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 28 Jul 2010 10:25 On 2010-07-28 16:22, Andre Kaufmann wrote: > 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. One potential advantage of two files is that certain people (designers, senior programmers) could be given write access to the interface in the header files whereas the junior programmer could be given just read-only access. This means that junior programmers couldn't (as easily) make sweeping design changes without review. I realize... 1. It doesn't really work because the private part of classes appears in header files and that is part of the implementation. That's why it would have been nice if the private part of classes could be separated out somehow as well. 2. A suitable tool could enforce access control over the individual parts of a file. Are there any tools like that currently? I haven't heard of one. > 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 ? I don't want to have to constantly remind myself what is and is not part of the interface to a module. To keep my code organized, I like putting the externally visible material in a separate file where it's special status is completely explicit. 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 28 Jul 2010 22:15 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 have my own ideas, but I'd like to hear what others think.) -- [ 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 22:48 Peter C. Chapin wrote: > On 2010-07-28 16:22, Andre Kaufmann wrote: > > [...] > One potential advantage of two files is that certain people (designers, > senior programmers) could be given write access to the interface in the > header files whereas the junior programmer could be given just read-only > access. This means that junior programmers couldn't (as easily) make > sweeping design changes without review. I just wonder, why would you have write access to the interface, but not to the implementation. If you change the interface it wouldn't compile at all or you can't prevent the junior developer to write an inline function in the interface at all ? > I realize... > > 1. It doesn't really work because the private part of classes appears in > header files and that is part of the implementation. That's why it would > have been nice if the private part of classes could be separated out > somehow as well. > > 2. A suitable tool could enforce access control over the individual > parts of a file. Are there any tools like that currently? I haven't > heard of one. Not yet, implementations which use this strategy allow access to all lines in the file. >> 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 ? > > I don't want to have to constantly remind myself what is and is not part Why do you have to remind yourself. If (for example) the private part would be collapsed, you would see the interface (functions collapsed too). If you hover the cursor / or click with the mouse over the interface you could change the implementation. Optionally the compiler would allow separation, where really needed. >[...] > Peter Andre -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Louis Lavery on 29 Jul 2010 00:09 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? Louis. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Dragan Milenkovic on 29 Jul 2010 07:09
On 07/28/2010 10:22 PM, Andre Kaufmann wrote: > Dragan Milenkovic wrote: [snip] >> 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. [snip] >> 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 ;-) ] I admit I am one... :-) Although if I found an IDE decent enough to satisfy the basic set of my needs, I wouldn't mind using it. 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). -- Dragan [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |