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 26 Jul 2010 23:42 Walter Bright wrote: > Timothy Madden wrote: >> Walter Bright wrote: >>> >>> Timothy Madden wrote: >>>> [...] >> Export promises template declarations in header files, and definitions >> in source files. > > Right, but there has to be a point to that. But the point is just that, to have template declarations in header files, and definitions in source files. And have the compiler understand that. I think it is a good point. > >> 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. Exported templates also benefit from pre-compiled headers, and a lot, as symbol tables is what they work with. > > [...] > > 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. I have heard this idea before, but how is this required ? >> 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? The short point is, the history and wide-spread of a language compiled to bytecode shows that pseudo-obfuscation still meets people's needs. >> 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. I guess I misused the expression whole program compilation here. I meant the template instantiation phase, when the compiler gets all the object files for processing. Sorry. [...] > > 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. So maybe export should be optional. If you do not want to touch the area, you have no need to. Would that be acceptable for compiler writers ? 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: Andre Kaufmann on 27 Jul 2010 06:39 Timothy Madden wrote: > [...] Sorry for jumping in. > But the point is just that, to have template declarations in header files, and definitions in source files. And have the compiler understand that. I think it is a good point. Wouldn't it be better to get rid of the inclusion model at all and better get a "module concept" in C++ as in other languages too ? Often it's said the inclusion model (separation of header and implementation file) is good for decoupling and therefore for compilation speed - may be. Most other languages use a single (module) file, where either the compiler separates header and implementation by itself and writes preparsed / precompiled code to be used when the code is imported in other modules. Or simply separation of header and implementation by using a keyword, which starts the implementation part in a single module file. I think this is an easier model for the compiler / tools and the developer. What's the real benefit of using multiple files for code which makes up a single code module - did I miss something ? > [...] Andre -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 27 Jul 2010 06:39 Timothy Madden wrote: > Walter Bright wrote: >> 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. > I have heard this idea before, but how is this required ? If the compiler is compiling foo.cpp, and it contains an exported template declaration, the compiler has no clue from the source code where it might find that template definition. Therefore, there must be some sort of global database the compiler can consult and update. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Zeljko Vrba on 27 Jul 2010 06:39 On 2010-07-27, Timothy Madden <terminatorul(a)gmail.com> wrote: > Walter Bright wrote: >> Timothy Madden wrote: >>> Walter Bright wrote: >>>> >>>> Timothy Madden wrote: >>>>> > [...] >>> Export promises template declarations in header files, and definitions >>> in source files. >> >> Right, but there has to be a point to that. > > But the point is just that, to have template declarations in header > files, and definitions in source files. And have the compiler understand > that. I think it is a good point. > So what's the problem with the following approach? #ifndef MY_Blah_h #define MY_Blah_h template <typename T> class Blah { // Your declarations go here }; #include "MY_Blah_impl.cpp" #endif -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Dragan Milenkovic on 27 Jul 2010 06:39
On 07/27/2010 04:42 PM, Timothy Madden wrote: [snip] > Here is an example of the use for a whole-program aware language > feature, not related to export: > > Suppose I have a class Module. That is not really usable by itself, and > each application module that needs the functionality in class Module > needs to derive from it a class that represents the specific module. > Base class Module needs to know about its children classes, and needs to > associate a constant to each of them (XmlModule, NetworkModule, > ThreadsModule, GUIModule) in order to provide its functionality. Why would Module need to know about it's children? This is the responsibility of some factory - for example ModuleFactory, which is a higher-level class. I don't like your design... the primary goal is to separate interfaces and responsibilities as much as possible, not integrate them... I did not really get your example. I will however acknowledge your disclaimer that this may not be the best example for the feature. -- Dragan [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |