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: Timothy Madden on 25 Jul 2010 00:08 Martin B. wrote: > > Timothy Madden wrote: >> >> Hello >> >> As you may know export has been a controversial feature for templates in >> C++, although also a somewhat promising and a much-awaited one for the >> more technical programmer, that even to date has hardly received support >> in compilers. >> >> You may hear that much of the controversy started with a paper by Herb >> Sutter (at Microsoft) and Tom Plum: >> http://www.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1426.pdf >> However the one company that did implement export also made an article >> against it as being biased: >> http://www.comeaucomputing.com/iso/promises.html >> >> In short the point is that many reasons against export have been given, >> but I find that they just do not justify the extraordinary measure of >> dropping the already standard feature from the future versions of C++. >> > > Both of these articles offer some insight but they are both from 2003 (7 > and I certainly > don't use export I would like to know: would that be because you (and everybody else) just do not have export, or is there something else about it ? > but probably some things have changed in 7 years. You would think people shall see by now export is not exactly wrong and unfit, but one of C++ features, and it is helpful and productive to have the declarations for templates in header files, and the definition bodies in source files, and have the compiler know how to do about it. But I still get those subjective reasons that it is not worth the effort, it has little or no value, is difficult to use or not understood, despite those reasons being argued against even at that time. :( After all every C++ feature is complex (the language is), and still every feature has its role and is important. So does export. The only reason I can see, that was not there at that time, is that export has not been wildly implemented (though it has been implemented), and I still wonder how is this a reason to remove export from the standard ? I mean SQL-99 has not been implemented either, and they still kept it and developed 2 more versions of SQL (2003 and 2006). Also it still escapes me how can one think export should be removed and that lack of demand is a reason, since people can not use export yet nor try it to get an image of it (the only compiler to support export has no free or evaluation version). Besides, as someone here said, and also on a similar thread on comp.std.c++ (for which this issue proved too debatable and noisy) http://groups.google.com/group/comp.std.c++/browse_thread/thread/5c0bcfb55a745f71/cdfc230f0d73a736?#cdfc230f0d73a736 having such a whole-program compilation feature, that export introduces, is a foundation for many other features. Thank you, Timothy Madden -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Timothy Madden on 25 Jul 2010 00:18 Francis Glassborow wrote: > > Martin B. wrote: >> >> Timothy Madden wrote: >>> >>> Hello >>> >>> As you may know export has been a controversial feature for templates in >>> C++, although also a somewhat promising and a much-awaited one for the >>> more technical programmer, that even to date has hardly received support >>> in compilers. >>> >>> You may hear that much of the controversy started with a paper by Herb >>> Sutter (at Microsoft) and Tom Plum: >>> http://www.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1426.pdf >>> However the one company that did implement export also made an article >>> against it as being biased: >>> http://www.comeaucomputing.com/iso/promises.html >>> >>> In short the point is that many reasons against export have been given, >>> but I find that they just do not justify the extraordinary measure of >>> dropping the already standard feature from the future versions of C++. >>> >> >> Both of these articles offer some insight but they are both from 2003 (7 >> years old). I certainly don't know current arguments and I certainly >> don't use export, but probably some things have changed in 7 years. >> > > Yes and one of them is that (AIUI) EDG supported the removal. I believe that the modules proposal (postponed till the next iteration of the C++ Standard) will address many of the problems as well as making C++ more usable by the casual programmer. That is not really news. EDG were against export even before they implemented it, and then they made it work and announced they would help other implementers with it. It looks like they had split opinions at all times. I know modules address the issues that export tackles, but when the next iteration of the standard is done I will be many years older than I am now (29, by the way :), so I am hoping to get better news with export. Thank you, Timothy Madden -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Francis Glassborow on 25 Jul 2010 08:57 Timothy Madden wrote: > Francis Glassborow wrote: >> Yes and one of them is that (AIUI) EDG supported the removal. I >> believe that the modules proposal (postponed till the next iteration >> of the C++ Standard) will address many of the problems as well as >> making C++ more usable by the casual programmer. > > That is not really news. EDG were against export even before they > implemented it, and then they made it work and announced they would > help other implementers with it. It looks like they had split opinions > at all times. > > I know modules address the issues that export tackles, but when the > next iteration of the standard is done I will be many years older than > I am now (29, by the way :), so I am hoping to get better news with > export. > So do you know of any implementer who was in favour of export? I think that your chances of getting modules in the next 10 years is infinitely higher than getting export even were WG21 decide not to remove it. IOWs WG21 is facing reality, no one else is going to implement export so it is time to allow otherwise conforming implementations to say that they are conforming and to encourage others to make the effort to have a fully conforming mode. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mathias Gaunard on 25 Jul 2010 23:04 On Jul 25, 4:18 pm, Timothy Madden <terminato...(a)gmail.com> wrote: > I think the ability to fed the entire program to the compiler at some > point in the build process (to instantiate templates or for anything > else) is what is interesting. Never thought about it, but this makes > the classic compilation model where translation units are compiled > separately, look old, dusty and unproductive. Most modern compilers (GCC, LLVM, MSVC) already allow this, since this allows to inline functions across translation units boundaries, etc. It's however less incremental, harder to parallelize, and more importantly, it doesn't scale as well since it requires to put the whole of the program into memory, which simply may not fit. > I guess this step is also what you are thinking about ("instantiate > templates at link-time"). To be frank I find all these very > interesting and I am surprised people are so much against export. Instantiating at link-time is also problematic with dynamic linking. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: James Kanze on 25 Jul 2010 23:06
On Jul 23, 1:02 pm, Walter Bright <newshou...(a)digitalmars.com> wrote: > Timothy Madden wrote: > > The main reasons I hear now against export are that it is not actively > > demanded (users always have the old inclusion model), that it is costly > > to implement, and that it has not been implemented. > Export also fails to deliver on its promises of: > 1. faster compilation In the one experiment I did with it, it gave distinctly faster compile times when just invoking make. Two or three times faster. (Admittedly, I was motivated to try it because I found I was recompiling a lot of code that didn't need recompilation. The class template I was defining had a lot of more or less trivial functions, which were used in twenty or thirty different modules, and one rather complex function to set it up, invoked in a single module. And every time I'd modify the complex function, I'd recompile all twenty or thirty modules, and not just the single module which used it.) > 2. effective obfuscation of template definition source code I've never heard that as a promise. The most important single promess it made was a separate compilation environment for the template. And it fulfilled that. > > 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. No to which of the above. When it comes down to it, it doesn't matter whether we have it in C++0x, since clearly, the compiler writers (with the exception of EDG) have conspired to not implement it. That doesn't mean that no one is interested in it (or at least in the separation of compilation it provided). > > 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'd say that there is at least partially a chicken and egg issue. If you could use it portably, a number of places where I've worked would have been glad to do so. On the other hand, we never asked e.g. Sun CC to provide it, since even if we did, we couldn't use it unless it also worked with g++ and VC++. > 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. The problem is that there is no realistic market for the feature unless it is widely implemented. A feature which is available on just one compiler (and a minority one at that) can't be used, regardless of how good it is. > There are a lot of things C++ could add with far less effort > that would be far more useful. For whom? Most of the places I've worked have simply banned templates in application level code, because of the necessity of putting the implementation in the header file. Are templates useful at the application level (as opposed to low level support libraries)? I don't know, but I know that some people claim that they are. -- James Kanze -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |