Any hopes for export ?
in [C++]
|
Prev: Is there any standard/guarantees for exception safety in STL operations?
Next: Does ternary conditional operator bind the order of evaluation?
From: Miles Bader on 3 Aug 2010 13:34 Seungbeom Kim <musiphil(a)bawi.org> writes: > I think they are good for what they are designed for. I agree. They are for avoiding name conflicts. Certainly the current behavior is very useful. -Miles -- Bacchus, n. A convenient deity invented by the ancients as an excuse for getting drunk. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Louis Lavery on 3 Aug 2010 18:04 On 04/08/2010 05:34, Miles Bader wrote: > Seungbeom Kim<musiphil(a)bawi.org> writes: >> I think they are good for what they are designed for. > > I agree. > > They are for avoiding name conflicts. More correctly, I think, they are for resolving them. Louis. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Hendrik Schober on 11 Aug 2010 16:35 Walter Bright wrote: > [...] > Export also fails to deliver on its promises of: > > 1. faster compilation No, it didn't fail at that. You and I have been discussing this several times in several newsgroups throughout the last decade, and I distinctly remember it was spelled out to you several times by those who had used it that it did indeed deliver that promise in a very common case: When you change a template's helper, compilation is sped up considerably, because you don't have to recompile everything using the template, but not (directly) the helpers. In my daily work, this would have been a tremendous help. > 2. effective obfuscation of template definition source code In the last ten years, I have cannot remember anyone except you bringing this up. >> Is there any chance now that we still have export in the new C++ ? >> Are there still people interested in export ? That think it would still >> be a feature ? > > No. That's definitely wrong. There are indeed people still interested in 'export'. >> More interesting, are there here any companies, perhaps working with >> templates a lot, that are interested in getting the export feature ? > > None of my (Digital Mars C++) users ever even asked for it. I'm sure they did, you just keep missing it despite the fact that this, too, had been pointed out to you several times: Everybody answering beginners' questions in newsgroups knows that beginners again and again are astonished that they have to include template _definitions_. Every single one of these beginners is not only asking their vendor to finally implement 'export', but simply _expecting_ the language to deliver it. > Since there is no realistic market for the feature, investing 3 man > years into > it (and not doing anything else in the meantime) makes no economic sense. Heck, just the amount of money thrown at distributed compilation a few years ago _in_one_small_shop_ I worked for would have paid a considerable part of those three man years -- except that most of that company's code had to be compiled on half a dozen compilers and compiler versions, only one of which supported 'export'. (And that one was only used for porting to a certain platform, not for any new development.) I'm sure that I alone have, in the last decade, seen a lot more man years than that wasted because of 'export' _not_ being widely available. (If someone would make a statistics of my newsgroup posting habits, they'd find the exact date of the above mentioned solution to the problem of long compilation times -- through distributed compilation -- very easily: It's the moment my postings during business hours became sparse. That's because fiddling with templates I wasted time waiting for the compiler, which I used to mostly spend reading C++ articles and posting in C++ newsgroups.) > There are a lot of things C++ could add with far less effort that would > be far > more useful. Like concepts? :) Hendrik Schober -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 12 Aug 2010 23:20 Hendrik Schober wrote: > Walter Bright wrote: >> [...] >> Export also fails to deliver on its promises of: >> >> 1. faster compilation > > No, it didn't fail at that. You and I have been discussing this several > times in several newsgroups throughout the last decade, and I distinctly > remember it was spelled out to you several times by those who had used it > that it did indeed deliver that promise in a very common case: When you > change a template's helper, compilation is sped up considerably, because > you > don't have to recompile everything using the template, but not (directly) > the helpers. > In my daily work, this would have been a tremendous help. As I recall, I pointed out that exported templates offered no fundamental technical advantage over precompiled headers in the speed department. PCH were an existing technology that did produce substantially faster compiles (at least with Digital Mars C++ they did), though I do not know how widely PCH was implemented. >> 2. effective obfuscation of template definition source code > > In the last ten years, I have cannot remember anyone except you bringing > this up. I discussed this with a couple people on one of the forums. It's been a long time. >>> Is there any chance now that we still have export in the new C++ ? >>> Are there still people interested in export ? That think it would still >>> be a feature ? >> >> No. > > That's definitely wrong. There are indeed people still interested in > 'export'. Sure, there's always someone, but I meant "no" as in not enough to make a difference. >>> More interesting, are there here any companies, perhaps working with >>> templates a lot, that are interested in getting the export feature ? >> >> None of my (Digital Mars C++) users ever even asked for it. > > I'm sure they did, you just keep missing it The entire Digital Mars support forum going back to 2001 is online, and is searchable. Go to http://www.digitalmars.com and use the search box to search for exported templates. > despite the fact that this, too, > had been pointed out to you several times: Everybody answering beginners' > questions in newsgroups knows that beginners again and again are astonished > that they have to include template _definitions_. > Every single one of these beginners is not only asking their vendor to > finally implement 'export', but simply _expecting_ the language to > deliver it. Newbies being surprised at the way any language works is fairly common, and does not necessarily translate into a demand that it change. Experts asking for a feature is an entirely different beast. >> Since there is no realistic market for the feature, investing 3 man >> years into >> it (and not doing anything else in the meantime) makes no economic sense. > > Heck, just the amount of money thrown at distributed compilation a few > years > ago _in_one_small_shop_ I worked for would have paid a considerable part of > those three man years -- except that most of that company's code had to be > compiled on half a dozen compilers and compiler versions, only one of which > supported 'export'. (And that one was only used for porting to a certain > platform, not for any new development.) > I'm sure that I alone have, in the last decade, seen a lot more man years > than that wasted because of 'export' _not_ being widely available. (If > someone would make a statistics of my newsgroup posting habits, they'd find > the exact date of the above mentioned solution to the problem of long > compilation times -- through distributed compilation -- very easily: It's > the moment my postings during business hours became sparse. That's because > fiddling with templates I wasted time waiting for the compiler, which I > used > to mostly spend reading C++ articles and posting in C++ newsgroups.) If a company had been willing to "throw money" at me to do exported templates, I'd have been motivated to implement them. As it was, there were a lot of things that they *were* willing to pay for that got done instead. >> There are a lot of things C++ could add with far less effort that >> would be far more useful. > Like concepts? :) If proper modules could be done for C++, it would resolve much of the compile speed issues. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mathias Gaunard on 13 Aug 2010 03:39
On Aug 13, 3:20 pm, Walter Bright <newshou...(a)digitalmars.com> wrote: > As I recall, I pointed out that exported templates offered no fundamental > technical advantage over precompiled headers in the speed department. > PCH were > an existing technology that did produce substantially faster compiles > (at least > with Digital Mars C++ they did), though I do not know how widely PCH was > implemented. Export template is quite easier and nicer to use and deploy than PCH. Personally, I don't understand what's so hard with implementing link- time template instantiation when you already have PCH. You already have support for serializing/deserializing your AST to/from an efficient binary form. All you need to do is embed that data in the object files (ELF objects shouldn't have any problem with this), then, before you call the linker, join all that data, and use it to instantiate and generate code for whatever type an export template was instantiated with. But then, I'm not a compiler writer; maybe there are issues with actually finding what to serialize in the first place. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |