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: Kaba on 28 Jul 2010 05:22 Dragan Milenkovic wrote: > 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... :-) That does not require export, here's what I do: 1) Write declaration files (.h) as usual, with the function declarations and class definitions, but not with the class function definitions. 2) At the bottom of the declaration file (.h), #include the definition file (.hpp) (see an analog .h + .cpp and .h + .hpp). (Optional) 3) At the top of the definition file (.hpp), include the declaration file (.h). And here's an example. http://kaba.hilvi.org/pastel/pastel/geometry/sphere.h.htm (Note: the #includes work as links) The only thing that's inconvenient is that when there are lots of template parameters, you need to write lots of template boilerplate to write the class member function definitions outside of the class. I was hoping for C++0x to solve this (maybe with some "class namespace"), but thus far the only aid I'm seeing is the alternative function declaration syntax helping. -- http://kaba.hilvi.org [ 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 28 Jul 2010 05:23 On 2010-07-28 01:32, Walter Bright wrote: > 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. It probably makes sense to do this with the module proposal rather than with export. If one reviews the literature on export it is easy to see that there are many problems and concerns with it. An experimental implementation of C++ modules would probably be a greater service to the community at this point than fighting with export. Peter -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andre Kaufmann on 28 Jul 2010 05:22 Dragan Milenkovic wrote: > 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 A good tool can present the interface separated from the implementation, a dumb editor however not. > 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... Yes, but what's the advantage over separation in a single file. One single file includes both, interface >and< implementation. The separation could be done by a single keyword, which tells the compiler that after this keyword the code for implementation follows. > 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... :-) As I wrote above, most editors either have collapsing, that you will see only the interface or a good class browser. It shouldn't be the task of the developer to do what the computer IMHO could do better - or should it ? [This won't work however for die hard text editor developers ;-) ] Andre -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Francis Glassborow on 28 Jul 2010 05:23 Dragan Milenkovic wrote: > 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... :-) > So don't just #include the implementation file at the end of the header file. However this still has a far more important problem that I have not seen anyone mention in this thread, when files are included together they can start interacting in undesirable ways. That is why I greatly favour the module proposal that is currently sitting on the back burner until the curent work is done and dusted. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Martin B. on 28 Jul 2010 05:21
Dragan Milenkovic wrote: > 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... > [...] Of course all of this is trivial to generate from a single file, so the argument seems moot for a library, where you would just have a simple generated (e.g. html) file with the public interface instead of the header to look at. cheers, Martin -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |