"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cvvuq4$ica$1@digitaldaemon.com...
> Why? Does that prove you right? Me?
>
> All it says is that G++ is not perfect, which I already knew.
>
> How come sometimes all that's needed to justify something in D is to show something wrong in C++? Not much of an evolution. More like a statis in different colour.
>
> :-(

I meant it as a comment as to whether the existence of such warnings make a compiler/language usable for serious development or not, and as a comment on its relative importance to developers in general.

Why doesn't g++ warn on it? It has many other warnings.

1) is it too hard to implement? I doubt it. g++ implements many very hard
things.
2) did the keepers of the main g++ branch reject such a warning? Why?
3) has nobody cared enough about that particular issue to implement it?

> To Matthew and Anders:
>
> Maybe you are right in some points but ...
>
> Performance is still an important issue nowadays

In no way have I said it's not important. (You should see the Herculian efforts of self-infliched torture I go through in the STLSoft libraries to eek out performance!)

I just said that if a program is not correct, it's performance is absolutely irrelevant.

>, when everybody says
> ..want speed, buy a bigga machine...
> (Try to buy X, 2*X, X^2 or 2^X size machines when X is growing :-)
>
> Most software developer (company and individual managers also) does not take care about theoretical "correctness".

Who said I was talking about "theoretical" correctness. AFAIUI, no non-trivial program is amenable to program proof techniques, and therefore theoretical correctness is of precisely 0 use in the real world, or in this debate.

> If it was true Windows would never born.
> Windows is what managers plan and people buy. Works, but not correct.
>
> I personally like D while is it much more correct than C/C++
> in some aspects. In D the binary code does (roughly) what I want.
> A C++ binary it does not (the code is unreadable compared to D).
> A C binary does what is written in the source, but it is
> very painful to explain every small things to the compiler.
>
> In C/C++ there are everywhere traps. I have to watch all and every
> steps.
> If I forget to delete something I'll be punished with a crash where
> I do not expect it... There are no (or not too much) help from the
> language(compiler) itself.
>
> D helps a lot _while_ developing. I mean this is Correctness. I agree, that the compiler is not finished yet.
>
> Tamas Nagy


I have worked on several projects over the last decade where (practical) correctness was of paramount importance. They also had exacting performance requirements. They were written in C/C++. They've all worked fine for months/years without a single failure once they've gone into production. Had they performed well but only been roughly correct, there'd've been losses of $Ms, and the clients wouldn't have cared a toss that the performance was good.

In article <d004m9$pbo$2@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>Matthew wrote:
>
>> IMO, D may well score 4.75 out of 5 on performance (although we're waiting to see what effect the GC has in large-scale high-throughput systems), but it scores pretty poorly on correctness.
>> 
>> Since Correctness is the sine qua non of software - there's precisely zero use for a piece of incorrect software to a client; ask 'em! - it doesn't matter if D programs perform 100x faster than C/C++ programs on all possible architectures. If the language promotes the writing of write buggy software, I ain't gonna use it.
>
>Also, there's a lot of interesting new stuff coming up on the C/C++ front, like system vendor's heavy optimizations and auto-vectorization, that the D implementation will be missing out on and thus could lose...
>

If I'm understanding you correctly, you are talking about new compiler implementations, right?

Compared to C/C++, D the language should actually allow more aggressive optimization than C/C++ within the current confines of those languages (imports vs. headers is a great example).

Am I understanding you? Or are you speaking of proposals for the next C or C++ language specs.?

Thanks,
- Dave

>
>I like that performance is a constant D focus. But it can't be *all* ?
>
>--anders

"Walter" <newshound@digitalmars.com> wrote in message news:d008bq$ukc$1@digitaldaemon.com...
>
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cvvuq4$ica$1@digitaldaemon.com...
>> Why? Does that prove you right? Me?
>>
>> All it says is that G++ is not perfect, which I already knew.
>>
>> How come sometimes all that's needed to justify something in D is to show something wrong in C++? Not much of an evolution. More like a statis in different colour.
>>
>> :-(
>
> I meant it as a comment as to whether the existence of such warnings
> make a
> compiler/language usable for serious development or not, and as a
> comment on
> its relative importance to developers in general.
>
> Why doesn't g++ warn on it? It has many other warnings.
>
> 1) is it too hard to implement? I doubt it. g++ implements many very
> hard
> things.
> 2) did the keepers of the main g++ branch reject such a warning? Why?
> 3) has nobody cared enough about that particular issue to implement
> it?

Maybe they don't care about it (which is what I presume you're getting at)? Other compiler vendors do.

I compile my libraries with various versions of ~10 compiler vendors, including GCC. Every single compiler, even Watcom, has provided me with a warning that I have found to be useful that the others have missed. It irks me that I need to go to such lengths, but I value the facility of doing so.

Your answer to this tiresome activity of the poor unpaid library writer is to just no worry about it. Mine is to pray for (several) standards-violating D compilers. I think both attitudes are regrettable, and I refuse to believe there's not a sensible, and largely agreeable, answer. If there isn't, then one would have to wonder whether that represented an underlying fundamental problem with D.

Dave wrote:

>>Also, there's a lot of interesting new stuff coming up on the C/C++
>>front, like system vendor's heavy optimizations and auto-vectorization,
>>that the D implementation will be missing out on and thus could lose...
> 
> If I'm understanding you correctly, you are talking about new compiler
> implementations, right?

Yes, specific example: GCC 3.3 and GCC 4.0 - with patches from Apple.

> Compared to C/C++, D the language should actually allow more aggressive
> optimization than C/C++ within the current confines of those languages (imports
> vs. headers is a great example).
> 
> Am I understanding you? Or are you speaking of proposals for the next C or C++
> language specs.?

Same old boring languages (C/C++), just better compilers for them.

--anders

<brad@domain.invalid> wrote in message news:cvvvqp$jo5$1@digitaldaemon.com...
> Matthew wrote:
>> 'cause if it's not part of the language spec, it might as well not exist.
>>
>> Several commentators (including IIRC, the original authors of the language; must trip off and check my copy of The Art Of UNIX Programming ...) have observed that the biggest single mistake in the development of the C language was having, for reasons of program size, the lint functionality as a separate program. Most people don't use it.
>>
>> Consider the case of C++, which is simply too complicated for an effective lint.
>>
>> And anyway, there's the more fundamental thing that if any item's going to be effectively mandatory in lint, it should be in the compiler in the first place. As I've said before, which competent C++ engineer does not set warnings to max?
>>
>
> I agree.  However, I think that with a lint like program built into
> the existing frontend via a #define would provide good quantitative
> evidence on this issue, and others.
> At the moment the whole thread boils down to "I like it one way" vs "I
> like it the other way".
> With a lint program built into the frontend, I think that you will
> have harder evidence either way.  For example, add narrowing warnings
> to the frontend, run it over Mango.  If it turns up genuine bugs, then
> the "warn on narrowing cast" crowd is proved right.  If it turns up no
> actual bugs, well Walter's case is stronger.
> At the moment it is just a face off between two (obviously qualified
> experts) who happen to have differing opinions.

Absolutely. There's nothing to be gained from our chronic incapability to resist the temptation of having the last word.

Action will prove it. Since Walter's the compiler writer, and (I presume) could add those warnings in within a day, I think it's appropriate to make the request of him, rather than waiting for the otherwise considerable efforts for any of the rest of us. I would think this would be of benefit to Walter, since he will undoubtedly learn something from it (as will we all!), and also stands to gain shutmouthedness from me and Kris, which he will not otherwise achieve.

MicroWizard wrote:

> Also, there's a lot of interesting new stuff coming up on the C/C++
>>front, like system vendor's heavy optimizations and auto-vectorization,
>>that the D implementation will be missing out on and thus could lose...
>>
>>I like that performance is a constant D focus. But it can't be *all* ?

> Performance is still an important issue nowadays, when everybody says
> ..want speed, buy a bigga machine...
> (Try to buy X, 2*X, X^2 or 2^X size machines when X is growing :-)

I did not say performance was unimportant, on the contrary...
I'm an old-time assembler/C nerd, so them's fighting words! :-)

Just think it would be sad to spend all time optimizing only
to be beaten by the C/C++ compilers anyway (since they "cheat")
and then getting run over because the code isn't correct... ?

--anders

"Dave" <Dave_member@pathlink.com> wrote in message news:d00055$k34$1@digitaldaemon.com...
> So would I (just for the educational aspects), but I'd rather have Walter
use
> that time to continue work on the reference compiler ;-)

Kris mentions slicing, that's just part of it. Slicing, *coupled with garbage collection* makes for a big win. Not having to keep track of ownership of memory means one can be much more flexible in designing and manipulating data structures. The need for copy constructors, move constructors, overloaded assignment operators, pretty much goes away. So not only is the code easier to write, there's much less that has to be executed. Ergo, faster.

I'll go out on a limb and say that there's no way Matthew is going to be able to beat D in the wc benchmark without writing a very ugly, kludgy piece of C++ hackery.

There's another, subtler issue of why D code is faster. I originally wrote DMDScript in C++ (and it used a gc, leveling the playing field with D on that issue). The C++ version was heavilly tuned with a lot of hacks in it to make it fast. I did a fairly rote translation of it into D (taking out the hacks). Initially, the D version was slightly slower. But then an interesting thing happened. The D version was significantly shorter and easier to express. I started rewriting a bit in a more "D" style than a C++ style. I found I could easilly experiment with different data structures and layouts. The C++ one was hard to change, data structures and algorithms in it are much more 'brittle'. So in just a few days, I was able to tweak the D version into being significantly faster, *without* the hacks I resorted to in the C++ version.

In other words, because expressing the algorithms is more straightforward, without the brittle framework C++ always seems to require, it's easier to see inefficiencies in those algorithms and change them.

> As to the 'performance via low-level control' type of argument, the recent thread on why higher level array and vector expressions could be optimized
by a
> compiler (but very difficult if not impossible to optimize as well with hand-tuned, low-level C code) offers a good general example of what I
think
> Walter had in mind w/ his statement.

Yes, you hit the nail on the head with that. With C++, optimizers need to
"reverse engineer" what was intended, which is much harder than optimizing
what was expressed directly. For another trivial example, in D you can write
code like:
    s ~ "xxx" ~ "yyy"
and the optimizer could combine the two strings at compile time.

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d005sa$r86$1@digitaldaemon.com...
>>> And anyway, there's the more fundamental thing that if any item's going to be effectively mandatory in lint, it should be in the compiler in the first place. As I've said before, which competent C++ engineer does not set warnings to max?
>>
>> A compiler's verboseness about warnings is entirely up to the compiler writer. If one doesn't like the lack of warnings in one compiler run or make another. GDC is a good candidate for a starting point. If all D has to worry about is the lack of warnings from the reference compiler then we are in great shape.
>
> But isn't the whole point to avoid dialecticism?

If by dialect you mean a different language then I disagree that having two compilers - one with warnings and one without - forks the language into two dialects. It's the same D underneath.

> At the rate it's going, DMD is going to be like Borland, an easy to use toy compiler that people learn on, but which is simply not good enough for any serious development. I can't believe that's in line with Walter's ambitions for Digital Mars (as opposed to D).

I find it hard to believe that DMD lives and dies for "serious development" based on the verbosity of its warnings. I think D will live or die for serious development if there is a lack of tools, libraries and community surrounding it.

> Anyway, I tire of this, mainly my own voice if I'm honest. I'll try my best to keep my word and shut up.

It seems to me a joke...

>I just said that if a program is not correct, it's performance is absolutely irrelevant.

Triviality.

>I have worked on several projects over the last decade where (practical) correctness was of paramount importance. They also had exacting performance requirements. They were written in C/C++. They've all worked fine for months/years without a single failure once they've gone into production. Had they performed well but only been roughly correct, there'd've been losses of $Ms, and the clients wouldn't have cared a toss that the performance was good.

And I worked on several banking, database, stock exchange dataproviding,
industrial automation, bookkeeping bla-bla-bla project (as a programmer
and as project manager also).
C/C++ were never the _correct_ but a "we should try it because it is extremely
fast" language. The development is painful, few (average) programmers
understand what it does, easy to make bugs...
What were correct: Basic, MUMPS, Turbo Pascal, Clipper, FoxPro, LINC,
DOS batch, nowadays PHP, Java ... they did what we wrote (generally :-)

This conversation remembers me an old hungarian TV advertisement.
Which is almost a joke. Two small children sit in the sand on a playground.
They are vying/talking about what kind of insurance their fathers have...
(Like Tom and the new guy in Mark Twain's Tom Sawyer)

If it hurts you, please forgive me.

Tamas Nagy