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!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.hanau.net!news-fra1.dfn.de!newsfeed.pionier.net.pl!news.nask.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mail
From: "Robert Kawulak" <tigrisek@interia.pl>
Newsgroups: comp.lang.ada
Subject: Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)
Date: Wed, 20 Oct 2004 22:06:28 +0200
Organization: tp.internet - http://www.tpi.pl/
Message-ID: <cl6gok$q0e$1@nemesis.news.tpi.pl>
References: <e749549b.0409211621.6f3d3723@posting.google.com>
 <cj0qlt$qkh$1@a1-hrz.uni-duisburg.de>
 <e749549b.0409240828.53001e66@posting.google.com>
 <41547dae$0$91007$39cecf19@news.twtelecom.net>
 <e749549b.0409252313.7cf8ca3a@posting.google.com>
 <uekkpt07s.fsf@earthlink.net>
 <e749549b.0409270631.2bf81ccf@posting.google.com>
 <1g2d9xmnita9f.5ecju0eftkqw$.dlg@40tude.net>
 <cjcn5t$s37$1@atlantis.news.tpi.pl>
 <1hl2mizeb27ku$.1f0asrbmb05mi.dlg@40tude.net>
 <cjeurq$bvp$4@nemesis.news.tpi.pl>
 <7siml3c62lev$.usczt2y2l19c$.dlg@40tude.net>
 <cji06f$17a$2@atlantis.news.tpi.pl>
 <15fk5715wm38q.3ie9r3bq8yuz$.dlg@40tude.net>
 <cjpm1t$7ep$2@nemesis.news.tpi.pl>
 <1ob4dexep087b$.ul8fb1ebgeok.dlg@40tude.net>
 <ck1a48$bqs$1@atlantis.news.tpi.pl>
 <1dzt37oj3dnah.bwalpmfvyxd3$.dlg@40tude.net>
 <ckcct1$s1$2@atlantis.news.tpi.pl>
 <1k2m0s9456ba7$.t0euzv9ux97l$.dlg@40tude.net>
 <cko5pk$3fu$1@atlantis.news.tpi.pl>
 <1q7hilgv3yu3a$.1t931ae5tgr06.dlg@40tude.net>
NNTP-Posting-Host: pd111.krakow.cvx.ppp.tpnet.pl
X-Trace: nemesis.news.tpi.pl 1098303061 26638 213.76.39.111 (20 Oct 2004
 20:11:01 GMT)
X-Complaints-To: usenet@tpi.pl
NNTP-Posting-Date: Wed, 20 Oct 2004 20:11:01 +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:5546
Date: 2004-10-20T22:06:28+02:00
List-Id: <comp.lang.ada>

Hi,

> #define is also parsed! In compiled languages "parsed" is far less than
> "compiled" and the results of these two actions are much different too.

  OK, by saying 'parsed' I meant 'compiled'... Don't catch me in my
words! ;-)

> The
> margin is not absolute of course, but parsed template body is closer to
> parsed #define body than to a compiled true body.

  Templates are not so close to #defines. Using the 'export', keyword their
implementation may be *compiled* in only one translation unit, and you may
use them anywhere given only their declarations  - just like ordinary
functions and objects (well, at least in theory, because there are not so
many compilers supporting 'export' yet... But I hope this will change soon).

> What if the *implementation*
> does not fulfill the contract, while the parameter does?

  Ah, I see (at last ;-) what's your point. But is it really necessary to
check if the *implementation* is contract-conformant? If it's not
contract-conformant, then you get a compile-time error anytime you try to
use it, the only difference I see is that such an error is detected only
during instantiation. I know it'd be nice if the implementation would be
checked for contract-conformance during compilation (parsing, whatever ;-),
but OTOH I don't see not doing this such an issue...

Regards,
Robert