Damn, this is going to get put in the troll category and disappear, and I can't agree more. What about this laundry that's piling up? Why won't Walter wash my floors instead of gallavanting about with this language nonsense?
I spoke confusingly - I should have said "to add the vtable pointer and the implicit layout change this results in" instead. In addition, D ties virtual objects with heap allocation.
Whether objects with virtual methods on the stack are necessary is an issue unrelated to the original post.
It has a bit type with true and false constants, which is rather misnamed as it doesn't allow implicit casts to it, but explicit casts have a logical (boolean) result. bit arrays are compact, and we could pack class fields. However, bit pointers are not allowed, nor are bit inout/out arguments for functions, as these would require pointer/mask pairs. I think it's worth the additional complexity, but there's more important things right now to work on.
See (here) under RAII. In short, you apply an "auto" attribute to the class and instances of it; this will insert a "delete XXX;" when it goes out of scope. auto classes are limited to local variables and can't be reassigned, so they can't be included in garbage collection and thus have a more stable environment for the destructor.
I'm not going to advocate how this feature is put together; I've never used it.
It's a free language; anyone can write a compiler. If it passes a suite of compliance tests as yet unwritten, it's a D compiler (Compliance will be easier than C for sure). The reference implementation is free, and produces code on par with MSVC and GCC. The backend is closed-source, but the frontend source is included in the distribution under the Artistic and GPL licenses, your choice. If you want to get the backend source, you'll have to talk to Walter (walter@digitalmars.com). I have no idea whether he'd be jiggy with licensing it.
The frontend leaves you at the stage of the syntax tree after semantic checking, so it's ready for translation into an IR. I wrote a dumb backend for my Linux port, so I can help anyone with the trickier parts of the frontend, like struct initialisers.
"if (...);" is invalid D code. The empty expression in D is "{ }", not ";", and that change was made for precisely the reason you give. I disagree with it, but no matter.
"if (a = 1)" is invalid D code. Not a recommended warning (there are no warnings in D) - if the compiler doesn't fail it, it's not compliant. This hasn't found its way into the specification yet - I'll notify Walter.
Octal notation can't be changed for reasons which should be obvious if you think about it.
That's a pretty strange last assertion. Does that mean that the most modern language is FORTH? Or perhaps Befunge! Idiosyncratic doesn't equal better. And yes, the basic syntax of C evolved from BCPL and ultimately evolved from FORTRAN.
It borrows from lots of languages. I haven't looked too hard at Ada95, but what I've seen indicates to me that there's far more differences than similarities.
Here's the state on the GCC backend. That project is run by Jan Knepper, who at this time and for the forseeable future has no time to spare for it. GCC is the most amazingly opaque piece of software internally, which makes this a pretty serious project needing someone who can make a pretty serious commitment. Once that time comes, I figure it will be three months after that point for the GCC port to be well-functional.
It is probable that there soon will be a better solution for Linux than my crap-generating port, which is also missing more recent D features. Let's just say that in my opinion it will meet the needs of every Linux i386 user, and being far faster than GCC while producing high-quality code will be a good advantage in that market.
This has been requested (and is partially in Ada95, for example), but nobody has shown why this would be necessary in any real work. Can you give an example?
"private static bit initialised;" instead. IMO this is all the language should provide, as trying to do such a vitally important thing as dependent static constructor order automatically is bound to be more confusing than doing it explicitly. Also, there are cases where each constructor is codependent on one another, where you need to do fairly complex intermingling.
My Linux port has reflection with a serialisation module. All that this is waiting for is more time on the part of the compiler author - he's not opposed to adding introspection. What is available now (in both the port and the original) is accessible through the TypeInfo and ClassInfo classes, which you get through.typeinfo and.classinfo properties.
Nothing. D is not a safe language; making it safe would change the language (no pointers, union restrictions), what it can do (no direct interaction with other languages), and what it can be applied to drastically.
The calling order of static constructors is not defined. Anyone trying to use static constructors as their only tool is going to get burned, same as with destructors. So:
You're a little confused. D has struct and class, which just makes explicit what C++ does implicitly - to create an object on the stack or in the heap depending upon whether it has virtual methods and is thus a candidate for polymorphism. class are on the heap, struct are on the stack. It also inverts the default protection of class fields and methods (public instead) and defines virtual methods by default - you define a nonvirtual method by using the final keyword.
So this part of D is more or less a literalisation of what was in C++. What D lacks here is struct inheritance and constructors.
Slashdot Mirror
Damn, this is going to get put in the troll category and disappear, and I can't agree more. What about this laundry that's piling up? Why won't Walter wash my floors instead of gallavanting about with this language nonsense?
Whether objects with virtual methods on the stack are necessary is an issue unrelated to the original post.
It has a bit type with true and false constants, which is rather misnamed as it doesn't allow implicit casts to it, but explicit casts have a logical (boolean) result. bit arrays are compact, and we could pack class fields. However, bit pointers are not allowed, nor are bit inout/out arguments for functions, as these would require pointer/mask pairs. I think it's worth the additional complexity, but there's more important things right now to work on.
I'm not going to advocate how this feature is put together; I've never used it.
The frontend leaves you at the stage of the syntax tree after semantic checking, so it's ready for translation into an IR. I wrote a dumb backend for my Linux port, so I can help anyone with the trickier parts of the frontend, like struct initialisers.
"if (a = 1)" is invalid D code. Not a recommended warning (there are no warnings in D) - if the compiler doesn't fail it, it's not compliant. This hasn't found its way into the specification yet - I'll notify Walter.
Octal notation can't be changed for reasons which should be obvious if you think about it.
That's a pretty strange last assertion. Does that mean that the most modern language is FORTH? Or perhaps Befunge! Idiosyncratic doesn't equal better. And yes, the basic syntax of C evolved from BCPL and ultimately evolved from FORTRAN.
Here's the state on the GCC backend. That project is run by Jan Knepper, who at this time and for the forseeable future has no time to spare for it. GCC is the most amazingly opaque piece of software internally, which makes this a pretty serious project needing someone who can make a pretty serious commitment. Once that time comes, I figure it will be three months after that point for the GCC port to be well-functional.
It is probable that there soon will be a better solution for Linux than my crap-generating port, which is also missing more recent D features. Let's just say that in my opinion it will meet the needs of every Linux i386 user, and being far faster than GCC while producing high-quality code will be a good advantage in that market.
This has been requested (and is partially in Ada95, for example), but nobody has shown why this would be necessary in any real work. Can you give an example?
"private static bit initialised;" instead. IMO this is all the language should provide, as trying to do such a vitally important thing as dependent static constructor order automatically is bound to be more confusing than doing it explicitly. Also, there are cases where each constructor is codependent on one another, where you need to do fairly complex intermingling.
My Linux port has reflection with a serialisation module. All that this is waiting for is more time on the part of the compiler author - he's not opposed to adding introspection. What is available now (in both the port and the original) is accessible through the TypeInfo and ClassInfo classes, which you get through .typeinfo and .classinfo properties.
Nothing. D is not a safe language; making it safe would change the language (no pointers, union restrictions), what it can do (no direct interaction with other languages), and what it can be applied to drastically.
...
The calling order of static constructors is not defined. Anyone trying to use static constructors as their only tool is going to get burned, same as with destructors. So:
class Foo
{
private bit initialised;
static void init ()
{
if (initialised)
return;
initialised = true;
}
static this ()
{
init ();
}
}
Is still a necessary construct.
void main ()
/* Called at the start of the program before main */
/* Called after main or an unhandled exception. */
/* The constructor - C++ would have "HelloWorld ()" here */
/* The destructor - C++ would have "~HelloWorld ()" here */
{
printf ("Hello, World!\n");
}
Not exactly informative, although note that "void main ()" is explicitly a well-formed main, and could be:
void main ();
void main (char [] [] args);
int main ();
int main (char [] [] args);
The OOP version:
class HelloWorld
{
char [] string = "Hello, Class!\n";
static this ()
{
printf ("Hello, Program!\n");
}
static ~this ()
{
printf ("Bubye, Program!\n");
}
this ()
{
string = "Hello, World!\n";
}
~this ()
{
printf ("Goodbye, World!\n");
}
void print ()
{
printf ("%.*s", string);
}
}
void main ()
{
(new HelloWorld).print ();
}
You're a little confused. D has struct and class, which just makes explicit what C++ does implicitly - to create an object on the stack or in the heap depending upon whether it has virtual methods and is thus a candidate for polymorphism. class are on the heap, struct are on the stack. It also inverts the default protection of class fields and methods (public instead) and defines virtual methods by default - you define a nonvirtual method by using the final keyword. So this part of D is more or less a literalisation of what was in C++. What D lacks here is struct inheritance and constructors.