www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D's future

reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I've been out of the D community for a few reasons.  The big one is that =
I've been loaded with schoolwork and this is the first time in about =
three months that I've had any free time.  The other reason is the topic =
of this thread.

Personally I don't see where D is going, or if it is going.  The patches =
come out few and far between.  I know, one-man band, but still.  Phobos =
is almost as shaky now as it was a year ago.  The vector-like array =
operations are still not implemented.  Worst of all, the whole language =
seems kind of.. clunky.

Granted, it's nowhere NEAR as ugly-feeling as C++.  But it's getting =
there.

Class properties feel like a weird compiler hack.  There is no official =
"property" keyword or anything like that.  In fact, the following, =
although confusing, is legal:

class A
{
public:
    void Something(int x) { writefln("Something here: ",x); }
}

void main()
{
    A a=3Dnew A;
    a.Something=3D7 // prints "Something here: 7"
}

Something() is not a property, though I can call it with the property =
syntax.

The "classes are references even though the syntax looks like they're =
local" (A a=3Dnew A) makes some template definitions painful and =
redundant.  I think it'd be easier to bring back class pointers (A* =
a=3Dnew A) and simply flag any attempt to create class instances on the =
stack as an error.

Casting is, frankly, a pain.  Not only do we now have the ugly =
cast(type)expr operator, but we cannot create more than one opCast per =
class (understandable) and there is no such thing as opAssign (NOT =
understandable).  We are then stuck making all these stupid =
"toSomething()" member functions, which can potentially cause =
frustration (imagine if you have int x; x=3Da.toInt();  then you change =
x's type to float.  it'll then cast to int and then to float, rather =
than automatically selecting a's toFloat() operator (if it has one)).  =
If there's one thing I love about C++, it's its ability to hide all that =
nasty casting crap.  The only problem with C++ is that sometimes it's a =
little obscure as to what goes through what function when implicitly =
casting.  But 99% of the time it's a very simple, obvious cast anyway, =
so I don't see what's wrong with implicit casting.

While I like the idea of inherent properties of types (like .sizeof, =
.init etc.), unless those property names are keywords, there will be =
opportunity to write such ugliness as:

class A
{
public:
    int sizeof() { return 77; }
}

void main()
{
    A a=3Dnew A;
    writefln(a.sizeof);
}

Whaat?!  How can that possibly be legal?

Lastly, I doubt this is ever going to change, and this isn't really part =
of the language per se, but I really really REALLY would like to see the =
D compiler produce regular old COFF files and the linker support them as =
well, instead of the weird DM OMF files that it currently makes (and =
are, as far as I know, incompatible with virtually everything else, so =
no using D libs in VC++).  There are TONS of C libs out there that come =
in COFF format and it's just stupid to not be able to use them without =
messing with a third-party linker.

This is just where I see D as it stands now.  I've been working on a C++ =
project recently, and I just can't get into the swing of C++ anymore, =
after seeing and using D.  But I look at D and I see a language that's =
getting to be just as quirky as C++.  
Dec 26 2004
next sibling parent David Medlock <amedlock nospam.org> writes:
Jarrett Billingsley wrote:
  
 The "classes are references even though the syntax looks like they're 
 local" (A a=new A) makes some template definitions painful and 
 redundant.  I think it'd be easier to bring back class pointers (A* 
 a=new A) and simply flag any attempt to create class instances on the 
 stack as an error.

Moving back to pointers and not references would be the worst sort of mistake. It would certainly push me back to C++. Java and C# both use references and have no issues at all.
 Casting is, frankly, a pain.  Not only do we now have the ugly 
 cast(type)expr operator, but we cannot create more than one opCast per 
 class (understandable) and there is no such thing as opAssign (NOT 
 understandable).  

opAssign was mentioned in another thread. Work through the potential semantics of it and you will reach a several dead ends. We are then stuck making all these stupid
 "toSomething()" member functions, which can potentially cause 
 frustration (imagine if you have int x; x=a.toInt();  then you change 
 x's type to float.  it'll then cast to int and then to float, rather 
 than automatically selecting a's toFloat() operator (if it has one)).  

The problem with this is that silent casting is a source of bugs. One off the top of my head is when there is an operator which converts to a char*, then you attempt to delete a reference...whoops the char* operator is invoked then deleted. A subtle bug which may bite you 2/10 times. I prefer clear, easy to understand vs saving a few keystrokes.
 While I like the idea of inherent properties of types (like .sizeof, 
 .init etc.), unless those property names are keywords, there will be 
 opportunity to write such ugliness as:
  
 class A
 {
 public:
     int sizeof() { return 77; }
 }
  
 void main()
 {
     A a=new A;
     writefln(a.sizeof);
 }
  
 Whaat?!  How can that possibly be legal?

Enough rope to hang yourself with...
Dec 26 2004
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message
news:cqo27e$7vr$1 digitaldaemon.com...
Lastly, I doubt this is ever going to change, and this isn't really part of

compiler produce regular old COFF files and the linker support them as
well, instead of the weird DM OMF files that it currently makes (and are,

D libs in VC++). There are TONS of C libs out there that come in >COFF format and it's just stupid to not be able to use them without messing with a third-party linker. The OMF format that DMD uses is actually a Microsoft defined format based on an earlier Intel designed one. Microsoft at one point decided to abandon it in favor of a Microsoft defined variant on COFF. Using the same object format doesn't mean that any C library in that format will successfully link and run. There is a lot more compatibility required - such as calling conventions, name mangling, compiler helper functions, and hidden assumptions about the way things work. If DMD produced Microsoft COFF output files, there is still little chance that they would work successfully with object files designed and tested for use with VC. There were a lot of problems with this back when Microsoft's compilers did generate COFF. Having a different object file format makes it helpful in identifying library files that were not tested to work with DMD. If they are not, weird problems would result even if they successfully managed to link them together. It really takes an expert to get a binary built with a compiler from one vendor to work with the output of another vendor's compiler. That said, the linux version of DMD produces object files in the ELF format which is standard on linux, and it is specifically designed to work with the standard linux C compiler, gcc. There is one case where using existing C libraries does work - when those libraries come in the form of a DLL conforming to the usual C ABI interface. The linkable part of this is called an "import library", and Microsoft COFF format import libraries can be successfully converted to DMD OMF using the "coff2omf.exe" tool.
Dec 27 2004
parent reply M <M_member pathlink.com> writes:
Sorry, can someone explain the problem to me? 
I am mostly using linux but sometimes need to make programs for windows too.
So for example if I need to use the MySQL librarys in windows, can I do that.
What C librarys can I use and what I can't? In D spec, there is written that it
has full binary compatablity for C.

Please light me a bit about it.

Thank you!


In article <cqohvg$rf0$1 digitaldaemon.com>, Walter says...
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message
news:cqo27e$7vr$1 digitaldaemon.com...
Lastly, I doubt this is ever going to change, and this isn't really part of

compiler produce regular old COFF files and the linker support them as
well, instead of the weird DM OMF files that it currently makes (and are,

D libs in VC++). There are TONS of C libs out there that come in >COFF format and it's just stupid to not be able to use them without messing with a third-party linker. The OMF format that DMD uses is actually a Microsoft defined format based on an earlier Intel designed one. Microsoft at one point decided to abandon it in favor of a Microsoft defined variant on COFF. Using the same object format doesn't mean that any C library in that format will successfully link and run. There is a lot more compatibility required - such as calling conventions, name mangling, compiler helper functions, and hidden assumptions about the way things work. If DMD produced Microsoft COFF output files, there is still little chance that they would work successfully with object files designed and tested for use with VC. There were a lot of problems with this back when Microsoft's compilers did generate COFF. Having a different object file format makes it helpful in identifying library files that were not tested to work with DMD. If they are not, weird problems would result even if they successfully managed to link them together. It really takes an expert to get a binary built with a compiler from one vendor to work with the output of another vendor's compiler. That said, the linux version of DMD produces object files in the ELF format which is standard on linux, and it is specifically designed to work with the standard linux C compiler, gcc. There is one case where using existing C libraries does work - when those libraries come in the form of a DLL conforming to the usual C ABI interface. The linkable part of this is called an "import library", and Microsoft COFF format import libraries can be successfully converted to DMD OMF using the "coff2omf.exe" tool.

Dec 27 2004
parent "Walter" <newshound digitalmars.com> writes:
"M" <M_member pathlink.com> wrote in message
news:cqoj1q$siu$1 digitaldaemon.com...
 Sorry, can someone explain the problem to me?
 I am mostly using linux but sometimes need to make programs for windows

 So for example if I need to use the MySQL librarys in windows, can I do

 What C librarys can I use and what I can't?

You can use C libraries that are compiled into DLLs that do not require that the caller of the DLL be compatible with, for example, VC's runtime library. For example, the DLL should not malloc memory and expect the caller of the DLL to free it. You can also use any C libraries that are designed for use with DMC++.
 In D spec, there is written that it
 has full binary compatablity for C.

It does, for the C compiler it is designed to work with. Be sure and ask the vendor of any C library you wish to use to support DMC++.
Dec 27 2004
prev sibling next sibling parent "Walter" <newshound digitalmars.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message
news:cqo27e$7vr$1 digitaldaemon.com...
Personally I don't see where D is going, or if it is going.  The patches

I've been doing updates about once a month. More than that just seems to be too disruptive to people doing serious work with D.
  I know, one-man band, but still.  Phobos is almost as shaky now as it was

There always seem to be more important things that need to be done before the vector stuff.
 Worst of all, the whole language seems kind of.. clunky.
 Granted, it's nowhere NEAR as ugly-feeling as C++.  But it's getting

Class properties feel like a weird compiler hack.  There is no official

confusing, is legal:
 [...]
 Something() is not a property, though I can call it with the property

I understand what you're driving at here, but I think what one thinks of the property syntax depends on one's perspective. I find the C# way of doing it to be wordy, clunky, and limiting (no overloading, for example). D's version is a bit unusual, but it's wonderfully flexible. Think about it like how C has interchangable syntax for pointers and arrays.
The "classes are references even though the syntax looks like they're

I agree that is clunky and should be fixed.
Casting is, frankly, a pain.  Not only do we now have the ugly

class (understandable) and there is no such thing as opAssign (NOT
understandable).

The legitimate uses (and need) for overloadable assignment operators in C++ are to handle resource allocation. Since this use isn't an issue for D, and since overloaded assignment in C++ leads to much madness and very complicated compiler internals, it falls very low on the cost/benefit scale. So it was left out.
We are then stuck making all these stupid "toSomething()" member functions,

x=a.toInt(); then you change x's type to float. it'll then cast to int and
then to float, rather than automatically selecting a's toFloat() operator

to hide all that nasty casting crap. The only problem with C++ is that
sometimes it's a little obscure as to what goes through what function when

anyway, so I don't see what's wrong with implicit casting. Implicit casting is a great idea. It's problems don't become apparent for years, when battle-weary programmers eventually conclude that it just causes more problems than it is worth. I know that it is difficult to be convincing in a few lines about this, but when the complexity of the classes goes beyond the trivial, the interactions between them and other classes with implicit casting becomes remarkably impenetrable.
While I like the idea of inherent properties of types (like .sizeof, .init

to write such ugliness as:
[...]
Whaat?!  How can that possibly be legal?

I have a number of misgivings about that, too. It'll probably change so that the inherent properties cannot be redefined (though they won't be keywords).
This is just where I see D as it stands now.  I've been working on a C++

seeing and using D. But I look at D and I see a language that's getting >to be just as quirky as C++. I've written compilers for both, and D has a very long way to go to get as quirky!
Dec 27 2004
prev sibling next sibling parent Matthias Becker <Matthias_member pathlink.com> writes:
Personally I don't see where D is going, or if it is going.  The patches =
come out few and far between.  I know, one-man band, but still.  Phobos =
is almost as shaky now as it was a year ago.  The vector-like array =
operations are still not implemented.  Worst of all, the whole language =
seems kind of.. clunky.

So, perhaps you should start to write thoese vector-like array-operations. What are vector-like array-operations anyway? Something like the scalar-product?
Granted, it's nowhere NEAR as ugly-feeling as C++.  But it's getting =
there.

Yes it has this usgly C-synthax, but many mainstream-languages do (Java, C#).
Class properties feel like a weird compiler hack.  There is no official =
"property" keyword or anything like that.  In fact, the following, =
although confusing, is legal:

class A
{
public:
    void Something(int x) { writefln("Something here: ",x); }
}

void main()
{
    A a=3Dnew A;
    a.Something=3D7 // prints "Something here: 7"
}

Something() is not a property, though I can call it with the property =
syntax.

You can abuse a language-feature? That's scary. Nobody should ever use a language that allows you to abuse any language construct. ???
The "classes are references even though the syntax looks like they're =
local"

Smalltalk,Python, ..., ..., ... -programmers all feel compfortable with this synthax. Only because a strange language designed more than 20 years ago has this strange notation ("C"), new language don't have to follow its rules.
(A a=3Dnew A) makes some template definitions painful and =
redundant.  I think it'd be easier to bring back class pointers (A* =
a=3Dnew A) and simply flag any attempt to create class instances on the =
stack as an error.

NO! That would be a big mistake. It would make writing tamplet-code to complicated. template foo (T) { foo (T bar) // just does the right thing {...} }
Casting is, frankly, a pain.  Not only do we now have the ugly =
cast(type)expr operator, but we cannot create more than one opCast per =
class (understandable) and there is no such thing as opAssign (NOT =
understandable).  

Ugly? so you prefere "dynamic_cast<Foo>(bar)"? "cast(Foo)bar" looks better to me, but still not perfekt. Perhaps bar "bar as Foo"? Looks cool to me.
We are then stuck making all these stupid =
"toSomething()" member functions, which can potentially cause =
frustration (imagine if you have int x; x=3Da.toInt();  then you change =
x's type to float.  it'll then cast to int and then to float, rather =
than automatically selecting a's toFloat() operator (if it has one)).  =
If there's one thing I love about C++, it's its ability to hide all that =
nasty casting crap.  The only problem with C++ is that sometimes it's a =
little obscure as to what goes through what function when implicitly =
casting.  But 99% of the time it's a very simple, obvious cast anyway, =
so I don't see what's wrong with implicit casting.

But now imagine that you forgot to write "operator float" in C++. The "operator int" will silently be used. A "toInt" would be quite obvious.
While I like the idea of inherent properties of types (like .sizeof, =
.init etc.), unless those property names are keywords, there will be =
opportunity to write such ugliness as:

class A
{
public:
    int sizeof() { return 77; }
}

void main()
{
    A a=3Dnew A;
    writefln(a.sizeof);
}

Whaat?!  How can that possibly be legal?

Whoooooo, a second feature that can be abused? Crazzy dude! Now look at this: int foo; int * bar = & foo - 9; // points just nowhere *bar = 42; // alowed!!!! AHHHHHH! -- Matthias Becker
Dec 27 2004
prev sibling next sibling parent reply Ben Hinkle <Ben_member pathlink.com> writes:
Class properties feel like a weird compiler hack.  There is no official =
"property" keyword or anything like that.  In fact, the following, =
although confusing, is legal:

class A
{
public:
    void Something(int x) { writefln("Something here: ",x); }
}

void main()
{
    A a=3Dnew A;
    a.Something=3D7 // prints "Something here: 7"
}

Something() is not a property, though I can call it with the property =
syntax.

The property syntax is syntactic sugar so it is assumed the name of the function, and the user's common sense, will be enough of a guide for when to use the property syntax and when to call the function directly. The only strange part about properties that bugs me is that sometimes you have explicitly put in the () when calling the getter. For example if foo is a property I think the code if (x.foo == 0) ... only compiles if it is if (x.foo() == 0) ... which arguably is a bug in the compiler.
Dec 27 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Ben Hinkle" <Ben_member pathlink.com> wrote in message
news:cqpaeg$1joq$1 digitaldaemon.com...
 The property syntax is syntactic sugar so it is assumed the name of the
 function, and the user's common sense, will be enough of a guide for when

 the property syntax and when to call the function directly. The only

 part about properties that bugs me is that sometimes you have explicitly

 the () when calling the getter. For example if foo is a property I think

 code
 if (x.foo == 0) ...
 only compiles if it is
 if (x.foo() == 0) ...
 which arguably is a bug in the compiler.

Yes, it is a compiler bug. When I find cases of these, they get stamped out.
Dec 27 2004
parent reply Vathix <vathix dprogramming.com> writes:
On Mon, 27 Dec 2004 08:59:49 -0800, Walter <newshound digitalmars.com>  
wrote:

 For example if foo is a property I think

 code
 if (x.foo == 0) ...
 only compiles if it is
 if (x.foo() == 0) ...
 which arguably is a bug in the compiler.

Yes, it is a compiler bug. When I find cases of these, they get stamped out.

digitalmars.D.bugs/740 and the replies, posted back in July. I know I've found a few more cases since then but didn't bother posting them, one being switch(f.prop). - Chris
Dec 27 2004
parent "Walter" <newshound digitalmars.com> writes:
"Vathix" <vathix dprogramming.com> wrote in message
news:opsjowgqowkcck4r tc3-ppp187.dialup.wzrd.com...
 digitalmars.D.bugs/740 and the
 replies, posted back in July. I know I've found a few more cases since
 then but didn't bother posting them, one being switch(f.prop).
 - Chris

I'll take care of them. Thanks, -Walter
Dec 27 2004
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Jarrett Billingsley wrote:
<snip>
 Class properties feel like a weird compiler hack.  There is no official 
 "property" keyword or anything like that.  In fact, the following, 
 although confusing, is legal:

 Something() is not a property, though I can call it with the property 
 syntax.

Indeed. Guess there are possible excuses like saving typing, saving a keyword or opening up IODCC potential. Of course, there may well be some more 'real' motives/advantages. The price is that documentation generators can't automatically give properties special treatment. But putting properties into a member group for Doxygen seems to work OK for my purposes.
 The "classes are references even though the syntax looks like they're 
 local" (A a=new A) makes some template definitions painful and 
 redundant.

Would you care to give an example?
 I think it'd be easier to bring back class pointers (A* 
 a=new A) and simply flag any attempt to create class instances on the 
 stack as an error.

This would invite people to go back to treating classes as value types, bringing back some of the weaknesses we were trying to avoid.
 Casting is, frankly, a pain.  Not only do we now have the ugly 
 cast(type)expr operator, but we cannot create more than one opCast per 
 class (understandable)

For some values of "understandable", yes. I still don't see that it had to be designed in such a way that you could have only one, rather than something like void opCast(out int qwert) or some special function syntax as C++ kind-of has. Or maybe even making opCast the one function name that can be return-type overloaded (IWC calling opCast by name would probably become illegal).
 and there is no such thing as opAssign (NOT understandable). 

http://www.digitalmars.com/d/faq.html#assignmentoverloading
 We are then stuck making all these stupid 
 "toSomething()" member functions, which can potentially cause 
 frustration (imagine if you have int x; x=a.toInt();  then you change 
 x's type to float.  it'll then cast to int and then to float, rather 
 than automatically selecting a's toFloat() operator (if it has one)).  
 If there's one thing I love about C++, it's its ability to hide all that 
 nasty casting crap.  The only problem with C++ is that sometimes it's a 
 little obscure as to what goes through what function when implicitly 
 casting.  But 99% of the time it's a very simple, obvious cast anyway, 
 so I don't see what's wrong with implicit casting.

Basically that it can get tricky, both to follow and to implement, and be an easy source of bugs. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on on the 'group where everyone may benefit.
Dec 28 2004
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
 Indeed.  Guess there are possible excuses like saving typing, saving a
 keyword or opening up IODCC potential.  Of course, there may well be
 some more 'real' motives/advantages.

Just wondering - what is "IODCC?" I googled it and all I got were a bunch of confusing CVS repositories and a page about someone using java to control his train set.
 Would you care to give an example?

I think it has something to do with == vs. is. Making one template that uses the == operator would cause problems when used with classes. I may be wrong, but Walter agrees with me, and I seem to remember someone coming across this problem in DTL or something, so..
Dec 28 2004
parent reply Markus Dangl <danglm in.tum.de> writes:
Jarrett Billingsley schrieb:
 Just wondering - what is "IODCC?"  I googled it and all I got were a bunch
 of confusing CVS repositories and a page about someone using java to control
 his train set.

Search for IOCCC, you'll understand :)
Dec 28 2004
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
 Search for IOCCC, you'll understand :)

Oh, dear lord.. that's one of the funnier things I've seen in a long time :) An operating system and an 11-bit ALU made entirely in the preprocessor? Man, these people have a lot of time on their hands.
Dec 28 2004