On Tue, 1 Mar 2005 11:24:35 +1100, Matthew wrote:

> Using the Arturius Compiler Multiplexer (coming to a download site to you sometime this year .... don't hold your breath):
> 
> H:\Dev\Test\compiler\D_warnings>arcc.debug
> D_warnings.cpp -c --warning-level=maximum --announce-tools
> arcc: Intel C/C++
> Tool: bcc/5.6
> D_warnings.cpp(5): Warning W8071 : Conversion may lose significant
> digits in function foo(char)
> D_warnings.cpp(6): Warning W8071 : Conversion may lose significant
> digits in function foo(char)
> Tool: cw/7
> ### mwcc.exe Compiler:
> #    File: D_warnings.cpp
> # -----------------------
> #       3:  {
> # Warning:  ^
> #   function has no prototype
> ### mwcc.exe Compiler:
> #       5:      foo(i);
> # Warning:           ^
> #   implicit arithmetic conversion from 'int' to 'char'
> ### mwcc.exe Compiler:
> #       5:      foo(i);
> # Warning:            ^
> #   result of function call is not used
> ### mwcc.exe Compiler:
> #       6:      c = c + 1;
> # Warning:               ^
> #   implicit arithmetic conversion from 'int' to 'char'
> Tool: cw/8
> ### mwcc.exe Compiler:
> #    File: D_warnings.cpp
> # -----------------------
> #       3:  {
> # Warning:  ^
> #   function has no prototype
> ### mwcc.exe Compiler:
> #       5:      foo(i);
> # Warning:           ^
> #   implicit arithmetic conversion from 'int' to 'char'
> ### mwcc.exe Compiler:
> #       5:      foo(i);
> # Warning:            ^
> #   result of function call is not used
> ### mwcc.exe Compiler:
> #       6:      c = c + 1;
> # Warning:               ^
> #   implicit arithmetic conversion from 'int' to 'char'
> Tool: dm/8.40
> Tool: dm/beta-sgi
> Tool: dm/beta-stlport
> Tool: gcc/2.9.5
> Tool: gcc/3.2
> Tool: gcc/3.3
> Tool: gcc/3.4
> Tool: icl/6
> Tool: icl/7
> D_warnings.cpp(2): remark #1418: external definition with no prior
> declaration
> Tool: icl/8
> D_warnings.cpp(2): remark #1418: external definition with no prior
> declaration
> Tool: ow/1.2
> [OW;Ruby]: D_warnings.cpp(5): Warning! W716: col(9) integral value may
> be truncated
> D_warnings.cpp(5): Warning! W716: col(9) integral value may be truncated
> [OW;Ruby]: D_warnings.cpp(6): Warning! W716: col(11) integral value may
> be truncated
> D_warnings.cpp(6): Warning! W716: col(11) integral value may be
> truncated
> [OW;Ruby]: Error: Compiler returned a bad status compiling
> 'D_warnings.cpp'
> Tool: vc/2
> D_warnings.cpp(5): warning C4244: 'function' : conversion from 'int' to
> 'char', possible loss of data
> D_warnings.cpp(6): warning C4244: '=' : conversion from 'const int' to
> 'char', possible loss of data
> Tool: vc/4.2
> D_warnings.cpp(5): warning C4244: 'function' : conversion from 'int' to
> 'char', possible loss of data
> D_warnings.cpp(6): warning C4244: '=' : conversion from 'const int' to
> 'char', possible loss of data
> Tool: vc/5
> D_warnings.cpp(5): warning C4244: 'argument' : conversion from 'int' to
> 'char', possible loss of data
> D_warnings.cpp(6): warning C4244: '=' : conversion from 'int' to 'char',
> possible loss of data
> Tool: vc/6
> D_warnings.cpp(5): warning C4244: 'argument' : conversion from 'int' to
> 'char', possible loss of data
> D_warnings.cpp(6): warning C4244: '=' : conversion from 'int' to 'char',
> possible loss of data
> Tool: vc/7
> D_warnings.cpp(5): warning C4244: 'argument' : conversion from 'int' to
> 'char', possible loss of data
> h:\dev\test\compiler\d_warnings\d_warnings.cpp(8): warning C4717: 'foo'
>: recursive on all control paths, function will cause runtime stack
> overflow
> Tool: vc/7.1
> D_warnings.cpp(5): warning C4242: 'argument' : conversion from 'int' to
> 'char', possible loss of data
> h:\dev\test\compiler\d_warnings\d_warnings.cpp(8): warning C4717: 'foo'
>: recursive on all control paths, function will cause runtime stack
> overflow
> Tool: vc/8
> D_warnings.cpp(5): warning C4244: 'argument' : conversion from 'int' to
> 'char', possible loss of data
> h:\dev\test\compiler\d_warnings\d_warnings.cpp(8): warning C4717: 'foo'
>: recursive on all control paths, function will cause runtime stack
> overflow
> 
> H:\Dev\Test\compiler\D_warnings>
> 
> "Walter" <newshound@digitalmars.com> wrote in message news:d00cg1$13em$1@digitaldaemon.com...
>>
>> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d008rv$v8k$1@digitaldaemon.com...
>>> Maybe they don't care about it (which is what I presume you're getting
>> at)?
>>
>> I'd consider that the most likely.
>>
>>> Other compiler vendors do.
>>
>> I just tried it with Comeau with "strict mode" http://www.comeaucomputing.com/tryitout/. No warnings.
>>
>>> 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.
>>
>> I'd be curious of the results of that snippet (and the other one I
>> posted)
>> run through each. It'd be fun to see the results. Every compiler has
>> its own
>> personality, and the warnings reflect the particular biases of its
>> developer. Warnings are not part of the language standard, and there
>> are no
>> standard warnings, despite some attempts to put them in.
>>
>>> 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.
>>
>> Why would it be a problem with D and not with the other languages?
>> Anyone
>> implementing a D compiler is free to add warnings to it for whatever
>> they
>> feel it justifiable, just like they are with C++.
>>
>>

I'm with Matthew on this one. The more warnings the better, so long as they are under the coder's control. I *hate* surprises in my code. If I can explicitly code away a warning (either by 'fixing' the code or telling the compiler that I'm grown up and will accept the consequences), I will do it.

This has also shown me that there are some real wimpy C compilers out there.

-- 
Derek
Melbourne, Australia
1/03/2005 11:44:36 AM

"Derek Parnell" <derek@psych.ward> wrote in message news:110v9i57xoxck$.kym8gprc7gyx$.dlg@40tude.net...
> D appears to have a *bloody huge* potential to excel in reducing costs to both purchasers and developers. Currently however, it can't be used to produce cheaper commercial software because its still a Work-In-Progress, and has many areas that cry out for tidying up.

Can you list those areas, please?

On Mon, 28 Feb 2005 16:41:07 -0800, Walter wrote:

> "Derek Parnell" <derek@psych.ward> wrote in message news:110v9i57xoxck$.kym8gprc7gyx$.dlg@40tude.net...
>> D appears to have a *bloody huge* potential to excel in reducing costs to both purchasers and developers. Currently however, it can't be used to produce cheaper commercial software because its still a Work-In-Progress, and has many areas that cry out for tidying up.
> 
> Can you list those areas, please?

Glad to, but later. I'll be back soon. Got some clients coming in to see me in a few minutes.


-- 
Derek
Melbourne, Australia
1/03/2005 11:55:59 AM

"xs0" <xs0@xs0.com> wrote in message news:d00dq4$14vh$1@digitaldaemon.com...
>
>
> Matthew wrote:
>>>short=short+5; // OK - 5 fits into short
>>
>>
>> Not necessarily
>>
>>
>>>int=byte+1+int; // OK, this is the above example
>>
>>
>> Not necessarily
>
> And your point is? That + should be forbidden, because the result may overflow?

No, my point was to correct a mistake in the post.

> If int=int+int+int is deemed completely acceptable (or don't you agree even with this?), I don't see how int=byte+5+int can be not acceptable?

These things are what's under debate. I don't believe I've defined a precise and overarching policy. Indeed, I'm suggesting that stipulating such a policy - as is currently the case with D's "all integral=>integral conversions are valid" - is a mistake.

So, pay attention, don't misrepresent, and save your sarcasm for when you have some ammo.. In the meanwhile why not try and contribute to the debate?

While I may not necessarily be in full accord with either Kris's content or his presentation in this particular post, I do think he has something of a point.

Let me put a question to you Walter:

    1. I have found bugs in my C/C++ code involving
unintended/undesirable integral narrowing. This is a fact. If you cannot
accept this, then we have no basis for discussion. Do you accept this to
be so?
    2. D provides, by definition, no facility for
detecting/warning/remedying unintended/undesirable integral narrowing.
This is a fact. Do you accept this to be so?

Now I am NOT saying that D's integral conversion is wrong. I'm NOT saying it has to be changed. I'm NOT saying DMD (and every other compiler) must have narrowing warnings.

What I AM saying is that, if 1 is true, and 2 is true, then one can draw one of two conclusions:

    A. D is flawed, by design, since errors due to integral narrowing
cannot be automatically detected, other than by tools that do not
represent the absolute letter of the language definition. Or,
    B. D is different from C/C++ in a fundamental way such that the
truth of 1. does not affect 2.

What I'm asking, Walter, is for you to tell me:

    - that 1. is wrong, or
    - that 2. is wrong, or
    - that A holds, or
    - that B holds

I don't want/need to hear any more examples of stupid and pointless conversion warnings/errors, because I absolutely admit they are legion. I don't want/need to have to demonstrate the contrary position of dangerous unwarned/unerrored conversions, because they are also legion.

I just want to know which of the above four is true. Whichever of those four it is, I'd like some explanation, but at this point I'd just settle for the bald answer.

I don't care what the solution is, either, because this ng is full of super smart people. But to get a solution requires a problem, which is where the answer comes in.

Cheers

Matthew



"Kris" <Kris_member@pathlink.com> wrote in message news:d00dfj$14nj$1@digitaldaemon.com...
> In article <d006j3$s40$1@digitaldaemon.com>, Walter says... [snip]
>>I disagree strongly on this. Unless you have something else in mind
>>I'm
>>forgetting, in your posts you've focussed in on two or three issues
>>and have
>>assigned major importance to them. None of them, even if they go awry
>>in the
>>manner you predict, will cause the kinds of erratic, random, awful
>>bugs that
>>C++ holes mentioned above will and do cause. All of them, as I've
>>argued
>>(and you and Kris disagree, fair enough), will open the door to other
>>kinds
>>of correctness bugs if they are fixed per your suggestions.
>
>
> Suggestions? Fixes? What?
>
> How can one get to the point of remedy when one cannot get you to even
> tentatively admit there might /actually/ be a problem to begin with?
> That has to
> happen before one can even begin to weight the odds. You know? That
> thing about
> getting the Moose onto the Table? This is what's so infuriating. It's
> called
> denial, or stonewalling.
>
> I've tried all kinds of ways to elicit some real honesty about the
> current
> design, over almost a year, yet you've been consistent in denying the
> very
> possibility of issue (not to mention the measurable quantities of
> subtle
> misinformation, which is yet more frustrating). How can you possibly
> say I, or
> anyone else, has managed to even begin to offer a resolution when you
> simply
> deny, deny, and deny again? And besides, the point is not necessarily
> for us to
> offer resolutions, but hopefully to encourage you to think of one.
>
> Where the forthright interaction here? I've yet to witness a discourse
> upon a
> serious topic with you, where it did not feel like I'm corresponding
> with the ex
> Iraqi Information Minister ~ like there's a whole lot of spin and very
> little
> truth. I see you using the same approach with certain others, but the
> vast
> majority are spared.
>
> Is this in line with your expectations?
>
> This is what troubles me far more than anything, manifest or not,
> within the D
> language itself. I mean, it's just another computer language ~ take it
> or leave
> it. What I find disturbing is that neither I, nor anyone else, can
> make
> /serious/ critique of the language without a corresponding barrage of
> denial and
> something resembling marketing propoganda.
>
> Where's the constructive discourse?
>
> Naturally, you might find that my approach is not to your liking.
> Perhaps I'm
> overly brusque for your taste. Perhaps I just get your back up.
>
> Since you've made a point about not replying to my last several posts,
> if you
> choose to not answer this one I'll understand the message loud and
> clear.
>
> - Kris
>
> 

In article <d00ba7$125c$1@digitaldaemon.com>, Walter says...
>
>
>"Kris" <Kris_member@pathlink.com> wrote in message news:cvvuhc$hqd$1@digitaldaemon.com...
>> In article <cvvp0e$b66$1@digitaldaemon.com>, Walter says...
>> >CPUs are designed to execute C semantics
>> >efficiently. That pretty much nails down accepting C's operator
>precedence
>> >and default integral promotion rules as is.
>> Misleading and invalid.
>
>Correct, but that's because much of the context is omitted. I wrote:
>
>"D, being derived from C and C++ and being designed to appeal to those programmers, is designed to try hard to not subtly break code that looks the same in both languages. CPUs are designed to execute C semantics efficiently. That pretty much nails down accepting C's operator precedence and default integral promotion rules as is."
>
>The second sentence just adds to the first, it does not stand alone. Where D does break from C/C++ is in things that look different, or that will issue error messages if the C syntax is tried.
>
>Many older CPUs had special instructions in them that catered to Pascal compilers. With the decline of Pascal and the rise of C, there was a change to support C better and drop Pascal. No CPU designer expects to stay in business if their new design does not execute compiled C efficiently. Intel added special instructions to support C integral promotion rules, and made darn sure they executed efficiently. If you carefully read their optimization manuals, they don't give much attention to the performance of integer operations that are not normally generated by C compilers.
>
>Changes in compiler code generation techniques led to a complete redesign of the FPU instructions.
>
>Even Java was forced to change their semantics to allow for the way Intel FPUs operated. And if you follow Java, you'll know how resistant Sun is to making any changes in the VM's semantics, it has to be a huge issue.
>
>Were that D was big enough in the market to dictate CPU design, but it isn't. C is, but even Java isn't. As such, it just makes sense to work with what works efficiently. I honestly believe that if D gets a reputation of being less efficient than C/C++, it will be dead in the marketplace. Look at all the drubbing Java gets over this issue, and the enormous resources Sun/IBM/etc. pour into trying to fix it.
>
>I believe Ada does what you wish (been a long time since I looked at it), but it just isn't very successful.


What I wish? What do I wish for, Walter? I can't even get you to the point of discourse without an avalanche of blanket denials.

The above is just another example of what I noted in another post: you completely ignored the salient points about the questionable tight bonding you seem to believe in, or any of the other points, and replied with more of the same branded gumph you're becoming so adept at. You'd think we all worked in the laundry rather than being steeped in this stuff ourselves.

If you'd have bothered to address the other points also, then fair play. But that's not your recent style.

Please read back what you wrote. It's exactly the kind of misguidance that diminishes your position as a realist. It's not even particularly factual. And in reply to a post that noted you should /not/ be coupling the language model /directly/ to the CPU model. There's no need to do that, as you are no doubt intensely aware.

I'm astonished.

And thanks for the subtle direction on language choice, dude. Along with the unnesessary 'success' sarcasm. I imagine that's the closest you'll get to saying "F-off, Kris". This is hardly the manner in which to limit escalation, Walter.


Please take a good look at what's happened here:

1) An issue arises with the language, some examples are knocked around

2) it seems that there are maybe some issues, maybe not

3) I, and certain others, are concerned that method-resolution is not what it's perhaps cracked up to be: some new limitatons come to light

4) Some old notions are brought to the fore again, within a somewhat different perspective than before

5) There's a whole spat of denial from you that anything could possibly be wrong, mixed in with the kind of spin that would make some marketeers blush. You make noises about "my wishes" or "Matthew's wishes", when we can't even get you to the point of rational discussion.

6) You make subtle and vaguely sarcastic overtones that I move on from D


Way to go, dude. That's constructive co-operation at it's best. There may be little love lost between us Walter, but I've still given over a vast quantity of my time and effort to help this thing along. During that time, I've often felt that the biggest impediment to the success of D is the stranglehold you have upon it, combined with your outright stubborness and your apparent lack of experience in a variety of software realms beyond writing compilers.

You are certainly most adept at the latter, but language design must account for many things other than bit-twiddling. I have no doubt you already know this. But you often act as though you don't.

Finally, it's worth pointing out that regardless of how far apart our positions might seem, the truth (as is so often the case) lies somewhere between. You don't have all the answers Walter; I doubt any of us do. It's why open-minded discussion is generally viewed as a good thing.

"Walter" <newshound@digitalmars.com> skrev i en meddelelse news:cvvqp9$d89$1@digitaldaemon.com...
> I challenge you to take the C++ program in
> www.digitalmars.com/d/cppstrings.html and make it faster than the D
> version.
> Use any C++ technique, hack, trick, you need to.

I could not resist having a go at it.

The following are my results for the attached version:

    dmd -o -release          359 ms
    dmc -o -6                   375 ms
    cl -Ox -G6 -ML         296 ms

I used an input file with 64 times "alice30.txt" to have something measurable. "cl" is MSVC 7.1.

Regards,
Martin

Martin M. Pedersen wrote:
> "Walter" <newshound@digitalmars.com> skrev i en meddelelse news:cvvqp9$d89$1@digitaldaemon.com...
> 
>>I challenge you to take the C++ program in
>>www.digitalmars.com/d/cppstrings.html and make it faster than the D version.
>>Use any C++ technique, hack, trick, you need to.
> 
> 
> I could not resist having a go at it.
> 
> The following are my results for the attached version:
> 
>     dmd -o -release          359 ms
Can you please use the -O switch and post results?

Brad

<brad@domain.invalid> skrev i en meddelelse news:d00i8f$19dg$1@digitaldaemon.com...
>>     dmd -o -release          359 ms
> Can you please use the -O switch and post results?

Sorry, I didn't write it as I compiled it. I used "dmd -O -inline -release" and consistently get 359/360 ms.

Regards,
Martin

"Martin M. Pedersen" <martin@moeller-pedersen.dk> wrote in message news:d00i1o$1974$1@digitaldaemon.com...
> "Walter" <newshound@digitalmars.com> skrev i en meddelelse news:cvvqp9$d89$1@digitaldaemon.com...
>> I challenge you to take the C++ program in
>> www.digitalmars.com/d/cppstrings.html and make it faster than the D
>> version.
>> Use any C++ technique, hack, trick, you need to.
>
> I could not resist having a go at it.
>
> The following are my results for the attached version:
>
>    dmd -o -release          359 ms
>    dmc -o -6                   375 ms
>    cl -Ox -G6 -ML         296 ms
>
> I used an input file with 64 times "alice30.txt" to have something measurable. "cl" is MSVC 7.1.
>
> Regards,
> Martin
>

Well, the code has very little C++ in it (the only STL is the sort at the end). No use of C++ strings. But technically, yes, it does count as a C++ program since it can be compiled by a C++ compiler. But I think it misses the spirit of Walter's challenge. I'd be curious what the D compiler's performance would be on that code ported to D. Since the code is almost entirely C it should be pretty easy to write a D version.

-Ben