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: James Kanze on 25 Jul 2010 23:06 On Jul 23, 10:44 pm, Mathias Gaunard <loufo...(a)gmail.com> wrote: > On Jul 23, 12:51 am, Timothy Madden <terminato...(a)gmail.com> wrote: > > 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 ? > While I don't care much about export itself, the ability to > instantiate templates at link-time could be used to implement > very useful features in C++, such as virtual templates, > efficient multi- methods, and dynamic duck typing. But export cannot reasonably provide that (or we drop all support for dynamic linking). -- James Kanze -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 25 Jul 2010 23:12 Timothy Madden wrote: > Walter Bright 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 >> >> 2. effective obfuscation of template definition source code > > Export promises template declarations in header files, and definitions > in source files. Right, but there has to be a point to that. > If the compiler can get some form of speed benefit with that, which is > likely, that would be great. > I should say here that pre-parsed templates might compile faster than > plain source code templates included everywhere. Pre-parsed templates, > although not fully compiled like object code, are still half-compiled > and that will help with speed. It doesn't work out that way in practice, though, for various reasons - precompiled headers are a far simpler feature and deliver actual speedups. > Speed is not improved radically as some expected because the template > still gets compiled at potentially any translation unit where it is > instantiated; symbols used in the template that are dependent on > template arguments have to be looked for at that point too. That is > flexible behavior and a good thing, but then again not every template > uses dependent names, so you still get a speed benefit. And if they do > use them, you get no slower than the speed you get including the > definition. How is export wrong ? For one thing, it requires that the compiler maintain some sort of global database of precompiled templates. Managing that database is a time sink, and comes with its own set of problems. > About source code obfuscation, other languages too compile to > bytecode, that can gives back the source, and they do just fine and > have a lot of support and many libraries. So if export can get that > for templates, and compiles to a pre-parsed tree, much like the > bytecode, I would say it still helps. Again, how is it wrong ? Because it is a failure at source obfuscation. There are many programs that can convert bytecode back into reasonable source code, thereby rendering pointless any attempts to obfuscate the source. Furthermore, precompiled templates must by necessity contain more information than Java bytecodes, so the decompiler can do an even better job at reconstructing the source. Basically, if you need source obfuscation, use PIMPL. Exported templates aren't going to get you there. > Besides, even proprietary libraries usually ship with the source code > (but without the license for its use) for debugging and documentation, > so source obfuscation is not much of an issue, and whatever export can > get of it, shall be good enough. It's fine if obfuscation isn't desirable, but then what are exported templates good for? > And of all the complexity that export is accused of, introducing a > whole-program compilation feature, such as template instantiation (as > someone else said in this thread), makes possible more language > features, not just export. Whole program compilation would render exported templates irrelevant, so again there seems to be no place for them. > Is there some estimate about when the new language shall be out ? Will > there be other meetings, or votes until then ? I don't know, I'm not on the Committee. > Yeah, I can see it is not obvious to everybody that export is useful; I've written a complete C++ compiler, and spend some time studying the issues. My conclusion is that exported templates simply have no net benefit, even if their implementation cost were zero. > people have long gotten used to the inclusion model as the only model > ... :( Not at all. I worked on D, which has a symbolic import system. "Exported templates" comes for free with such, and without the complexity. C++ exported templates attempted to graft a subset of symbolic import onto the inclusion model, and it just does not work. > A company that is interested in this would certainly help, however I > guess this is not too likely. Sometimes I find that the commercial > model of developing-for-profit looks much like the greedy algorithm > used for computing the minimum coins for a change (given a set of > possible coin values) on a snacks machine. Greedy is known to give an > optimal solution for practical and most cases, but not for all of them > :(. Just like a company could benefit from export, but still because > of the greedy-like approach of go-for-profit always has only a loose > interest for it. Look at it another way. It would take me 3 man-years to implement it. Am I greedy to want some sort of return for investing 3 years of my life? I don't see any return on investment for exported templates, not for me and not for my customers. I've got too much to do that has big demand for it, like the 64 bit code generator I'm up to my eyeballs in at the moment. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Edward Diener on 25 Jul 2010 23:48 On 7/25/2010 7:57 PM, Francis Glassborow wrote: > 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. The position of the C++ Standard Committee in dropping 'export' is completely understandable. However, I believe the position of many people in regards to 'export' is that the idea of being able to specify template declaration code apart from template definition code, so that only template declaration code needs to be #included by the end-user of a template to instantiate the template, has some important uses. If the 'modules' feature addresses this functionality so much the better. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Dragan Milenkovic on 25 Jul 2010 23:48 On 07/25/2010 05:18 PM, Timothy Madden wrote: [snip] > 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. It may be interesting, but don't you agree that it is quite a bit messy? If this "modules stuff" manages to fix the core of the issue, that would be even more interesting. Could someone please point to some work done in this area? Thanks... -- Dragan [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Pedro Lamarão on 26 Jul 2010 02:47
James Kanze wrote: > > 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. Which suggests that those who would like to keep it on the standard should implement it in GCC, and perhaps also Clang. If there are enough interested parties out there, perhaps a joint effort would succeed, or be capable of funding it. With the new support for LTO in GCC and the LLVM foundation of Clang perhaps we would see a different incarnation of export from what was envisioned initially. Not that I actually know how it was envisioned initially, though... -- P. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |