Version française
Home     About     Download     Resources     Contact us    
Browse thread
stl?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Kuba Ober <ober.14@o...>
Subject: Re: [Caml-list] stl?
>> i'm just trying to get my head around what it might look like, and
>> if/how it might be useful. (it just bugs me that somebody can claim
>> that C++ is the /only/ language that could do it -- maybe the real
>> quote implied "mainstream" or something. apparently Ada wasn't up to
>> snuff http://www.sgi.com/tech/stl/drdobbs-interview.html)
>
> I don't know what are the Stepanov requirements, but C++
> can do unboxed collections like  list<int>, which OCaml can
> not provide I think. a 'int list' has boxed integers in OCaml.
>
[...]
>
> The question is do we really need those 2 things ?
> I've worked a little bit with C++ using unboxed objects, that
> is without introducing pointers (similar to boxing) in templates,
> like list<figure> instead of list<figure*>, and passing them
> as value in parameters, or returning them,
> and it was far less efficient because there was lots of copy,
> and you could not use then virtual method on them. So in the

I think those are usually (or can be) implemented with
copy-on-write semantics. Heck, if the objects are large, you can have
specialized versions which use hardware-assisted copy-on-write.

This is pretty much how data structures in Qt work, say when you pass
QString around. While people usually pass a reference to a const QString
as a read-only parameter, it costs no more to pass QString by value --  
QString
won't copy much besides a pointer or two, and it's a fairly small and  
simple
class, as far as copy construction goes.

Cheers, Kuba