www.digitalmars.com         C & C++   DMDScript  

D - Serious Promises and Standard C++

reply "Golan Trevize" <golan.trevize microoroo.com> writes:
Thought some people would find this interesting.
http://www.comeaucomputing.com/iso/promises.html
Dec 21 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Golan Trevize" <golan.trevize microoroo.com> wrote in message
news:bs52pp$1iqp$1 digitaldaemon.com...
 Thought some people would find this interesting.
 http://www.comeaucomputing.com/iso/promises.html

Of course Greg Comeau would support export, since his EDG based compiler supports it and so it offers him a competitive advantage. <g> Interestingly, D has 'export' automatically falling out of the semantics of how templates are defined in D.
Dec 21 2003
next sibling parent "Golan Trevize" <golan.trevize microoroo.com> writes:
Hi Walter,


"Walter" <walter digitalmars.com> wrote in message
news:bs541o$1kl8$1 digitaldaemon.com...
 "Golan Trevize" <golan.trevize microoroo.com> wrote in message
 news:bs52pp$1iqp$1 digitaldaemon.com...
 Thought some people would find this interesting.
 http://www.comeaucomputing.com/iso/promises.html

Of course Greg Comeau would support export, since his EDG based compiler supports it and so it offers him a competitive advantage. <g>

Interesting that D has this. I actually found the above reference in the OpenWatcom newsgoups. Below is the post and it's quite interesting. http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&selm=brla4v%241dm%241%40panix2.panix.com&rnum=11
 Interestingly, D has 'export' automatically falling out of the semantics

 how templates are defined in D.

GT
Dec 21 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bs541o$1kl8$1 digitaldaemon.com...
 Of course Greg Comeau would support export, since his EDG based compiler
 supports it and so it offers him a competitive advantage. <g>

I must add to that that of course I am opposed to export because it apparently took EDG 3 man years of work to implement it, and I just don't see the return on investment for it. Export is a feature of enormous cost and very little benefit. But if I had export implemented in DMC++ I'd argue in favor of it <g>. I'll also point out that nowhere does the article point out what the usefulness of export might be to programmers. I've yet to see any article make a compelling case for its advantages, especially in the light of its enormous cost. If someone knows of one, I'd appreciate a url!
Dec 21 2003
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
I'm thoroughly underwhelmed by the whole notion of export.

But yet again, I may be partial, being the provider of an open-source suite
of libraries that are 100% header-only.

:)



-- 
Matthew Wilson

STLSoft moderator (http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
(www.synesis.com.au/articles.html#columns)

"You can tell a Yorkshireman, but you can't tell him much!" -- Uncle Michael

----------------------------------------------------------------------------
---



"Walter" <walter digitalmars.com> wrote in message
news:bs5fr1$27mc$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:bs541o$1kl8$1 digitaldaemon.com...
 Of course Greg Comeau would support export, since his EDG based compiler
 supports it and so it offers him a competitive advantage. <g>

I must add to that that of course I am opposed to export because it apparently took EDG 3 man years of work to implement it, and I just don't see the return on investment for it. Export is a feature of enormous cost and very little benefit. But if I had export implemented in DMC++ I'd

 in favor of it <g>.

 I'll also point out that nowhere does the article point out what the
 usefulness of export might be to programmers. I've yet to see any article
 make a compelling case for its advantages, especially in the light of its
 enormous cost. If someone knows of one, I'd appreciate a url!

Dec 21 2003
prev sibling next sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Golan Trevize wrote:
 Thought some people would find this interesting.
 http://www.comeaucomputing.com/iso/promises.html

I had just read it a few days ago. On the OpenWatcom newsgroup, someone advocated for export, i against, and was quite surprised to see Mr. Comeau answer! I must say that i dislike him. He says something then something else and bends the meaning of each word as he sees fit. Just compare this letter to his post in the newsgroup, also mentioned somewhere down this thead. The thing is, C++ module system is broken. And export doesn't fix it. I had posted Mathew an idea for fixing the module system, but with D and my lack of time to support anything, i don't think it's worth it. But if anything, it should work independantly of a compiler. If it finds use, someone may draw profit from integrating it into a front-end. But it would simply not work the other way around. Be it standard- backed or not. Greg seems to want to get OpenWatcom team into working on export. This would clearly be a suicide for the project, since there are so many basic features not covered yet. And as i see there are none of the original developers among the crew. ;( -eye
Dec 21 2003
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 The thing is, C++ module system is broken. And export doesn't fix it. I
 had posted Mathew an idea for fixing the module system, but with D and
 my lack of time to support anything, i don't think it's worth it.

Did you? I must confess I've forgotten what it was, and apologise for having done so. Busy, busy, busy ... Cheers Matthew P.S. If it was a good one, maybe I can put it in "More Imperfect C++" ;)
Dec 21 2003
parent Ilya Minkov <Ilya_member pathlink.com> writes:
In article <bs5cu2$22fj$1 digitaldaemon.com>, Matthew says...

Did you? I must confess I've forgotten what it was, and apologise for having
done so.

In fact, you even answered my e-mail. The idea of an utility, basically as another language on top of C++. I also explained to what extent it can improve compilation speed. However, i'm still puzzled in what relation the module system should have to the C++ namespace feature. I think i shall post it elsewhere. But i'm not sure since i know i won't have time to write it. D backend would be higher on my priority list, but as you can see i've dropped it as well.
Busy, busy, busy ...

Same here.
P.S. If it was a good one, maybe I can put it in "More Imperfect C++" ;)

We'll see. I think it's too heavyweight. -eye
Dec 22 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Golan Trevize" <golan.trevize microoroo.com> wrote in message
news:bs52pp$1iqp$1 digitaldaemon.com...
 Thought some people would find this interesting.
 http://www.comeaucomputing.com/iso/promises.html

Should contrast it with this paper on export: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf
Dec 21 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bs5mtu$2ijt$1 digitaldaemon.com...
 "Golan Trevize" <golan.trevize microoroo.com> wrote in message
 news:bs52pp$1iqp$1 digitaldaemon.com...
 Thought some people would find this interesting.
 http://www.comeaucomputing.com/iso/promises.html

Should contrast it with this paper on export: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf

Daveed Vandevoorde's rebuttal to n1426.pdf: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=52f2f9cd .0305090607.62637fdf%40posting.google.com&rnum=1&prev=/groups%3Fq%3Ddaveed%2 Bvandevoorde%2Bmodule%2Bconcept%26ie%3DUTF-8%26oe%3DUTF-8%26hl%3Den I haven't found any other substantive rebuttals while googling around. Daveed says that the demand for export is based on desires for faster compilation speed and hiding template source code (much like source code is hidden when it's distributed as .obj or .lib files). I'd like to see some benchmark results that show that export really does speed up compiles significantly. It sounds a lot like the justification for incremental linkers (Digital Mars' optlink can do full links faster than other vendors' linkers can do incremental links, which is why we never did an incremental linker). Hiding source could be easilly done by encrypting #include'd files in a manner that only the compiler could decrypt them (using well known public/private key cryptography). That leaves Daveed's final argument for demand, that programmers are caught by assuming that templates can be treated like function bodies and separately compiled, and that export enables this to work. I don't see this as anything more than a minor misunderstanding on the programmer's part, one that is easilly corrected. These seem to me to be weak justifications for the expense of export. Of course, I am not a member of the C++ committee and am not privy to the discussions they had about about export, if there is a better justification for it I'd sure like to see it.
Dec 21 2003
parent reply Georg Wrede <Georg_member pathlink.com> writes:
In article <bs5t3j$2tvu$1 digitaldaemon.com>, Walter says...
"Walter" <walter digitalmars.com> wrote in message
news:bs5mtu$2ijt$1 digitaldaemon.com...
 "Golan Trevize" <golan.trevize microoroo.com> wrote in message
 news:bs52pp$1iqp$1 digitaldaemon.com...
 Thought some people would find this interesting.
 http://www.comeaucomputing.com/iso/promises.html

Should contrast it with this paper on export: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf


Having read these brings yet again to my mind that the C++ crowd still are the diametric opposite of Practical Programmers. They seem constantly to take on challenges that you either have to be superhuman or foolhardy to even consider. "Exportable templates? Sure, bring 'em on!" What about consequences? Don't you fear this'll break things, be impossible to implement, break vendors' backs, or cause both vendors and users to deliberately skip trying to hang on to the bleeding edge? "Aw, you know, there are some amazing guys writing these compilers, they can pull off just anything, in no time too." Do you _know_ that this is even theoretically possible? "Naw, our vendors and programmers aren't just ordinary folks. That kind of thing never stopped them before." Oh, so you found the implications intractable, and just decided to go ahead? "Let's not get snotty here!" Sorry. But shouldn't language design follow similar paths as constructing a major application?? "Um, I've got BS on the other line, gotta go, bye." Bet they never heard of the KISS principle. Boy, am I glad that we have Walter and D!
Dec 22 2003
next sibling parent reply Ilya Minkov <Ilya_member pathlink.com> writes:
In article <bs6gpn$1a9p$1 digitaldaemon.com>, Georg Wrede says...

They seem constantly to take on challenges that you either have
to be superhuman or foolhardy to even consider.

I think there was an implementation in Bjarne's Cfront prior to the standard. It was just somewhat broken. -eye
Dec 22 2003
parent Georg Wrede <Georg_member pathlink.com> writes:
In article <bs6ihl$1crf$1 digitaldaemon.com>, Ilya Minkov says...
In article <bs6gpn$1a9p$1 digitaldaemon.com>, Georg Wrede says...

They seem constantly to take on challenges that you either have
to be superhuman or foolhardy to even consider.

I think there was an implementation in Bjarne's Cfront prior to the standard. It was just somewhat broken.

Yes, that was mentioned in the references in the posts. Having an almost working program for giving you the anwer to "what's the meaning of life?" does't imply that you can really implement one.
Dec 22 2003
prev sibling next sibling parent reply Elias Martenson <elias-m algonet.se> writes:
Georg Wrede wrote:

 In article <bs5t3j$2tvu$1 digitaldaemon.com>, Walter says...
 
"Walter" <walter digitalmars.com> wrote in message
news:bs5mtu$2ijt$1 digitaldaemon.com...

"Golan Trevize" <golan.trevize microoroo.com> wrote in message
news:bs52pp$1iqp$1 digitaldaemon.com...

Thought some people would find this interesting.
http://www.comeaucomputing.com/iso/promises.html

Should contrast it with this paper on export: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf


Having read these brings yet again to my mind that the C++ crowd still are the diametric opposite of Practical Programmers.

Well, I googles around a little for information on template export and realised that the Comeau compiler is the ony one that supports that feature. With that in mind, the Comeau paper mentioned makes a little more sense. If that feature goes away then they'd lose some of their edge. Regards Elias Mårtenson
Dec 22 2003
parent "Walter" <walter digitalmars.com> writes:
"Elias Martenson" <elias-m algonet.se> wrote in message
news:bs6k3a$1f7s$1 digitaldaemon.com...
 Well, I googles around a little for information on template export and
 realised that the Comeau compiler is the ony one that supports that
 feature. With that in mind, the Comeau paper mentioned makes a little
 more sense. If that feature goes away then they'd lose some of their edge.

Once it is implemented, the incremental cost of keeping it is small, since the investment in creating the feature is already spent. That high cost of implementation is a tall barrier against competitors. It's a powerful motive for any vendor with it implemented to vote to keep it in the standard. For those who are not compiler vendors, the cost of implementation is irrelevant, only the added value of the feature, however small that might be. I don't think it is a coincidence that the number of C++ vendors has shrunk, will continue to shrink, and that it has taken so long (5 years) for any vendor to be standard compliant.
Dec 22 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Georg Wrede" <Georg_member pathlink.com> wrote in message
news:bs6gpn$1a9p$1 digitaldaemon.com...
 Boy, am I glad that we have Walter and D!

It's the kind of thinking where extreme effort to solve minor problems is justified, but fixing the major problems is not. Export is an example of the former, the reaction I received from proposing Design by Contract in comp.lang.c++.moderated is an example of the latter. I just got tired of complaining about it, and did D. The ironic thing about export, though, is that D has it by default simply because D does imports rather than #include's. Export is a classic example of the problem of continuing to add new features into a framework that must still compile 30 years of backwards legacy code. It gets harder and harder to implement and the actual improvements get smaller and smaller.
Dec 22 2003
next sibling parent reply John Reimer <jjreimer telus.net> writes:
Walter wrote:
 "Georg Wrede" <Georg_member pathlink.com> wrote in message
 news:bs6gpn$1a9p$1 digitaldaemon.com...
 
Boy, am I glad that we have Walter and D!

It's the kind of thinking where extreme effort to solve minor problems is justified, but fixing the major problems is not. Export is an example of the former, the reaction I received from proposing Design by Contract in comp.lang.c++.moderated is an example of the latter.

What kind of reaction did you get to Design by Contract? Is there a link to the old Newsgroup discussions? Sounds interesting...
Dec 22 2003
parent reply "Walter" <walter digitalmars.com> writes:
"John Reimer" <jjreimer telus.net> wrote in message
news:bs7fl3$2pra$1 digitaldaemon.com...
 Walter wrote:
 "Georg Wrede" <Georg_member pathlink.com> wrote in message
 news:bs6gpn$1a9p$1 digitaldaemon.com...
Boy, am I glad that we have Walter and D!



 justified, but fixing the major problems is not. Export is an example of


 former, the reaction I received from proposing Design by Contract in
 comp.lang.c++.moderated is an example of the latter.


I'll let you read it for yourself!
 Is there a
 link to the old Newsgroup discussions? Sounds interesting...

Do a google search in groups for ["design by contract" walter] and sort by date.
Dec 22 2003
parent John Reimer <jjreimer telus.net> writes:
 
 Do a google search in groups for ["design by contract" walter] and sort by
 date.
 
 

Yeah, I figured that out. Found it with little trouble. Thanks!
Dec 22 2003
prev sibling parent reply "Golan Trevize" <golan.trevize microoroo.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bs7bd9$2jf9$1 digitaldaemon.com...
 "Georg Wrede" <Georg_member pathlink.com> wrote in message
 news:bs6gpn$1a9p$1 digitaldaemon.com...
 Boy, am I glad that we have Walter and D!

It's the kind of thinking where extreme effort to solve minor problems is justified, but fixing the major problems is not. Export is an example of

 former, the reaction I received from proposing Design by Contract in
 comp.lang.c++.moderated is an example of the latter.

 I just got tired of complaining about it, and did D.

I remember following that thread, It went on for quite some time and I actually think that you let it drag on for to long and it more or less became a religous battle. I personally think D is great and brave move foward and I hope more people will start using it. I'm using it a little and the only thing I really miss is a good source level debugger (it really is important for some of us some old habits are hard to break).
 The ironic thing about export, though, is that D has it by default simply
 because D does imports rather than #include's. Export is a classic example
 of the problem of continuing to add new features into a framework that

 still compile 30 years of backwards legacy code. It gets harder and harder
 to implement and the actual improvements get smaller and smaller.

Modula-2 also uses imports but the Definition and Implementation are in separate files. I got admit that I do like the separation at a file level. GT
Dec 22 2003
parent "Walter" <walter digitalmars.com> writes:
"Golan Trevize" <golan.trevize microoroo.com> wrote in message
news:bs7gvh$2s3v$1 digitaldaemon.com...
 I remember following that thread, It went on for quite some time and I
 actually think that you let it drag on for to long and it more or less
 became a religous battle.

I did try to drop out of it before it got too silly, but I think you're right.
Dec 22 2003