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 27 Jul 2010 06:48 On 2010-07-27 10:42, Timothy Madden wrote: > It is a useful feature. Separating declaration from implementation is > good practice that all programmers should follow. I agree with this. I don't like visually cluttering specification with implementation. Even if there were no other benefits, I would see separating those things as a desirable feature of export. On the other hand I understand that there is a cost/benefits ratio to consider here. For example even now it is possible to declare templates in one part of a (header) file and then provide their implementations in a later part of that file. One can put a big bold comment block across the middle of the file that says, in effect, "Below are implementation details." Peter -- [ 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 14:32 Timothy Madden wrote: > Walter Bright wrote: >>> 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, Not in a way that makes (exported templates + precompiled headers) faster at compiling than (precompiled headers). > and a lot, as symbol tables is what they work with. Don't get me wrong, I'm not criticizing you for being enthusiastic about this feature and thinking it will work. Often times, fundamental advancements are made by people who reject the conventional wisdom and find a way. The source code is available for many C++ compilers, including g++ and Digital Mars C++. Feel free to organize some like-minded developers and try out your ideas. > 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 ? Not for me. I don't care for wishy-washy standards with optional features. Furthermore, if making it a required feature didn't get it adopted, making it optional isn't going to make it more palatable. The best way forward for you is to develop this feature yourself, and prove it works, delivers real benefits and has a sizable constituency, then take it to the Committee with an incorporation proposal. The "I think it will work, let's standardize it and hope for the best" approach has already been tried and failed. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Peter C. Chapin on 27 Jul 2010 15:42 On 2010-07-27 17:39, Andre Kaufmann wrote: > What's the real benefit of using multiple files for code which makes up > a single code module - did I miss something ? It separates design from implementation. When I'm designing a program I can work in the header files... organize the namespaces, define the classes and their relationships (along with their methods), and declare necessary supporting functions. I can do all of this without thinking about implementation details or writing one line of code into a .cpp file. Once my design is somewhat in hand I can then start building the implementation (the .cpp files). Separating a module into two files encourages me to separate design and implementation in my mind. I find this very beneficial. Of course the separation isn't perfect because the private part of classes is implementation material. Still, I find it far better than, for example, Java where design and implementation are co-mingled in a single file and sometimes hard to separate mentally (without using an unnatural style anyway). In Ada one can even separately compile package specifications (it's not necessary for the bodies to be present). This allows the compiler to perform some consistency checks on my design before I even start writing the implementation. I have often found significant design errors this way. I think it's a great way to work. Peter P.S. When Ada was first being designed some thought was given to the idea of using *three* files for each package: the public specification, the body, and the private part of the specification. The last file would contain the material the compiler needed to know to compile clients of a package but that was logically part of the implementation. This would have created a very clean separation of design and implementation and I rather wish the language had done that. Apparently it was decided at the time that people would find it just too tedious. -- [ 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 15:40 On 07/27/2010 11:39 PM, Andre Kaufmann wrote: [snip] > > What's the real benefit of using multiple files for code which makes up > a single code module - did I miss something ? Because I want to look at some library's header file and see only things that I need for using the library. And I like it more if it is human written, with comments and with functions and other entities ordered maybe by usage or some other logic and not by their names... such things... Least of all would I want to see the implementation. Even the representation and private: stuff is already way too much. This applies even when I am developing the same library... Sometimes I just want to see (and change) the interface. Then later maybe I dedicate my time to the implementation. And if the maintenance of two files requires too much effort, then I would argue that their interfaces became fat and need refactoring... This was my argument against putting it all in one file, not generally against modules. Find a way to put private stuff away and I'm all ears... :-) -- Dragan [ 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 15:41
Walter Bright wrote: > Dragan Milenkovic wrote: > [...] > 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. I don't know why it's a must to be able to obfuscate the implementation. In Open Source code it doesn't matter and in commercial libraries / components it's rather a sales argument to ship the sources too, to be able to fix bugs / debug / or use another compiler, since theres no ABI compatibility between different compilers. And if you want to hide secret knowledge, it's IMHO only an illusion that this information can be hidden by obfuscation / compilation. Anyways, obfuscation IMHO could be reached by: a) Simple code reformat obfuscators: Replace every internal variables and functions by a single character. Remove carriage returns etc. - the code is then hardly readable and not usable, besides it's normal usage as a library b) Precompilation - the compiler could use a binary format, which can be compiled as normal source code too. Same as a) but a bit more obfuscated Andre -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |