|
Archives
D Programming
D
D.gnu
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger
C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows
digitalmars.empire
digitalmars.DMDScript
|
D - Serious Promises and Standard C++
↑ ↓ ← → "Golan Trevize" <golan.trevize microoroo.com> writes:
Thought some people would find this interesting.
http://www.comeaucomputing.com/iso/promises.html
↑ ↓ ← → "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.
↑ ↓ ← → "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
↑ ↓ ← → "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!
↑ ↓ ← → "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!
↑ ↓ ← → 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
↑ ↓ ← → "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++" ;)
↑ ↓ ← → 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
↑ ↓ ← → "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
↑ ↓ ← → "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.
↑ ↓ ← → 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!
↑ ↓ ← → 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
↑ ↓ ← → 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.
↑ ↓ ← → 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
↑ ↓ ← → "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.
↑ ↓ ← → "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.
↑ ↓ ← → 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...
↑ ↓ ← → "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.
↑ ↓ ← → 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!
↑ ↓ ← → "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
↑ ↓ ← → "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.
|
|