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.

First sensible entry for a while!

OTOH, isn't this as it's supposed?
We are pre 1.0. Most other languages
haven't been this far even at 3.0!

Not that these shouldn't be fixed, of course. ;-)

> Can you list those areas, please?

Walter wrote:
> "Georg Wrede" <georg.wrede@nospam.org> wrote in message
> news:42231636.8090805@nospam.org...
> 
>>Give a toy, and they're happy
>>for the day. But what to do to get them happy _for the rest of their
>>lives_?
> 
> 
> Ultimately, they decide for themselves if they're going to be happy or not.
> You cannot cause them to be happy. Probably the best you can do is help them
> realize this, and that if they expect that things or other people will make
> them happy, they'll be disappointed.

True.

Now, that I don't see them every week (we're separated, as you remember), it occasionally worries me, though. My ex is not too good at this sort of thing, so the entire burden is on my (remote) shoulders.

But why whine, I didn't take the kids to Thailand this Christmas. For long it was an option.

Georg Wrede wrote:

> OTOH, isn't this as it's supposed?
> We are pre 1.0. Most other languages
> haven't been this far even at 3.0!

I think it was either of "Mac OS X 10.x",
the "Windows 2000" / "XP" releases of NT 5.x,
or "Java 2 Platform Standard Edition (J2SE)
version 5.0" release of JDK 1.5 that has
convinced me that Marketing has destroyed
all notions of version numbers forever... :-)

But you are right. It's pre-release still.

--anders

"Roberto Mariottini" <Roberto_member@pathlink.com> wrote in message news:d01bt4$25h8$1@digitaldaemon.com...
> Once again, what about doing this at runtime? Like the common "missing
> default
> in a switch" error, such narrowing conversion errors can be found at
> runtime
> (and I'd add overflows):
>
> int i = 256;
> ubyte b1 = (ubyte) i; // no error: explicit cast
> ubyte b2 = i; // throws NarrowCastError at runtime in debug builds

I was going to suggest the same thing.

<soapbox>I don't see why, when it comes to an impasse over preference, you guys don't look for *other* solutions.  Back up in your decision tree, so to speak.  In the end, and I've said it before, if you get mired in preference, and Walter is writing the language, then Walter wins.  So the impetus is really on Matthew or whoever to find other creative solutions when the only difference is preference.</soapbox>

Here are a couple of other ideas:

    int i = 32;
    ubyte b1 = (ubyte) i; // not allowed; don't care if it *would* fit.

I've been programming at various levels for 20 years, and I can't remember any times that one really wanted to overflow an integer or even "narrow" one in practice.  The exception which proves the rule is

    unsigned int c = -1;    // to get 0xFFFFFFFF

Part of the excuse is that the coder doesn't have a set size for an int. And I think this one comes up now and then as a "hack" that should be avoided and replaced with

    unsigned int c = ~0;

Can others name good situations for "narrow casting"?  If there were no cast and trying it without a cast were an error, coders would be forced to "upgrade" the LHS even if it propogates up the code tree.  OK.  Admittedly this is harsh, because you can never get narrow casted if you want, but I can't think of reasons it would be necessary to narrow cast.  The run-time check in debug sounds pretty good.

In short, if you consider comp langs as a way to express math sans infinity, overflow and lost most significant bits is simply an error.  Not something that you might need occasionally.

The solution categories for a language problem X are

* always trust the coder knows what he's doing and let X through,
* allow implicit X but check at run-time (probably in debug only for speed),
* allow the coder to explicity force X,
* allow the coder to explicity force X, but check at run-time (probably in
debug only for speed),
* always stop the coder from doing X
* avoid the issue of X altogether

"Walter" <newshound@digitalmars.com> wrote in message news:d00n60$1e5e$1@digitaldaemon.com...
> D expends a lot more cost on trying to prevent the latter than the former. Things like array bounds checking, guaranteed initialization, garbage collection, etc., are examples of such steps.

Hmm, I was more on Walter's side of this until the list came out.  (-:  I agree that pointer intialization, for instance, can be costly to find. However, I haven't made a bounds mistake in years (but I still think checking it is nice and maybe for newbs), and lack of regular variable initialization isn't so bad, and garbage collection was just for making coding easier for me, not really bugs.  So, now I'm thinking there is a continuum here and casting issues are about par with array bounds, to me. So if array bounds deserve run-time checks then I think casts might, too, in my experience.

"Walter" <newshound@digitalmars.com> skrev i en meddelelse news:d00oun$1frg$1@digitaldaemon.com...
> I noticed that you're using memory mapped files! Cheater! <g> Trying the D
> version with std.mmfile, I get about a 10% speedup. It adds one line of
> code
> and an import.
> Anyhow, I think the effort you made just shows the point!

I partly agree. The std::string is a sorry accident of history, and without reference counting, it has very little to offer compared to vector<char>. But no string type will fit for all purposes. If you really are going for efficiency, you need some specialized string handling, and my point is, that you can have that in C and C++ too (but STL will not help you). The slicing concept of D is strong, and my solution in C++ was using slices too. Of cause much less elegantly than in D :-)

Another win for the D version, is its associative arrays which I suspect are hash tables internally. STL does not offer hash tables yet, but that does not mean that you cannot have them anyway. You just need to look elsewhere.

Regards,
Martin

On Tue, 01 Mar 2005 18:39:14 +1300, brad beveridge <brad@nowhere.com> wrote:
> Why not have the compiler be able to run programs at compile time?  What I mean is that the DMD config file can have a set of (I hate to say this word) "preprocessors", programs that get run before the real compiler and get passed the same input as the compiler.

I don't think you want 'lint' to run before the compile, but rather after, I mean, if compile fails, who cares what lint says?

> Sure, you can do this with a script - but then people won't bother.  So, in this way the compiler can remain pure - either code passes or fails, and you can enforce the running of a lint (or anyother) program transparently.

I think it's a good idea, once a lint program has been written it can be bundled with the compiler and this configured to happen automatically, this serves to get everyone doing it, by default.

You'd then use lint on your dev box, and disable it on your build boxes.

> D could potentially check the return values from those programs and fail to run if any of the "preprocessors" fail.

I don't think lint processesing will give a pass/fail result.. it will simply give a list of things to double check, things you should check then either fix, or ignore.

Incidently, if you want to ignore a lint warning, how do you go about doing that?

I mean, you could just ignore it, but it will still popup every compile and may obfuscate other lint warnings.

> As long as D supports different config files (ie, look for the config file in the current directory first, then /etc/dmd.conf), then you can make sure that you have global sensible options, with project specific overrides.
>
> This is also in keeping with the philosophy that each program should do one task and do it well.  There is some lost efficiency in multiple handling of the files, but D is so fast at compiling that I think that would be minimal.

The lint program is going to need to read object files also, isn't it, because some lint warnings might be based on global variables, types etc defined outside the source file it's processing..

Regan

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsmy95bqr23k2f5@ally...
> On Tue, 01 Mar 2005 18:39:14 +1300, brad beveridge <brad@nowhere.com> wrote:
>> Why not have the compiler be able to run programs at compile time?  What I mean is that the DMD config file can have a set of (I hate to say this word) "preprocessors", programs that get run before the real compiler and get passed the same input as the compiler.
>
> I don't think you want 'lint' to run before the compile, but rather after, I mean, if compile fails, who cares what lint says?

That sounds reasonable though I can see why people would want to know about linting info independent of whether the compile worked or not. I can see arguments for running either before or after.

>> Sure, you can do this with a script - but then people won't bother.  So, in this way the compiler can remain pure - either code passes or fails, and you can enforce the running of a lint (or anyother) program transparently.
>
> I think it's a good idea, once a lint program has been written it can be bundled with the compiler and this configured to happen automatically, this serves to get everyone doing it, by default.
>
> You'd then use lint on your dev box, and disable it on your build boxes.
>
>> D could potentially check the return values from those programs and fail to run if any of the "preprocessors" fail.
>
> I don't think lint processesing will give a pass/fail result.. it will simply give a list of things to double check, things you should check then either fix, or ignore.

agreed.

> Incidently, if you want to ignore a lint warning, how do you go about doing that?

The lint program should have ways of customizing the output to filter some messages you don't ever want to see.

> I mean, you could just ignore it, but it will still popup every compile and may obfuscate other lint warnings.
>
>> As long as D supports different config files (ie, look for the config file in the current directory first, then /etc/dmd.conf), then you can make sure that you have global sensible options, with project specific overrides.
>>
>> This is also in keeping with the philosophy that each program should do one task and do it well.  There is some lost efficiency in multiple handling of the files, but D is so fast at compiling that I think that would be minimal.
>
> The lint program is going to need to read object files also, isn't it, because some lint warnings might be based on global variables, types etc defined outside the source file it's processing..

Lint doesn't check link errors - only syntax and probably some semantics errors. So it won't need to look at object files. The first pass - syntax checking - can also happen without looking at other source files. I don't know how much semantic analysis is possible without looking at the imports, though. Probably not much.

>
> Regan

On Tue, 1 Mar 2005 17:01:56 -0500, Ben Hinkle <bhinkle@mathworks.com> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opsmy95bqr23k2f5@ally...
>> On Tue, 01 Mar 2005 18:39:14 +1300, brad beveridge <brad@nowhere.com>
>> wrote:
>>> Why not have the compiler be able to run programs at compile time?  What
>>> I mean is that the DMD config file can have a set of (I hate to say this
>>> word) "preprocessors", programs that get run before the real compiler
>>> and get passed the same input as the compiler.
>>
>> I don't think you want 'lint' to run before the compile, but rather after,
>> I mean, if compile fails, who cares what lint says?
>
> That sounds reasonable though I can see why people would want to know about
> linting info independent of whether the compile worked or not. I can see
> arguments for running either before or after.

True, given that it's a seperate app, they can run it stand-alone, whenever they like.

>>> Sure, you can do this with a script - but then people won't bother.  So,
>>> in this way the compiler can remain pure - either code passes or fails,
>>> and you can enforce the running of a lint (or anyother) program
>>> transparently.
>>
>> I think it's a good idea, once a lint program has been written it can be
>> bundled with the compiler and this configured to happen automatically,
>> this serves to get everyone doing it, by default.
>>
>> You'd then use lint on your dev box, and disable it on your build boxes.
>>
>>> D could potentially check the return values from those programs and fail
>>> to run if any of the "preprocessors" fail.
>>
>> I don't think lint processesing will give a pass/fail result.. it will
>> simply give a list of things to double check, things you should check then
>> either fix, or ignore.
>
> agreed.
>
>> Incidently, if you want to ignore a lint warning, how do you go about
>> doing that?
>
> The lint program should have ways of customizing the output to filter some
> messages you don't ever want to see.

Ok, but what if it's a warning about x, and you do want to know about x, because it might be a bug, but in this one instance you've already decided it's not. Basically it seems to me you want to be able to ignore x in this instance only.

Or does that never occur for some reason?

>> I mean, you could just ignore it, but it will still popup every compile
>> and may obfuscate other lint warnings.
>>
>>> As long as D supports different config files (ie, look for the config
>>> file in the current directory first, then /etc/dmd.conf), then you can
>>> make sure that you have global sensible options, with project specific
>>> overrides.
>>>
>>> This is also in keeping with the philosophy that each program should do
>>> one task and do it well.  There is some lost efficiency in multiple
>>> handling of the files, but D is so fast at compiling that I think that
>>> would be minimal.
>>
>> The lint program is going to need to read object files also, isn't it,
>> because some lint warnings might be based on global variables, types etc
>> defined outside the source file it's processing..
>
> Lint doesn't check link errors - only syntax and probably some semantics
> errors. So it won't need to look at object files. The first pass - syntax
> checking - can also happen without looking at other source files. I don't
> know how much semantic analysis is possible without looking at the imports, though. Probably not much.

I was thinking of a "narrowing integer conversions warning", say you're assigning a value to a global int. Lint would need to know that global was an int in order to give a warning about it.

Regan

> 
> Ok, but what if it's a warning about x, and you do want to know about x,  because it might be a bug, but in this one instance you've already decided  it's not. Basically it seems to me you want to be able to ignore x in this  instance only.
> 
> Or does that never occur for some reason?
I think that this would be a hard problem in general.
 - You could use a pragma to suppress the warning, but that results in ugly code
 - You could use a config file to suppress specific warnings on specific lines, but that will break when the code moves
 - You could use a config file to suppress specific warnings within a function and happening on a particular symbol, but that may be too coarse
 - You could do as above, and specify the count, if the counts don't match, warn.  Ie - "suppress narrow cast : foo.d : main : counter : 2" could perhaps mean, suppress the narrowing cast warnings for the foo.d file, within the function main, happening on the symbol counter - and suppress 2 of them.  If you change the code so that lint doesn't see exactly 2 narrowing casts on that symbol in that function, then it warns again.

Hand editing config files sucks, but presumably if you are super paranoid and have lint set to super-paranoid, then you won't mind suppressing the genuine occasions that you know better.

Brad