Re: #pragma once in ISO standard yet?
On Dec 18, 9:09 pm, akfmn...@t-online.de (Andre Kaufmann) wrote:
James Kanze wrote:
[...]
These languages as well support abstract interfaces. Such an
interface plays the part of separation you are demanding.
It's used for that, the same as textual inclusion is in C++.
See my response to Alf.
I don't think so. You can't separate specification from implementation
in C++ just by using header files. Impossible.
You will always have the private part - variables - inside the header
file. Which, I'm just using your words ;-), is bad software engineering
since this part of the class is implementation specific and shouldn't be
in the header file -> what can you do in C++ ?
a) Use pimpl
b) Use Interfaces, the workaround needed in other languages !
It's a hack. I agree. The compilation firewall idiom helps,
but of course, ideally, we wouldn't need it (and there are times
when it really isn't applicable). Using interfaces is a
different hack. It has more or less the opposite problem---you
can't get all of the specifications in the interface, since
constructors, etc. are missing.
On the whole, I prefer the C++ hack, but that's probably at
least partially because I'm used to it, I've been using it for
many years, and I know how to manage it. (I've also worked on a
C++ project where we did use interfaces, rather than the
compilation firewall idiom.)
[...]
IMHO, C++ could benefit with some additional categorization
of member functions: override and final, for example, come
to mind. Whether the benefit is worth the effort is another
problem; I'll admit that in practice, I've not seen a lot of
errors due to this.
You won't get an error, that is the problem.
Having working code is a problem?
As you wrote as argument for #pragma once, it might cause
trouble more often as you think ;-). It happens from time to
time if you are dealing with template base classes, to which
you pass the abstract interface as a template parameter.
Additionally more often if you are using meta template
programming. I'm not using that combination anymore, because
in C++ I can't simply control if I have successfully
overridden a virtual function of the base class.
As I said, I've never seen this to be a concrete problem in
actual code. It certainly could happen, and I'd certainly
prefer a means of making such errors detectable by the compiler.
Because it's not been an actual problem in my experience,
though, such changes are not high on my list of priorities. Not
making the language more complicated than it already is is high
on my list, so if the proposals to allow these problems to be
errors detected by the compiler increase the complexity of the
language, I'd be sceptical. It's a question of degree, however,
and if the additional complexity were minor, and the additional
checking really robust, why not?
[...]
The implementation is in a .tcc file, the specification in a
.hh.
It's IMHO not a true separation. You have to include the .tcc file if
the compiler doesn't support export.
Totally agreed. But it's better than nothing. For the issues
we were discussing, it's sufficient, since the two files are
managed separately by version control, but there's still a lot
of unnecessary compile time coupling.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S9mard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]