www.digitalmars.com         C & C++   DMDScript  

D - Some questions

reply "Roberto Mariottini" <rmariottini lycosmail.com> writes:
Hello all,
I have still some unanswered questions:

 - Explicit parenthesis around && within ||, as GCC says. Not every
programmer knows that
    (a || b && c)  means (a || (b && c)). In this case GCC issues a warning,
what about D?
 - How is this handled in D:
    int i = 43;
    int j = function1(++i, i++);
 - Will 'final' or somethig be supported to prevent overloading of a method
in a derived
    class?
 - Will some support for automatic documentation of D programs be added?
 - Will some crash-exception-bug reporting utility be added?
 - Will arrays support defining a non-zero start index?
 - Will equality and assignment work by reference or by value?
 - Will explicit casts be needed in automatic conversions with possible loss
of
    precision? (unsigned->signed, double->int, and so on).
 - I know dfront will be open source. What about starting now a project at
   SurceForge?

Thanks in advance
Mar 21 2002
next sibling parent reply "Richard Krehbiel" <rich kastle.com> writes:
"Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
news:a7cmg3$gcu$1 digitaldaemon.com...
 Hello all,
 I have still some unanswered questions:

  - Explicit parenthesis around && within ||, as GCC says. Not every
 programmer knows that
     (a || b && c)  means (a || (b && c)). In this case GCC issues a

 what about D?

Not every programmer realizes in every case that (a + b * c) means (a + (b * c)). Maybe all operations should be strictly left-to-right with precedence by explicit parentheses - um - NOT. I think D should demand that programmers have a minimum level of competence. If they don't, then there's VB. Yes, I make mistakes too - in fact, I've coded a+b*c expecting (a+b)*c, by mistake of course, and the context (type-casting, pointer math) made it a lot more obscure. But I didn't blame the language, I fixed my mistake.
  - How is this handled in D:
     int i = 43;
     int j = function1(++i, i++);

No one who codes this knows what they are doing. I don't care if they think they do - they don't. C leaves this undefined, and I think that's fine. C doesn't require a diagnostic, and neither should D, even when it's as obvious as this, because there are hundreds of unobvious ways. If you want to put "sequence points" between evaluation of function arguments, I suppose that's okay, though you still shouldn't know which of ++i and i++ were evaluated first. But woe unto D in the day that modern compilers on advanced machines can dispatch multiple microthreads to evaluate function arguments in parallel. -- Richard Krehbiel, Arlington, VA, USA rich kastle.com (work) or krehbiel3 comcast.net (personal)
Mar 21 2002
parent Russell Borogove <kaleja estarcion.com> writes:
Richard Krehbiel wrote:
 "Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
 news:a7cmg3$gcu$1 digitaldaemon.com...
 
Hello all,
I have still some unanswered questions:

 - Explicit parenthesis around && within ||, as GCC says. Not every
programmer knows that
    (a || b && c)  means (a || (b && c)). In this case GCC issues a
 warning, what about D?

Not every programmer realizes in every case that (a + b * c) means (a + (b * c)). Maybe all operations should be strictly left-to-right with precedence by explicit parentheses - um - NOT.

Heh, that's how I code, even for a+b*c, where I'm 99.2% sure of the precedence. I _always_ write a+(b*c) because the next poor bastard who might be working on my code might have had lousy teachers, or he might be hung over, or might be being distracted by his office-mate muttering something about a stapler and setting the building on fire.
 Yes, I make mistakes too - in fact, I've
 coded a+b*c expecting (a+b)*c, by mistake of course, and the context
 (type-casting, pointer math) made it a lot more obscure. But I didn't blame
 the language, I fixed my mistake.

Say you intended (a+b)*c, and due to the contextual obscurity, you wrote a+b*c. Assume you got away with it for a while, because a was usually zero, or because the exact answer wasn't important or wasn't checked closely. Now I'm trying to reuse your code in a context where a is usually nonzero or where the exact answer is more important. It's very hard for me to realize that you've made an error, because of that contextual obscurity -- far harder for me to find the error than for you to avoid the error when you were writing that line of code. in the first place. After all -- I hear you were a pretty good programmer before you took off to Hawaii to enjoy your retirement, so I should trust your code! It's probably my mistake! It's probably a compiler bug! This code used to work fine! For this reason, I personally would be happy with a compiler that always required parentheses to disambiguate (Guess I should be using lisp or something). I don't expect anyone else to agree, however. -Russell B
Mar 21 2002
prev sibling next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
news:a7cmg3$gcu$1 digitaldaemon.com...

 Hello all,
 I have still some unanswered questions:

  - Explicit parenthesis around && within ||, as GCC says. Not every
 programmer knows that
     (a || b && c)  means (a || (b && c)). In this case GCC issues a

 what about D?

There is a strict operator precedence table in D, which states that && is evaluated before ||. Every D programmer should be aware of it - or die... ...or just put brackets around expressions on his own; but don't force others, who know what they do, to do so.
  - How is this handled in D:
     int i = 43;
     int j = function1(++i, i++);

Order in which arguments are evaluated is undefined, so is the result of this code.
  - Will 'final' or somethig be supported to prevent overloading of a

 in a derived
     class?

Walter said "yes".
  - Will some support for automatic documentation of D programs be added?

As soon as somebody will make it.
  - Will some crash-exception-bug reporting utility be added?

Um, what?
  - Will arrays support defining a non-zero start index?

I doubt.
  - Will equality and assignment work by reference or by value?

Assignment is definitely by reference. Equality will most likely stay the same as well (I didn't see any Walter's comments on the topic, which usually means that you won't see it in D =))
  - Will explicit casts be needed in automatic conversions with possible

 of
     precision? (unsigned->signed, double->int, and so on).

D is not Java, I guess.
  - I know dfront will be open source. What about starting now a project at
    SurceForge?

Why?
Mar 21 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
news:a7cmg3$gcu$1 digitaldaemon.com...
  - Explicit parenthesis around && within ||, as GCC says. Not every
 programmer knows that
     (a || b && c)  means (a || (b && c)). In this case GCC issues a

 what about D?

It works as in standard C, i.e. no warnings or errors.
  - How is this handled in D:
     int i = 43;
     int j = function1(++i, i++);

That is an error in D, although the compiler successfully detecting all such cases is impossible. The rule is it is an error to depend on order of evaluation when order of evaluation is determined by the compiler.
  - Will 'final' or somethig be supported to prevent overloading of a

 in a derived
     class?

Probably. It's a bit up in the air at the moment.
  - Will some support for automatic documentation of D programs be added?

Yes, in the form that D can be embedded inside html documents. (It approaches the problem from the opposite end as Javadoc does, which embeds documentation inside D.)
  - Will some crash-exception-bug reporting utility be added?

What do you mean? Some automatic thing to email Digital Mars on a crash?
  - Will arrays support defining a non-zero start index?

It's a good idea, but it's not in the present spec.
  - Will equality and assignment work by reference or by value?

By value for primitive types and structs, by reference for arrays and classes.
  - Will explicit casts be needed in automatic conversions with possible

 of
     precision? (unsigned->signed, double->int, and so on).

Yes.
  - I know dfront will be open source. What about starting now a project at
    SurceForge?

I have no idea how to go about that. Great questions, btw. -Walter
Mar 21 2002
parent reply "Roberto Mariottini" <rmariottini lycosmail.com> writes:
"Walter" <walter digitalmars.com> ha scritto nel messaggio
news:a7drb4$144p$1 digitaldaemon.com...
 "Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
 news:a7cmg3$gcu$1 digitaldaemon.com...
  - How is this handled in D:
     int i = 43;
     int j = function1(++i, i++);

That is an error in D, although the compiler successfully detecting all

 cases is impossible. The rule is it is an error to depend on order of
 evaluation when order of evaluation is determined by the compiler.

If I understand well it can be an error or not, depending on the compiler implementation. I am right?
  - Will some support for automatic documentation of D programs be added?

Yes, in the form that D can be embedded inside html documents. (It approaches the problem from the opposite end as Javadoc does, which embeds documentation inside D.)

Maybe this is the right direction. I should try to write some real code to see how it appears.
  - Will some crash-exception-bug reporting utility be added?

What do you mean? Some automatic thing to email Digital Mars on a crash?

Ok, my fault. My original question is: is a D program supposed to crash on an error? (for example a Java program is not). If yes, what about adding a consistent error-reporting procedure for a D program? Just an idea. I find difficult to track a program when it prints only "segmentation fault".
  - Will arrays support defining a non-zero start index?

It's a good idea, but it's not in the present spec.

D 1.1?
  - I know dfront will be open source. What about starting now a project


    SurceForge?

I have no idea how to go about that.

Do you think it's a viable solution to start dfront as a public project, developed by the community, or to you is better to keep it "under control"? Ciao
Mar 22 2002
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
news:a7eq42$1jme$1 digitaldaemon.com...

 If I understand well it can be an error or not, depending on the compiler
 implementation. I am right?

It IS an error, only not every compiler might detect it. But it's not valid D.
 Ok, my fault. My original question is: is a D program supposed to crash on
 an error?
 (for example a Java program is not). If yes, what about adding a

 error-reporting procedure for a D program? Just an idea.
 I find difficult to track a program when it prints only "segmentation
 fault".

D tries to track most errors (out-of-memory, array bounds etc) and raises exceptions accordingly; if you don't handle them, they are printed to stderr and program aborts. I'm not sure if it handles things like access violation and such, though.
 Do you think it's a viable solution to start dfront as a public project,
 developed
 by the community, or to you is better to keep it "under control"?

I'd suggest not to open it completely for now. Everybody has his own understanding of the "right thing", and to get something consistent, only one should control the project.
Mar 22 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
news:a7eq42$1jme$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> ha scritto nel messaggio
 news:a7drb4$144p$1 digitaldaemon.com...
 "Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
 news:a7cmg3$gcu$1 digitaldaemon.com...
  - How is this handled in D:
     int i = 43;
     int j = function1(++i, i++);


 cases is impossible. The rule is it is an error to depend on order of
 evaluation when order of evaluation is determined by the compiler.

implementation. I am right?

It's always an error, but whether the compiler detects it or not is a quality of implementation issue.
  - Will some crash-exception-bug reporting utility be added?


an error? (for example a Java program is not). If yes, what about adding a

 error-reporting procedure for a D program? Just an idea.
 I find difficult to track a program when it prints only "segmentation
 fault".

Having a seg fault is good - I remember the bad old DOS days where an error would silently scramble your hard disk.
  - Will arrays support defining a non-zero start index?



I want to do 1.0 first <g>.
 Do you think it's a viable solution to start dfront as a public project,
 developed
 by the community, or to you is better to keep it "under control"?

I'm concerned the language will splinter off into too many directions before it has a chance to "gel" if it goes open source too early.
Mar 23 2002