Browse thread
stl?
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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