In regard to the quality and consistency of stl itself, some projects prefer to use "stlport" rather than the stl that might happen to come with a given compiler. This does have the advantage of a stl of known quality and consistent implimentation.
I personally do not like templated code that much, because it tends to produce huge object images which you can get stuck with if you have a poor linker unable to resolve the common expressions at link time. gcc incidently includes a couple of special pragma's which allow you to specify when a template is being used for declaration purposes only vs when to impliment code from a given class into a given object file. This can be very nice when used correctly, but is entirely gcc specific.
The template classes we looked at having in Common C++ were going to be for special cases where common but highly optimized design patterns would likely get re-used. For example, if one needs a single linked list or associated hash as a single list, or other specialized things that did not fit into stl well, or which the stl version that comes close would tend to be much larger. It was also going to be extended to better support multi-threading which most stl's do not address, and perhaps eventually support "lock-free" data structures. The most useful class in the Common C++ template library at the moment seems to be the smart pointer class.
Federico Montesino Pouzols wrote:
On Tue, Mar 01, 2005 at 07:28:00PM -0500, Dan Weber wrote:
How much slower would it be using std::list. We know std::list is very well tested and usable. I'm thinking about sending a patch just because I'm not interested in instability in my applications.
Dan
I've had funny experiencies with the STL of Visual C++, though they may have improved in the last two years. Apart from atrocious implementations, the performace loss should not be too big not even noticeable, but it depends on what list we consider (list of packets, ssrcs, participants, destinations, etc. may show significant differences in size and use frequency depending on the application). I think the best solution would be to replace handcrafted lists with templates similar to the objlink template of commonc++, without the overhead derived from additional functionality or deficient STLs.
_______________________________________________ Ccrtp-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/ccrtp-devel
begin:vcard fn:David Sugar n:Sugar;David org:GNU Project adr:;;23 Olin Drive;Cape May Court House;NJ;08210;USA email;internet:[EMAIL PROTECTED] tel;home:1 609 465 5336 tel;cell:1 908 917 6084 x-mozilla-html:FALSE url:http://www.ostel.com version:2.1 end:vcard
_______________________________________________ Ccrtp-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/ccrtp-devel
