July 20, 2004
Then where does one post specification bugs? :-)


July 20, 2004
In article <cdjc7b$1jfu$1@digitaldaemon.com>, Bent Rasmussen says...
>
>Then where does one post specification bugs? :-)

I'm not sure if that's meant to be a rhetorical question, but I'll try to respond anyway.

My opinion: it depends on what you mean by "specification bugs".

Here's some proposed guidelines...

Post to dm.D.bugs
-----------------
if you find a possible typographical error in the spec
if the compiler doesn't follow the spec
if the compiler produces a confusing or incorrect error message
if the compiler crashes without even producing an error message
if the compiler produces an executable that behaves unexpectedly
(This list isn't all-inclusive.)


Post to dm.D
------------
if you want to change the spec significantly (yes, it's a judgment call)
if you don't understand an idea in the spec
if you don't like an idea in the spec
if you think the spec needs more examples
if you think the spec is incomplete (unless you think it's really, really
incompelte)
if a thread in dm.D.bugs drifts like this one has into broader concepts (oops)
(This list definitely isn't all-inclusive.)


No one has to agree with me on any of these, but this is how I try to decide where to post. Until I realize I'm posting in the wrong place.

By the way, for a long time I was opposed to having separate newsgroups because I didn't want to read a bunch of bickering about which threads belong in which newsgroups. Polite comments and discussions about the topic are appropriate (how else could we reach consensus?), but posting "WRONG NEWSGROUP, STUPID" would be bad. I hope we can remember how these newsgroups used to be more civil. Ah, the good old days...

jcc7
July 20, 2004
"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cdikf7$18m6$1@digitaldaemon.com...
> Although I think Dereks' being simplistic - since after all one might
write
> a function such as that shown below - I still agree with his sentiment. I never write code that precipitates such responses from the compiler, and voila, I never get those responses. Now I'm not saying you're wrong, but I think issues such as this should be on the back of the queue.

I don't agree one might never write such a function. I'll do it sometimes to fill in stubs that I intend to work on later, and the exception thrown will remind me if I forget. I'll also do it to fill in stubs required by something else, but that I know will never actually be called. (Such as putting a stub implementation for an abstract function required by an interface, but which would be an error for your circumstances.)


July 20, 2004
"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cditku$1cah$1@digitaldaemon.com...
> In article <cditbh$1c4m$1@digitaldaemon.com>, Arcane Jill says...
>
> Only in D could you do this!
>
> #    void main()
> #    {
> #        return;
> #        printf("hello world\n");
> #    }

This is allowed in D (and in C, C++) because it comes in handy when debugging code. For example, I may wish in the process of isolating down a bug to just 'stub out' a function by putting in a return as the first statement. I do this stuff all the time.

I'll also do things like force a particular branch to happen by changing:
    if (x) { ... } else { ... }
to:
    if (1 || x) { ... } else { ... }
or:
    if (0 && x) { ... } else { ... }

The optimizer will remove any dead code.


July 20, 2004
I use two guidelines: common sense and politeness, the rest is implicit.


July 21, 2004
You're just trying to be nice to me, now.

I don't think it suits either of us. ;)

"Cabal" <cabalN05P4M@myrealbox.com> wrote in message news:cdj4to$1fqh$1@digitaldaemon.com...
> Christ no! I'll buy the other 50% of the run :)
> When you aren't being all religious you seem to know a fair old bit about
> D...
>
> > So you're not going to be fighting through the crowds in the bookshop in September?
> >
> > Sigh, I'll have to ring AWL and tell them to cut down the print run.
>


July 21, 2004
"Walter" <newshound@digitalmars.com> wrote in message news:cdjo8s$1p14$2@digitaldaemon.com...
>
> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cdikf7$18m6$1@digitaldaemon.com...
> > Although I think Dereks' being simplistic - since after all one might
> write
> > a function such as that shown below - I still agree with his sentiment. I never write code that precipitates such responses from the compiler, and voila, I never get those responses. Now I'm not saying you're wrong, but I think issues such as this should be on the back of the queue.
>
> I don't agree one might never write such a function. I'll do it sometimes to fill in stubs that I intend to work on later, and the exception thrown will remind me if I forget. I'll also do it to fill in stubs required by something else, but that I know will never actually be called. (Such as putting a stub implementation for an abstract function required by an interface, but which would be an error for your circumstances.)

What, old buddy? We're disagreeing! Say it ain't so.

Will it be two books, in one? A psychotic spawn with a split personality. :-)



July 21, 2004
Walter wrote:

>"Arcane Jill" <Arcane_member@pathlink.com> wrote in message
>news:cditku$1cah$1@digitaldaemon.com...
>  
>
>>In article <cditbh$1c4m$1@digitaldaemon.com>, Arcane Jill says...
>>
>>Only in D could you do this!
>>
>>#    void main()
>>#    {
>>#        return;
>>#        printf("hello world\n");
>>#    }
>>    
>>
>
>This is allowed in D (and in C, C++) because it comes in handy when
>debugging code. For example, I may wish in the process of isolating down a
>bug to just 'stub out' a function by putting in a return as the first
>statement. I do this stuff all the time.
>
>I'll also do things like force a particular branch to happen by changing:
>    if (x) { ... } else { ... }
>to:
>    if (1 || x) { ... } else { ... }
>or:
>    if (0 && x) { ... } else { ... }
>
>The optimizer will remove any dead code.
>
>  
>

But we now have nested comments.  Almost defeats that purpose doesn't it?


-- 
-Anderson: http://badmama.com.au/~anderson/
1 2 3
Next ›   Last »