www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D's future

reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
	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 

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


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.

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


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.

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


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?


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


come out few and far between.

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


a year ago.  The vector-like array >operations are still not implemented.

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


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:

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


syntax.

I understand what you're driving at here, but I think what one thinks of the

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


local" (A a=new A) makes some >template definitions painful and redundant.

I agree that is clunky and should be fixed.


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).


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,


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.

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


etc.), unless those property names are >keywords, there will be opportunity
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++


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++.

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.






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


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.


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


 the

 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.


http://www.digitalmars.com/drn-bin/wwwnews?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...

 http://www.digitalmars.com/drn-bin/wwwnews?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:


<snip>

 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.


<snip>

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