and how much code do you need to write to perform a simple
prinf( "this number 0x%X, as dec(%d) with a string '%s' or two %s%s, and a
float %g, i,i,str1,str2,str1,f );
I would like to see an extended object array type that allows runtime type
checking or both objects and primitives
which could be used for a D varargs
without the Java problem of having to create a Integer, Long Object to wrap
the primatives passed in the array.
a good D svprintf would be a bonus too (that understood the buffer was a D
char/wchar[] and could grow it for you).
Mike.
<dr_dizel hotbox.ru> wrote in message
news:an4qf6$2bio$1 digitaldaemon.com...

and how much code do you need to write to perform a simple
prinf( "this number 0x%X, as dec(%d) with a string '%s' or two %s%s, and a
float %g, i,i,str1,str2,str1,f );
I would like to see an extended object array type that allows runtime type
checking or both objects and primitives
which could be used for a D varargs
without the Java problem of having to create a Integer, Long Object to wrap
the primatives passed in the array.

My port has safe varargs using a generic list:
void print (char [] format, generic [] args...);
The generic struct holds a pointer and a TypeInfo. I use it for
printing, as with the above. Go bug Walter about it, as he seems to
think formatted printing isn't the most important library task in a wide
range of applications and worth the fifty lines of code this took. :-)
This also gets rid of the va_list issue with two functions for every
varargs function as you can expand generic lists into another. Example:
void foobar (generic [] args...)
{
print ("%s:%d\n", args [1 .. ]...);
}
And, of course, it fixes the issue of having to have at least one real
argument.

a good D svprintf would be a bonus too (that understood the buffer was a D
char/wchar[] and could grow it for you).

It seems that you've made some changes from the D standard in your port.
Does Walter plan on supporting these things in the future? Are these things
temporal (likely to change)? What will happen if Walter takes a different
approach and some of these things become obsolete?
Not saying what you have done is good or bad, I'm just asking some critical
questions about your port.
PS -
Keep up the excellent work on the port.
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:an52bu$2jb3$1 digitaldaemon.com...

Mike Wynn wrote:

and how much code do you need to write to perform a simple
prinf( "this number 0x%X, as dec(%d) with a string '%s' or two %s%s, and

float %g, i,i,str1,str2,str1,f );
I would like to see an extended object array type that allows runtime

checking or both objects and primitives
which could be used for a D varargs
without the Java problem of having to create a Integer, Long Object to

the primatives passed in the array.

My port has safe varargs using a generic list:
void print (char [] format, generic [] args...);
The generic struct holds a pointer and a TypeInfo. I use it for
printing, as with the above. Go bug Walter about it, as he seems to
think formatted printing isn't the most important library task in a wide
range of applications and worth the fifty lines of code this took. :-)
This also gets rid of the va_list issue with two functions for every
varargs function as you can expand generic lists into another. Example:
void foobar (generic [] args...)
{
print ("%s:%d\n", args [1 .. ]...);
}
And, of course, it fixes the issue of having to have at least one real
argument.

a good D svprintf would be a bonus too (that understood the buffer was a

It seems that you've made some changes from the D standard in your port.
Does Walter plan on supporting these things in the future? Are these things
temporal (likely to change)? What will happen if Walter takes a different
approach and some of these things become obsolete?

Default arguments for array slicing will get in DMD; if they're not on
Walter's TODO, they must be put there.
Safe varargs, as I say, require some convincing. The alternatives are
compile-time argument expansion and iostream. He's publicly opposed
iostream (to the point of wanting to restrict the operator overloading
to disallow it, if you remember) - although it flat out will get into D
if the only alternative is C's broken method - and I doubt he's much for
compile-time argument expansion (Either the Russ method or the
overloaded recursive method), as it's not a simple thing to do in the
compiler, even with inlining there.
I'm convinced my solution is the absolute ideal for the generic list
method - it does everything using the minimum of fuss and fits like the
language had been built for it. Choosing an inferior, and incompatible,
method instead would be very strange seeing as it's so easy to
implement; fifty lines isn't really any more complex than twenty or ten.
The only variation could be in the keyword and the supported methods.
There's no chance of obsoletion, as the generic list method does everything.

I'm not ignoring this issue, you're right, it does need addressing. It's
just that I've got a pile of things to do to D. You're right about my
dislike of C++ iostreams. The nail in its coffin is the poor performance on
benchmarks. Iostreams has bloat, inefficiency, complexity, and is
aesthetically unappealing. The only thing it does right is flexibility, but
at too high a cost.
Java is worse, its I/O speed is a serious problem.
Paying a lot of attention to I/O routines is a crucial component of the
speed of the Digital Mars compilers/linkers.