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=new A;
    a.Something=7 // 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=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.

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

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?

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

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

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

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

"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 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
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!

>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"
No they don't!!! Only to C/C++-Programmers. C#, Java, O'Caml, Eiffel, 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

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

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

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

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