From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,243dc2fb696a49cd X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.glorb.com!news.icp.pl!newsfeed.gazeta.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mail From: "Robert Kawulak" Newsgroups: comp.lang.ada Subject: Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) Date: Wed, 29 Sep 2004 20:16:20 +0200 Organization: tp.internet - http://www.tpi.pl/ Message-ID: References: <1777528.JKnUEYTOM6@linux1.krischik.com> <1ec946d1.0409230820.455ad242@posting.google.com> <3673998.bj16mkkOu2@linux1.krischik.com> <1700922.2nPlMsa4Ny@linux1.krischik.com> <3750337.aJMmIeXcav@linux1.krischik.com> <3060085.UHp9MgIIe7@linux1.krischik.com> NNTP-Posting-Host: pr170.krakow.cvx.ppp.tpnet.pl X-Trace: nemesis.news.tpi.pl 1096482492 12281 213.76.42.170 (29 Sep 2004 18:28:12 GMT) X-Complaints-To: usenet@tpi.pl NNTP-Posting-Date: Wed, 29 Sep 2004 18:28:12 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-RFC2646: Format=Flowed; Original Xref: g2news1.google.com comp.lang.ada:4402 Date: 2004-09-29T20:16:20+02:00 List-Id: Hi all, >> Yup, you're absolutely right. But Stlport implementation always stores >> '\0' at the end, so std::string::c_str() boils down to returning a >> pointer. On the other hand, the GCC implementation writes terminating >> '\0' >> every time this function is called. However, this is still constant >> complexity and a little overhead contrary to what many people suspect - >> that converting std::string to char * requires copying whole the contents >> of the string to some temporary buffer. > > But that means that the strings need "capacity () - size () >= 1" so that > there is allways one spare byte for the '\0'. Well, in those particular implementations yes, but AFAIK it's not imposed by the standard. > I was thinking about "capacity () - size () == 0" - then c_str() would > need > to resize. Doesn't happen in your implementation - but is this valid for > all. As said above, it's not. An implementation can choose freely, but I suspect that vast majority use "capacity () - size () >= 1" due to efficiency - after all this one extra byte doesn't cost a lot compared to creating new buffer for whole the string and copying it in case of a call to c_str(). >> I can't agree with that at all. In C++ there is almost always an >> alternative. You may use std::vector<> instead of arrays, std::auto_ptr<> >> instead of naked pointers etc. But still you have a choice - if you >> really >> need to have a total low-level control on your program, you may have it. >> Otherwise use higher abstraction-level utilities. What you say might be >> eventually true for C, but not for C++. And the difference between the >> two >> is enormous, unfortunately many people think C and C++ is the same... > > Not quite true. I did have to make Ada::Range Last> myself. Actually, I still have to make it. My Current implementation > is for the old standart (as in Ada::IntegerRange). > C++ > has protection against buffer overruns - but the new JPEC Viruses work > integer overurns. That one is indeed missing in the standard (that's why I've used 'almost' above ;-) and you have to make it on your own (fortunately it's a trivial task, and you do it only once and then reuse). > And there is no: > > typedef explicit int My_Int. > > And that means that > > typedef Ada :: Range US_Hours; > typedef Ada :: Range Month; > > are the same for C++. But there are not in real live. And if I use: > > class US_Hours Ada :: Range {}; > class Month Ada :: Range {}; > > I loose the constructors. So there is still something to be improved. That's all very true what you say and it IS going to be improved - there are already papers submitted to the C++ standarisation commettee concerning strongly-typed typedefs. Best regards, Robert Kawulak