Am I getting this all right?

Jason House jhouse at mitre.org
Wed Dec 13 15:57:14 PST 2006


I'm kind of doing a trial by fire method to learn D and how it works... I'm
taking an existing open source project and converting it over.  Here's the
stuff that I've found / questions that I have.

Thanks in advance for all the thoughtful responses.  I know this is a long
post!  I've worked through the issues to get working code, but I think my
issues will be hit by others.

It seems that DTL and minTL are the two candidates for an STL equivalent in D.
 Both seem to be out of date.  Since minTL is documented, I chose to use that.
 I found that the latest dmd (0.176) doesn't compile the latest minTL.  It
complains that va_arg isn't defined even though it imports std.stdarg.  Adding
a fully qualified name fixed my usage problem.  Is this really the best option
that I have for STL equivalent?  Anyone else compiling this stuff and hitting
problems?

I know of no way in d to provide a const qualifier.  It seems like the concept
purely doesn't exist.  minTL appears to have a workaround where it templates
itself on a boolean value, and simply doesn't publish certain functions.  When
will a real const qualifier get added to the language?  It seems really
strange that a language that adds all kinds of contract programming wouldn't
use const qualifiers / const types.

After banging my head on printing stuff for a long time, I've come to a few
conclusions:
* The C++ equivalent to std::ostream& operator << (std::ostream &out, const
type &x) does not exist
* Custom types use the toString property
* Enums do not (and can not) have a toString property
* I have found no way to determine (in a templated class) if a type is
printable or not.  static if(is(typeof(T))) comes close, but my very first
test using ints failed.

The special unittest member function doesn't get built in with -unittest
unless the actual class is used in some way (and then one copy of the unittest
funciton gets run for each type).  I'd really like to see some way for this to
work.  for example, class foo(T){ ... unittest{ foo!(int) sample; ...} } does
not run unless other code instantiates foo!(U)

In my early efforts at doing operator overloading, I wrote opCmp and then was
shocked when my unit test showed that == didn't even call opCmp.  It silently
did something wrong.  This seems like a gotcha built into the language that
should probably get remedied.

I couldn't find a way to reinitialize a variable back to a default value...
For example class foo(T){ T[] bar; void func(){bar[3] = new T();} } won't
compile.  I'm not too sure why this is the case.


More information about the Digitalmars-d-learn mailing list