Bo Persson wrote:
Walter Bright wrote:
>My beef with class is that it's also in the tag name space. The tag
name space is a language design mistake.
I guess so. I don't seem to write code where it matters, so it's not a
big deal for me. Perhaps more of a problem to compiler writers?
It's not too much of a problem in C because the lookups are always
qualified with 'struct' or 'union', but it's a bit of a mess in C++. The
names default to being in the main space, but then are pushed into the
tag space if there are any other declarations with the same name. The
semantic analyzer has to look in the tag space if it's expecting to see
a class name based on the context, after first looking in the regular
space and finding a name that isn't a tag. It's just goofy - and it
didn't have to be that way.
>With the D programming language there was a chance to fix that.
Structs are for POD, classes are for objects, and both are in the
regular name space (there is no tag name space in D).
So it seems that there really _were_ reasons to keep the structs
unchanged. Some of the memcpy-guys are now arguing that they need a
pod_struct or something, to have the compiler assure the POD-ness of
their data.
POD objects and OOP objects are just different and serve different
design goals. I think that any code design that tries to mix them
together (with, say, inheritance) is probably a mistake. People coming
to D programming from C++ at first find the struct(POD)/class(OOP)
dichotomy to need a bit of getting used to, but once they do, the
feedback on the choice is clearly positive.
Structs and classes are like ints and floats. Sure, you can use a float
as a loop counter, but it's just not meant for that.
So, keeping structs as C-style PODs might have been a good idea after
all. But now there is *way* too much C++ code to make such a change.
I agree. C++ is boxed in by legacy code based on decisions made 20 years
ago. This happens, of course, to all successful languages.
>Both class and struct default to public.
Typing an additional "public:" per class definition is not big deal,
and it also serves as documentation. Making it optional could satisfy
both sides, of course.
It's a minor thing, I agree. It's like a story my father told me. We
lived in a small town, and he once asked the mayor what the biggest
problem he faced was. The mayor replied that the town was evenly divided
between dog lovers and dog haters. Neither side could gain ascendancy,
so his work was occupied with constantly trying to compromise and
reconcile the two <g>.
Walter Bright
http://www.digitalmars.com
C, C++, D programming language compilers