Re: C++ Frequently Questioned Answers
Alex Shulgin wrote:
"Very complicated type system"
I'll quote that a bit to bring in some context:
For example, if your function accepts const std::vector<const
char*>& (which is supposed to mean "a reference to an immutable
vector of pointers to immutable built-in strings"), and I have a
std::vector<char*> object ("a mutable vector of mutable built-in
strings"), then I can't pass it to your function because the types
aren't convertible. You have to admit that it doesn't make any
sense, because your function guarantees that it won't change
anything, and I guarantee that I don't even mind having anything
changed, and still the C++ type system gets in the way and the only
sane workaround is to copy the vector.
The interesting thing is the OP chooses to criticise something that is much
harder or impossible to do in languages he seems to prefer. How do you say
'immutable Foo' in Java or C#? You can't and are left with coding guidelines
like 'make your classes [always] immutable' (see for example Effective Java
book) which are there for a good reason. The same reason C++ has const in
the language.
When you do try to make things immutable but still need to modify them from
time to time you hit exactly the same problem as in his C++ example. There
are three known ways of having 'immutable Foo' in popular languages.
One is to have two distinct classes, like Java's String and StringBuffer.
One of them is immutable, another is not and they can be freely converted to
each other. This is the 'recommended' approach but if you do this you will
quickly discover that you can't pass List<StringBuffer> to a function
expecting List<String>. Just like in C++ only worse becasue there is no
solution to it.
Another approach is to have something like (in C++ notation)
struct ImmutableFoo
{
virtual int GetValue() = 0;
};
struct MutableFoo : ImmutableFoo
{
virtual void SetValue(int val) = 0;
};
struct Foo : MutableFoo
{
int GetValue();
void SetValue(int val);
};
Unfortunately, you still cannot pass List<Foo> to a function that expectes
List<ImmutableFoo> (for the same reason arrays are not polymorfic in C++).
However, now it is possible to do something about this and the solution is
along the lines suggested for C++. You make the function a generic that
accepts List<anything derived from ImmutableFoo>.
This approache to constness sort of works but badly. It is intrusive,
doesn't scale well (what if Foo concept itself is polymorphic?) and so is
rarely used.
Finally you can do what Java collections do, namely provide a wrapper that
fails mutating methods at runtime. Something like (in C++ notation again)
struct Foo
{
virtual int GetValue() = 0;
virtual void SetValue(int val) = 0;
};
struct FooImpl : Foo
{
int GetValue();
void SetValue(int val);
};
struct ImmutableFoo : Foo
{
int GetValue()
{ return impl.GetValue(); }
void SetValue(int val)
{ throw some_exception(); }
Foo impl;
};
This "works" since you will only have List<Foo> as the parameter to any
function. The price you pay is detecting violations of const correctness
only at runtime.
Now which language's type system makes things more complicated?
--
Eugene
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]