After converting a large, system-level program to D, I can name the biggest problems:

1) No stack-trace on exceptions.
This makes contract programming a mere QA test, rather than a useful debugging tool.

2) No 64-bit support.
This not only limits memory usage, but also causes 2x runtime on my AMD processor.  My D code is the same speed as my 32-bit C++ code, but both are 2x slower than 64-bit C++ code.  Same compiler.  Same machine.

3) Lack of forward declarations.
The compiler figures everything out in simple cases, but it gets very confused with templates.  That dramatically hurts the genericity of D, since it limits what templates can do.  One nice use of templates in C++ is to set a static variable on a type, as a sort of "property" with high-speed access.  With D, I have accomplished this only by putting all templates in the same file.

This problem also causes the compiler to depend on the order of files on the command-line.

4) Not enough help for converting between D strings and C char*.
There must be conversion functions which work regardless of whether the D string is dynamic or not, and regardless of whether the C char* is null terminated.  I'm not sure what the answer is, but this has lead to a large number of runtime bugs for me as a novice.

5) Same syntax structs and classes.
This is minor problem, but it is extremely confusing to the novice.  A struct and a class are completely different in D, but the fact that I can write code the same to use either one implies too much similarity.  It leads to programming errors which easily result in seg-fault.

Also, it is too difficult to switch a set of objects from structs to classes or vice versa.  I need to be able to do that in order to compare runtimes for various implementations.  Again, I don't know the best answer.


I love the language as an evolution of C++, so I really hope these problems get ironed out.  I could list a *lot* of great things about D!

C. Dunn wrote:
> 1) No stack-trace on exceptions.
> This makes contract programming a mere QA test, rather than a useful debugging tool.

on windows you can use ddbg (http://ddbg.mainia.de) to get full stack-traces for all exceptions

C. Dunn Wrote:


> 5) Same syntax structs and classes.
> This is minor problem, but it is extremely confusing to the novice.  A struct and a class are completely different in D, but the fact that I can write code the same to use either one implies too much similarity.  It leads to programming errors which easily result in seg-fault.
> 
> Also, it is too difficult to switch a set of objects from structs to classes or vice versa.  I need to be able to do that in order to compare runtimes for various implementations.  Again, I don't know the best answer.

I agree with the rest of your post, but IMO this would make using classes confusing, C++-style. Structs as value-types and classes as reference-types is one of the hallmarks of D and value types + inheritance just makes everything harder (slicing, etc.), and one of D's advantages is that it's a lot simpler to do what you want without ambiguity. Just my opinion, though.

I esp. agree on stack tracing, though. Debuggers are nice, but not everyone runs their code under a debugger all the time. I tried Tango + Flectioned, which ran great under Linux, but since I develop on/for Windows, this isn't helpful.

C. Dunn wrote:
> 4) Not enough help for converting between D strings and C char*. There must be conversion functions which work regardless of whether
> the D string is dynamic or not, and regardless of whether the C char*
> is null terminated.  I'm not sure what the answer is, but this has
> lead to a large number of runtime bugs for me as a novice.
> 

The std.string module has the toStringz and toString functions.

The toString function simply returns a slice over the C string:

char[] toString(char* ptr) {
	return ptr[0 .. strlen(ptr)];
}

The toStringz function simply appends a null character (\0) to the end
of the D string:

char* toStringz(char[] str) {
	return (str ~ \0).ptr;
}

These are very simple operations, and it is fairly easy to adapt
them to whatever needs you have.

> 5) Same syntax structs and classes. This is minor problem, but it is
> extremely confusing to the novice.  A struct and a class are
> completely different in D, but the fact that I can write code the
> same to use either one implies too much similarity.  It leads to
> programming errors which easily result in seg-fault.
> 
> Also, it is too difficult to switch a set of objects from structs to
> classes or vice versa.  I need to be able to do that in order to
> compare runtimes for various implementations.  Again, I don't know
> the best answer.
> 

Structs and classes are very different beasts in D, even if they look the same. However, there are some important differences in their use which should clue you in:

Using 'new' on a class gives you a reference, using it on a struct gives you a pointer.

Structs are plain ol' data. Saying "SomeStruct s;" gives you an instance you can immediately behind using. You have to use 'new' to get a class instance.

Classes have inheritance and all those other object-oriented features, while structs do not.

What I am getting at is that whether something should be a class or a struct seems like an important design decision which shouldn't be expected to change after development is well underway. Also, code doesn't really look all that similar when it uses structs vs. classes.

> 
> I love the language as an evolution of C++, so I really hope these
> problems get ironed out.  I could list a *lot* of great things about
> D!
> 

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org

C. Dunn wrote:
> After converting a large, system-level program to D, I can name the biggest problems:

> 2) No 64-bit support. This not only limits memory usage, but also
> causes 2x runtime on my AMD processor.  My D code is the same speed
> as my 32-bit C++ code, but both are 2x slower than 64-bit C++ code.
> Same compiler.  Same machine.

Been asked for many-a-time. I believe GDC, now supports 64-bit compilation.   http://dgcc.sourceforge.net/

The problem is that the linker used by DMD is some ancient thing written in assembly that ain't never gonna get upgraded to 64bit.
A new linker must be found or written eventually.  Unless someone interested in helping with that comes out of the woodwork, it's probably going to mean a 6-12 month halt in progress for D as Walter goes off to write a new linker.    I think few people want that to happen to D, at least not until the language has all its issues pretty much worked out.

> 3) Lack of forward declarations. The compiler figures everything out
> in simple cases, but it gets very confused with templates.  That
> dramatically hurts the genericity of D, since it limits what
> templates can do.  One nice use of templates in C++ is to set a
> static variable on a type, as a sort of "property" with high-speed
> access.  With D, I have accomplished this only by putting all
> templates in the same file.
> 
> This problem also causes the compiler to depend on the order of files
> on the command-line.

Been asked for many-a-time.  I think the problem is again the black-box linker that no one knows how to fix.

--bb

Kirk McDonald wrote:
> C. Dunn wrote:
> 
>> 5) Same syntax structs and classes. This is minor problem, but it is
>> extremely confusing to the novice.  A struct and a class are
>> completely different in D, but the fact that I can write code the
>> same to use either one implies too much similarity.  It leads to
>> programming errors which easily result in seg-fault.
>>
>> Also, it is too difficult to switch a set of objects from structs to
>> classes or vice versa.  I need to be able to do that in order to
>> compare runtimes for various implementations.  Again, I don't know
>> the best answer.
>>
> 
> Structs and classes are very different beasts in D, even if they look the same. However, there are some important differences in their use which should clue you in:
> 
> Using 'new' on a class gives you a reference, using it on a struct gives you a pointer.
> 
> Structs are plain ol' data. Saying "SomeStruct s;" gives you an instance you can immediately behind using. You have to use 'new' to get a class instance.
> 
> Classes have inheritance and all those other object-oriented features, while structs do not.
> 
> What I am getting at is that whether something should be a class or a struct seems like an important design decision which shouldn't be expected to change after development is well underway. Also, code doesn't really look all that similar when it uses structs vs. classes.
> 

I don't agree here. I had all my algebraic classes (vectors, matrices, transforms, etc.) as structs, as they needed to be value types, and for performance. However, I had to convert several of the more complex structs to classes instead, when I needed reference semantics.

Since structs use a different constructor syntax, along with 'this' versus '*this', it was quite annoying. Since the only difference the original spec highlighted was that one in a reference type, and one a value type, it seems silly to have large syntactical differences between them. In particular, that structs lack meaningful constructors/destructors/copying semantics is *really* annoying. Value types are scoped, so why not let us use that to our advantage?

"Tristam MacDonald" <swiftcoder@gmail.com> wrote in message news:f9gm20$2jd6$1@digitalmars.com...
>
>
> Kirk McDonald wrote:
>> C. Dunn wrote:
>>
>>> 5) Same syntax structs and classes. This is minor problem, but it is
>>> extremely confusing to the novice.  A struct and a class are
>>> completely different in D, but the fact that I can write code the
>>> same to use either one implies too much similarity.  It leads to
>>> programming errors which easily result in seg-fault.
>>>
>>> Also, it is too difficult to switch a set of objects from structs to
>>> classes or vice versa.  I need to be able to do that in order to
>>> compare runtimes for various implementations.  Again, I don't know
>>> the best answer.
>>>
>>
>> Structs and classes are very different beasts in D, even if they look the same. However, there are some important differences in their use which should clue you in:
>>
>> Using 'new' on a class gives you a reference, using it on a struct gives you a pointer.
>>
>> Structs are plain ol' data. Saying "SomeStruct s;" gives you an instance you can immediately behind using. You have to use 'new' to get a class instance.
>>
>> Classes have inheritance and all those other object-oriented features, while structs do not.
>>
>> What I am getting at is that whether something should be a class or a struct seems like an important design decision which shouldn't be expected to change after development is well underway. Also, code doesn't really look all that similar when it uses structs vs. classes.
>>
>
> I don't agree here. I had all my algebraic classes (vectors, matrices, transforms, etc.) as structs, as they needed to be value types, and for performance. However, I had to convert several of the more complex structs to classes instead, when I needed reference semantics.
>
> Since structs use a different constructor syntax, along with 'this' versus '*this', it was quite annoying. Since the only difference the original spec highlighted was that one in a reference type, and one a value type, it seems silly to have large syntactical differences between them. In particular, that structs lack meaningful constructors/destructors/copying semantics is *really* annoying. Value types are scoped, so why not let us use that to our advantage?

Agreed.  I think Walter has plans to add constructors/destructors/copying semantics to structs.  It's a welcome change.

-Craig 

C. Dunn a écrit :
> After converting a large, system-level program to D, I can name the
> biggest problems:
[]
> 2) No 64-bit support. This not only limits memory usage, but also
> causes 2x runtime on my AMD processor.  My D code is the same speed
> as my 32-bit C++ code, but both are 2x slower than 64-bit C++ code.
> Same compiler.  Same machine.

2x?
Your code must do a lot of 64b computation!

When the AMD64 was released benchmarks made showed at best a 20% improvement, which is quite a lot to get with a simple recompilation assuming the code is 64b clean of course but is nowhere 2x.

Either your code makes a lot of 64b computations or there are issue on the 32b version of your C++ code.

That said, its a problem with DMD not with D, if memory serves GDC supports 64b code generation.

renoX

> Been asked for many-a-time. I believe GDC, now supports 64-bit compilation.   http://dgcc.sourceforge.net/

At least for me 64 bit gdc works very fine atm (on linux).

> Been asked for many-a-time.  I think the problem is again the black-box linker that no one knows how to fix.

Would it be easier/less work to have dmd output the "standard" windows
object format then write a new linker? (I dont remember the exact name
of that beast)
I mean finding linkers for that wouldnt be too hard (iirc lcc has one,
there is a free one from M$ etc...) and on linux there is no problem
anyway as the object format is already the "standard one".

Henning

-- 
GPG Public Key: http://keyserver.ganneff.de:11371/pks/lookup?op=get&search=0xDDD6D36D41911851 Fingerprint: 344F 4072 F038 BB9E B35D  E6AB DDD6 D36D 4191 1851

C. Dunn schrieb:
> 1) No stack-trace on exceptions.
> This makes contract programming a mere QA test, rather than a useful debugging tool.
> 

Since I use flectioned, i have stack traces for exceptions and
segmentation faults.
I havn't tested it with DBC.