Re: C++ Frequently Questioned Answers
On Nov 2, 6:42 pm, Yossi Kreinin <yossi.krei...@gmail.com> wrote:
On Oct 28, 8:01 pm, Alex Shulgin <alex.shul...@gmail.com> wrote:
"No compile time encapsulation"
This item implies that you have to ship the implementation class
declaration to clients, which is not necessarily true. Have you ever
heard about abstract classes ("interfaces")?
I know the ways to work around the problems with private:
I think you have severely misunderstood the "Defining interfaces is
hard, throwing together an implementation is easy." part of the
original FAQ item. From my experience, it is really harder to define
interfaces than providing implementation, since making changes to an
interface have much bigger costs than making changes to the
implementation. Designing the interfaces the way you never have the
need to change them, or at least minimizing the changes in future is
what exactly makes it hard (up to the point being harder than
This, of course, applies not only to C++ but to any interface/
implementation problem in general. ;-)
Have never used pimpls, so no comments this time. :-)
http://yosefk.com/c++fqa/class.html#fqa-7.5 (incomplete types)
This is interesting, and I agree that the original FAQ item is
(possibly intentionally) wrong. However, could you please elaborate
on the last sentences:
"C++ is extremely unsafe because every pointer can be used to modify
every piece of memory from any point in code."
An example (i.e. some real code) would be very helpful.
However, workarounds aside, C++ does have private, and there's a
separate question of whether it's useful or not. I claim that the
advantages (getting a compile time error when someone accesses a
member you didn't want them to) are dwarfed by the drawbacks. Most C++
classes are neither pimpls nor implementations of base classes (that
takes manually written wrapper/bridge code) and of course not C-like
incomplete types (naturally, people most often use C++ classes when
they program in C++). Changes done to the private members of those
classes are responsible for a significant amount of time spent for
rebuilding C++ code (of course I don't have numeric data proving this,
and you don't have numeric data refuting this; all we can do is to
point out the things that happen, not to measure their importance).
Agreed, except for the "most" part... How do you know they really
"No run time encapsulation"
I'm not claiming that every language should have run time
encapsulation. Frequently, language features can not be judged by
themselves, but only if you consider how they interact.
The problem with having no run time encapsulation /in C++/ is that the
language has no reflection and several different and non-trivial
commercially significant ABIs. This means, for example, that when a
program crashes, figuring out what's going on in the core dump is hard
compared to, say, a program compiled from C source (C doesn't have
reflection, either, but maps more straight-forwardly to executable
Personally, I don't having recall that sort of problems... But may be
you can clarify on what exactly makes it harder as compared to C
dumps? I can think of inlining and templates... Anyway that's quite
natural and expectable, since the language itself is way more complex
"No binary implementation rules"
Frankly, I don't see your point here. You have tried to link g++-
compiled libraries with msvc-compiled code, or what exactly?
I didn't, because I know it doesn't work. I wish it did though. Are
you saying that this is a non-problem, and if so, why?
Well, it was never a problem for me, and I wish I'd never have this
one. Is sticking to a single compiler a problem to anyone?
Anyway, I don't recall myself applying cv-qualifiers to the type of
contained elements in a sensible and useful way. Anyone?
What about when you fill your vector with objects obtained by calling
a method returning a const reference in a loop?
As others have noted it would be extremely nice to have an example for
this one. Let's get to some real code already. :-)
... Exception safe C++ code is almost infeasible to achieve in a
Maybe, if you prefer to write everything from scratch instead of
trying to stick to standard library.
What about when you need a subset of objects kept in std::vector or
std::list, and the owning collection is about to be deallocated,
because you only need some of the objects, but not all of them
Another example please? From what I can see it's all about storing
raw pointers in the containers... very suspicious.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]