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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,703c4f68db81387d X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!o13g2000cwo.googlegroups.com!not-for-mail From: "Jerry Coffin" Newsgroups: comp.lang.ada Subject: Re: Teaching new tricks to an old dog (C++ -->Ada) Date: 24 Mar 2005 08:35:41 -0800 Organization: http://groups.google.com Message-ID: <1111682141.541662.113720@o13g2000cwo.googlegroups.com> References: <4229bad9$0$1019$afc38c87@news.optusnet.com.au> <1110032222.447846.167060@g14g2000cwa.googlegroups.com> <871xau9nlh.fsf@insalien.org> <3SjWd.103128$Vf.3969241@news000.worldonline.dk> <87r7iu85lf.fsf@insalien.org> <1110052142.832650@athnrd02> <1110284070.410136.205090@o13g2000cwo.googlegroups.com> <395uqaF5rhu2mU1@individual.net> <1111607633.301232.62490@z14g2000cwz.googlegroups.com> <4793664.vi5Yol0h1t@linux1.krischik.com> NNTP-Posting-Host: 68.64.130.76 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1111682145 2378 127.0.0.1 (24 Mar 2005 16:35:45 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 24 Mar 2005 16:35:45 +0000 (UTC) User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: o13g2000cwo.googlegroups.com; posting-host=68.64.130.76; posting-account=mZiOqwwAAAC5YZsJDHJLeReHGPXV5ENp Xref: g2news1.google.com comp.lang.ada:9918 Date: 2005-03-24T08:35:41-08:00 List-Id: Martin Krischik wrote: [ ... ] > I have worked a lot with SQL and I allways wound it cumbersome to map > the SQL string type to C++. Most SQL string types are bounded - they > have a maximum size. std::string (and IBM's IString) is unbounded - > so before you can store your string inside the database you have to > make a sanity check. In Ada I could use Ada.Strings.Bounded_Strings > instead. While bounded vs. unbounded strikes me as a reasonable distinction, I'm not at all convinced that two separate string classes are necessary to accomplish it. I see nothing here that can't be accomplished by single class with a parameter specifying its bound (or lack thereof). In fact, std::basic_string in the C++ library indirectly supports that right now: what we're reallly talking about is the memory allocation for the string, and std::basic_string takes a parameter to specify the allocator to use. All that's needed for a bounded_string is an allocator that only ever allocates a block of the initially-specified size. That does leave a minor bit of room for discussion over terminology -- basic_string is a template, so instantiating it over a different allocator does technically produce a separate class. Since it's one piece of code, I generally think/speak of it as a single class except in those situations where it really matters that two separate instantiations aren't really the same class. >>From that viewpoint, C++ doesn't have just one or two string classes -- rather, it has a potentially unbounded set of string classes. OTOH, from a viewpoint of coding, all the string-specific behavior for all those classes is defined in one place. In the end, you can call that what you will, and depending on how you call it, my original statement about the multiplicity of classes indicating a problem might need to be re-phrased. > > Ada's exception handling is also primitive at best (exceptionally > > so, if you'll pardon a pun). In particular, in Ada what you throw > > is essentially an enumaration -- a name that the compiler can > > match up with the same name in a handler, but nothing more. Only > > exact matches are supported and no information is included beyond > > the identity of the exception. > > Well, Ada 95 added a 200 character informations string. Actually, looking through the specification, it has technically added two strings (name and information) so what I said was clearly wrong in Ada as currently defined, and I apologize for that. OTOH, this doesn't really seem to change the point much -- I've yet to see anybody claim that the current situation in Ada in anywhere close to optimal. [ ... ] > All true. But does that powerfull contruct works inside a multi > tasking environment. No multitasking is included in the C++ specification, so it's impossible to answer that about C++ in general. > It is indeed true that Ada exeptions are restricted - but they > are thread save. And thead save means that an exception may be > raised in one thead and caugth in another. Exceptions raised > inside an rendevous may even be caught in both threads > participating in the rendevous. With the proviso above, yes -- at least in the implmentations I've used in environments that supported multi-threading, C++ exception handling was thread-safe. I feel obliged to add that exception handling is an unusually simple case to make thread safe. First we care little about speed. Second, throwing the exception halts the throwing thread, so there's really only one thread active at a time, and the switch from one thread to another is easily predictable. > And tread save is not all. An Ada system implementing the (optional) > Annex E needs exeptions which can be passed from one process to > another. Both processed runing on different computers. Just like > CORBA exceptions. Again, the C++ standard simply doesn't include an analog, but as you've pointed out, CORBA supports them. The middleware market is sufficiently competitive that almost any major feature in one will be present in the others as well... -- Later, Jerry. The universe is a figment of its own imagination.