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: Andre Kaufmann on 29 Jul 2010 22:18 Dragan Milenkovic wrote: > On 07/28/2010 10:22 PM, Andre Kaufmann wrote: > [...] > I understand your views on this subject. Let's meet in the middle > and accept that the best option would be if it could work both ways. > The same syntax can be used no matter whether a "module" is > in one file or three. > > (I actually don't mind... actually prefer... using three when templates > come into play: foo.h, foo.cc, foo.tcc). I would agree on that "freedom" of choice, how many files a module uses, if it doesn't imply that modules will suffer from the same problems as currently header files in combination with macros have. The developer doesn't mind, but the compiler vendors and tool vendors will mind if modules are using only one file or can be spread to multiple files. Sometimes restrictions are better, because they reduce complexity - which IMHO is one of the main reasons to introduce modules. If modules are introduced, the developer would be free to use "old" style or the new module style anyways. After the introduction of single file modules it would be still possible, to check what implications a "multiple files module concept" will have and then introduce them later into the standard. Andre -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Keith H Duggar on 30 Jul 2010 03:53 On Jul 29, 9:15 am, Walter Bright <newshou...(a)digitalmars.com> wrote: > Francis Glassborow wrote: > > 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. > > Why do namespaces fail to resolve this issue (aside from the preprocessor)? For one there is a need for automatically generating unique easy to use one-off names for helper/detail functions etc. Currently anonymous namespaces do this per translation unit. So I can without fear use short generic names for helpers etc for example: a.cpp namespace { void dump ( ) { ... } } b.cpp namespace { void dump ( ) { ... } } if both a.cpp and b.cpp are included at the bottom on the ..hpp file then when that .hpp is eventually included in some ..cpp translation unit there will be name clashes. The problem turns from annoying to dangerous when there are overloaded helper/detail functions because then instead of getting ambiguity errors your code just silently changes. And, no, forcing users to generate their own unique names for helper namespaces (ala private_someunique) and requiring them to prefix throughout and/or telling them they should just nest everything into their already unique class name (ala Java) are not acceptable "solutions". We would need a replacement that is as simple and easy to use as separate unique translation units. KHD -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Bo Persson on 30 Jul 2010 03:54 Louis Lavery wrote: > On 29/07/2010 14:15, Walter Bright wrote: >> Francis Glassborow wrote: >>> 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. >> >> Why do namespaces fail to resolve this issue (aside from the >> preprocessor)? > > I #include the implementation file (.cpp) at the foot of the header, > and it seems to work okay for me. I'm trying to fathom what Francis > means by "interacting in undesirable ways". > Anyone care to give a hint? > For example, it will make your .cpp file see #defines from other .cpp files included earlier. It also changes the meaning of anonymous namespaces in the implementation files, as well as potentially causing ODR violations for free function definitions. Bo Persson -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Louis Lavery on 30 Jul 2010 10:13 On 30/07/2010 19:54, Bo Persson wrote: > Louis Lavery wrote: >> On 29/07/2010 14:15, Walter Bright wrote: >>> Francis Glassborow wrote: >>>> 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. >>> >>> Why do namespaces fail to resolve this issue (aside from the >>> preprocessor)? >> >> I #include the implementation file (.cpp) at the foot of the header, >> and it seems to work okay for me. I'm trying to fathom what Francis >> means by "interacting in undesirable ways". >> Anyone care to give a hint? >> > Thank's for the clarification, Bo. > For example, it will make your .cpp file see #defines from other .cpp > files included earlier. > I rarely use #defines (apart from the include guards in my .hpp and ...cpp files), and when I do it's a #define in a header and the #ifdef or #ifndef in the .cpp or .hpp. So it's not a problem for me. That may be because of the nature of the code I write. > It also changes the meaning of anonymous namespaces in the > implementation files, as well as potentially causing ODR violations > for free function definitions. > Yes, I miss anonymous namespaces in my template .cpp files. I get round it by using a unique namespace name (the same as used in the #include guard) in each .cpp file, but of course that's not quite the same thing, as I have to qualify calls or employ a using directive or whatever. But lack of anonymous namespace seems to be becoming less of a problem since I started to use a test driven development approach to writing code. Even in non-templated code, if the stuff in the anonymous namespace gets to any size then I factor it out into its own files, for testing purposes. Still, for those little functions that help clarify/commment the main code, anonymous namespace is handy. I like header files. As others have said, they separate the interface from the implementation, and so make it much easier to understand what the piece of software is supposed to do (if it doesn't, and I find myself looking in the .cpp, then I know it's time a fixed the header). Do modules facilitate separation of the i/f from implementation, or are they more useful to the compiler than the programmer? If so, I'm against them! Louis. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Timothy Madden on 30 Jul 2010 11:24
Zeljko Vrba wrote: > 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 The problem is impl.cpp may have stuff that should be visible only there, where by including it in the header you make the entire implementation public. Think about writing some non-template function there, that I use to implement my templates. Sooner or later, you end up with yet another implementation file (when you though you already have one). Thank you, Timothy Madden -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |