Welcome. MLT: > D is really an amazing language!<
Yep. >It really is everything that C++ did not manage to be, at least as far as my >limited experience with it shows.< I also hope D will never be lot of the things C++ is, because C++ is too many things :-) > 1. struct vs. class As far as I understand, these two reserved words, that in > C++ mean very similar things, in D are very different.< C++ classes are like structs, but their methods are private by default. In D structs have value semantics, are copied by value and keep the given order of the fields, while classes have reference semantics, are often allocated on the heap, and the compiler in theory can change the order of fields in memory. They are designed for different purposes, and I agree with such decision by Walter. C# has chosen in a similar way. But later practice has shown that you want struct constructors, and other things, so now D2 has them too. So structs are a bit closer to classes now in D2. >A class variable is "really" a pointer, whereas a struct is directly allocated >memory.< A class is a "reference". There are some ways manual or automatic with "scope" to sometimes allocate classes on the stack to improve performance. I have seen that sometimes it gives a nice speedup. You can't create an array of scoped classes by normal means, you have to manually change the way they allocate memory. Generally you can do what you want, but you may need some work to do special kinds of memory allocation. >What I don't like is that it seems that structs and classes should almost be >interchangeable - one might implement something as a class and later want it >to be a struct, or vice versa. It almost is actually a local decision. I might >want something to be a class in one place, and a struct in another.< In D they are by design different, because most of the times you want just one of the meanings. >It seems to me that these are 3 different issues, and one should have control >over them separately.< Giving control over each thing is of course nice and it may even increase performance in special situations. But it surely leads to an increase of the complexity of the language (and its use). D tries to be less complex than C++ (and C++ today is probably one of the most complex languages, and such very high complexity is now slowly killing it), and this means that sometimes you have to give up on some flexibility. If the language is well designed then most of the times, in practical programs, you don't feel much of such limitations. >Otherwise, it seems to me that a program that uses both (struct and class) can >get mightily confusing.< It's confusing if you are used to program in a language like Python, where everything acts according to a reference semantics (more or less, it's not exactly like that, it's a name-semantics). But D is more complex and powerful than Python, and lower level too, and it gives you both reference and data semantics. Once you know that, you just have to keep in memory that classes are by reference and structs are by values, and you can live well (you can also have pointer to structs. I think I have never used a pointer to class in D yet). > Maybe the solution is to not use struct (which is I guess what is recommended > unless you really need it.)< Structs are useful in D because classes have some overhead in both memory, and their methods are always virtual (and all the current D compilers are unable to devirtualize such methods, maybe not even GDC is able to do it, even if G++ is sometime able to devirtualize C++ virtual methods, I think it's the only C++ compiler able to do that)), and being usually allocated on the heap (D compilers aren't like HotSpot that is sometimes able to allocate classes on the stack when it is sure they not exit the scope) they aren't fit if you for example need small [x,y] vectors. > 2. char[] vs. int[] > I think it is strange that > char[] x = "1234" ; > x[0] = '4' ; > > Produces a run time error, but > int[] x = [1,2,3,4] ; > x[0] = 4 ; > Doesn't. I think that they both should, or both shouldn't - to be consistent > (and it would be better if they both didn't). I leave this to other people. in D2 strings are immutable, by the way, while static arrays are not. >Best would be again, to allow the programmer to specify where the array (or >other stuff) should be stored.< That requires you to pay some complexity. And D designers/programmers may be unwilling to pay it. >Given that, it is even sadder than it is in C++, that one can not inherit from >the basic types.< Yes, this is a problem of D2. Scala language shows that there are better ways to design types, as you say. Walter has recently changed the D2 language to allow a bit of this, using "this". With that you can define a struct that behaves for example like the built-in associative array, and you don't need to redefine all its almost-methods. Bye, bearophile
