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: Peter C. Chapin on 26 Jul 2010 03:42 On 2010-07-26 10:06, James Kanze wrote: > 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). Ada has a generic feature that is similar to C++ templates except that in Ada there is a separation between declarations (specification) and implementations (body). The feature is designed in such a way as to allow implementations to reuse the generic body for every instantiation. There is a performance cost for this but in some cases that is acceptable and the smaller code size is preferred. There are some other benefits: 1. Generic bodies can be separately compiled to actual object code. 2. Generic bodies only need to be compiled once no matter how many times they are instantiated. 3. The compiler enforces at compile time consistency on the the generic actual parameters (similar to the C++ concept proposal). The Ada standard does not *mandate* this approach and some implementations do require access to the source code of generic bodies in a manner similar to the case for C++ templates (point #3 above is true in either case, however). Anyway my point here is that this works in Ada because of the way generics are defined. Probably if C++ templates had been defined slightly differently it would work for C++ as well and we wouldn't be having this discussion now. In any event, separate compilation of generic (template) bodies *is* useful and if it worked well in C++ I would definitely be using it. I haven't asked my compiler vendor to provide the feature because I know it's pretty much hopeless. Of course that allows compiler vendors to claim that there's a lack of customer interest in this matter. It's definitely a chicken-and-egg thing, it seems to me. Peter P.S. I might be wrong about this but I also believe that Ada generics can't be used for meta-programming the way C++ templates can. I have a feeling this might be related to the same restrictions imposed by Ada that allow for the advantages I mentioned above. It might not be possible to have it both ways. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Jean-Marc Bourguet on 26 Jul 2010 07:33 "Peter C. Chapin" <pcc482719(a)gmail.com> writes: > On 2010-07-26 10:06, James Kanze wrote: > >> 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). > > Ada has a generic feature that is similar to C++ templates except that > in Ada there is a separation between declarations (specification) and > implementations (body). The lack of explicit and partial specialisations is a bigger difference. Instantiations are named, which allows some things for which we need to use tag parameter in C++, but make the generic more painfull to use. > The feature is designed in such a way as to allow implementations to > reuse the generic body for every instantiation. IIRC, for Ada 83 compilers used both approach and there where even compilers which allowed to choose per instantiation, but for Ada 95 there where some complications which didn't theorically make shared implementation impossible but induced all compilers to use specialized one. Allowing explicit and partial specialisations would make shared implementation even less the right approach. > P.S. I might be wrong about this but I also believe that Ada generics > can't be used for meta-programming the way C++ templates can. The lack of explicit and partial specialisation is the root cause. The need to name instantiation could also be a factor in this. > I have a feeling this might be related to the same restrictions imposed > by Ada that allow for the advantages I mentioned above. It might not be > possible to have it both ways. It depends how much link time work you are allowing. Yours, -- Jean-Marc [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 26 Jul 2010 07:31 James Kanze wrote: > 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. I should have been clearer. It does not deliver better speed improvements than an existing, and far simpler, common feature of C++ compilers - precompiled headers. I know of no technical reason to suppose that exported templates could be faster than pch. >> 2. effective obfuscation of template definition source code > > I've never heard that as a promise. I have, it was discussed in this n.g. years ago. > The most important single promess it made was a separate > compilation environment for the template. And it fulfilled > that. Yes, but separate compilation is not a goal in and of itself, there is a purpose behind separate compilation: 1. implementation obfuscation 2. faster compilation There's no reason to have separate compilation if at least one of those two goals cannot also be met. >>> 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. Pretty much to all of them. There might be a few people still wanting it (like Timothy, obviously) but not enough to make a difference. > 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. As a C++ compiler writer, I can assure you that I have not been involved in any "conspiracy" to not implement it. I did seriously consider implementing it for purely marketing reasons, even though I believe there is no net benefit to users for the feature, because it's a great selling point to say one supports 100% of the Standard. > That doesn't mean that no one is interested in it > (or at least in the separation of compilation it provided). I wish to reiterate that separation of compilation is not a goal, it is a means to another goal. If it technically succeeds at separation of compilation, but fails at that further goal, it is a failure. >> 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++. Perhaps, although my users have not been shy about asking for what they want. More generally, if you don't make clear to your vendor what your needs are, is it any surprise they make no attempt to fulfill them? >> 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. I would have implemented exported templates if I thought they delivered value to the customer. They don't. If it was an easy to implement feature (like the useless exception specifications) I would have implemented it anyway. The problem is that exported templates are probably the most expensive feature ever devised for C++, and is at the bottom of the barrel in terms of user utility. >> There are a lot of things C++ could add with far less effort >> that would be far more useful. > > For whom? For users. > 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. Why didn't they want 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. I'll leave the answer to that to others <g>. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 26 Jul 2010 07:48 Dragan Milenkovic wrote: > 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... The D programming language has templates that follow the same strategy as C++ templates. But D has a true module system, and it clearly fixes the issue of exported templates: 1. fast compilation - yes 2. no need to write header files - yes 3. implementation obfuscation - no 4. hygiene - yes (3) is not, in my opinion, a solvable problem because the compiler needs, one way or another, far too much information about the template definition to hope one could conceal it from a determined user. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mathias Gaunard on 26 Jul 2010 07:48
On Jul 26, 3:06 pm, James Kanze <james.ka...(a)gmail.com> wrote: > 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). The C++ standard doesn't even know about dynamic linking, does it? In any case, it seems to me quite reasonable that certain features may not be used across dynamic linking boundaries. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |