"Pavel Minayev" <evilone@omen.ru> wrote in message news:ad01lm$275t$1@digitaldaemon.com...
> But yes, I know how to use the good ol' EDLIN DOS command... It was pretty useful to type in BAT-files with infinite loops to drive teachers crazy, when we studied MS-DOS in school. That were great days! =)

Edlin is just a sorry clone of a Real Editor (tm), known as TECO.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:ad2uc0$sn8$1@digitaldaemon.com...
> "Martin M. Pedersen" <mmp@www.moeller-pedersen.dk> wrote in message news:ad2rch$pj3$1@digitaldaemon.com...
>
> I wouldn't. As long as it differences from my concept significantly (and seen myself being outnumbered here, I guess I would), I would not follow them anyhow. Why pay such a price? What for? I understand why a single coding standard is needed in a team, but why do the same for the entire community?
>

I'd have to disagree with you on this part. You said (I can't find the source) that at least provide people with an option.  Providing it in the styles guide, gives you a set of rule but doesn't enforce it. You can take the styles guide and use it as a template (extend if you will) to allow for your own preferences. That's what the styles guide for. I'm sure there's other areas in the styles guide that people ignore or change.

Perhaps the styles guide should be treaded a class and bracketing should be
made virtual static (static for the overall community) instead of static ;)
But as D doesn't allow for static virtual members (I think). Also all
members would default to virtual which may not be a good idea.
What you want is explicitly virtual (=0) which I disagree with.

But I agree that coming to a consensus may be extremely difficult, but I don't mind if the styles guide say's use brackets pedantically. Because I'll just extend the community and change that rule.


--------------------------

Changing the subject slightly(perhaps I should new post)

The styles guide should help prevent people making stupid mistakes and leave it to the advanced programmers who know when rules should be broken.

For example...
The other day an lowly experienced programmer did this

int count; //global

...
void a()
{
    for (count=0; count<width; count++) x();
}

...because he was tired of using int, and you can imagine what happened next.

He did something like..
void b()
{
    for (count=0; count<width2; count++) a();
}

Which either caused a recursive loop or skipped a whole bunch of count's.


I realise that I default make all "for" loops use local values for that purpose.

I tried to explain this to him but when he eventually understood, we change the affected functions over, and all ran correctly. Later he tried to convert these back to the previous "count" which ment that he was unwittingly following a style.

So Walter (if yar listening) I'd suggest putting something in the styles
guide like,

"All variables should be local as much as possible." (which is a general
programming rule anyway)
or
"All variables directly related to loops should be local" (but I like the
former and perhaps the for loop could be and example.

Of coarse there are times when the above needs to be broken.

The idea of a styles guide is useful,  though I would recommend creating the styles guide for a different purpose.

Instead of having a styles guide for general programming in D, which may have the effect of slowing down the uptake of D (due to the guide conflicting with company style guides), we use the guide for submitting new modules in the standard D library.  Having a library written in a consistant style is always a bonus for a language.

C 2002/5/31

"C.R.Chafer" <blackmarlin@nospam.asean-mail.com> wrote in message news:ad7vlh$2ise$1@digitaldaemon.com...
> The idea of a styles guide is useful,  though I would recommend creating
> the styles guide for a different purpose.
> Instead of having a styles guide for general programming in D, which may
> have the effect of slowing down the uptake of D (due to the guide
> conflicting with company style guides), we use the guide for submitting
new
> modules in the standard D library.  Having a library written in a consistant style is always a bonus for a language.

Having Phobos written in a consistent style is a good thing. Whether people want to follow that style or not with their own projects is entirely up to them. The D style guide is for the library, and is for people who are casting about looking for a style to use as a starting point. For people/companies who have long ago settled on a particular style, there's no reason for them to change.

Use a 16 entry lookup table, indexed by flag1..4.

"C.R.Chafer" <blackmarlin@nospam.asean-mail.com> wrote in message news:acvt54$2251$1@digitaldaemon.com...
> Roberto Mariottini wrote:
>
> > if (flag1)
> >   if (flag2)
> >       live();
> >   else
> >      if (flag3)
> >         if (flag4)
> >            die();
> >      else
> >         live();
> > else
> >     die();
> >
> > Insert the right braces, and then tell me.
>
> Nice trick screwing up the indentation - almost had me there :-)
>
>         if( flag1 )
>  {      if( flag2 )
>   {     live()                  ;
>   }     else
>   {     if( flag3 )
>    {    if( flag4 )
>     {   die()                   ;
>     }   else
>     {   live()                  ;
>    }}   else
>    {    die()                   ;
>  }}}
>
> lets try a better implementation ...
>
> 1234    flags (1=true)
> 0xxx    nothing
> 100x    die()
> 1010    live()
> 1011    die()
> 11xx    live()
>
> 1&(2|(3&!4))    : live()
> 1&(!2&!(3&!4))  : die()
> ==1&!(2|(3&!4))
>         which is a mirror of live()
>
> hence =>
>
> if( flag1 ) { if( flag2 || ( flag3 && !flag4() ) live(); else die(); }
>
>         ||OR||
>
> if( flag1 ) flag2 || ( flag3 && !flag4() ) ? live(); : die();
>
>
> Which should be just as fast (due to lazy evaluation) and much clearer (or
> have I been doing boolean algebra for too long).
>
> C 2002/5/28

"anderson" <anderson@firestar.com.au> wrote in message news:actk7t$7n6$1@digitaldaemon.com...
> Although D doesn't try to be 100% compatible with c++, it is very simular. I'm sure that was done on purpose.

Yes, it was.

> Taking what was learned from C++ and
> applying/improving it to D is a good thing.

Yes, D is meant to be an evolutionary improvement over C and C++. It is not meant to improve on Pascal, Eiffel, Java, or APL <g>.

> It also reduces the learning
> curve and helps with reportability.

Right, the idea is that someone used to programming in C and C++ should be able to transfer that knowledge to using D with a minimum of gotchas.

Yes but they have to give up a lot of power if coming to D from C++.  It should be a clear upgrade from C;  I know of nothing but improvements over the C language.  But C++ is also much nicer than C.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:ad9npg$1f47$1@digitaldaemon.com...
>
> "anderson" <anderson@firestar.com.au> wrote in message news:actk7t$7n6$1@digitaldaemon.com...
> > Although D doesn't try to be 100% compatible with c++, it is very
simular.
> > I'm sure that was done on purpose.
>
> Yes, it was.
>
> > Taking what was learned from C++ and
> > applying/improving it to D is a good thing.
>
> Yes, D is meant to be an evolutionary improvement over C and C++. It is
not
> meant to improve on Pascal, Eiffel, Java, or APL <g>.
>
> > It also reduces the learning
> > curve and helps with reportability.
>
> Right, the idea is that someone used to programming in C and C++ should be able to transfer that knowledge to using D with a minimum of gotchas.

I got one right for once! That's one up from -49 to -48. ;)

"Walter" <walter@digitalmars.com> wrote in message news:ad9npg$1f47$1@digitaldaemon.com...
>
> "anderson" <anderson@firestar.com.au> wrote in message news:actk7t$7n6$1@digitaldaemon.com...
> > Although D doesn't try to be 100% compatible with c++, it is very
simular.
> > I'm sure that was done on purpose.
>
> Yes, it was.
>
> > Taking what was learned from C++ and
> > applying/improving it to D is a good thing.
>
> Yes, D is meant to be an evolutionary improvement over C and C++. It is
not
> meant to improve on Pascal, Eiffel, Java, or APL <g>.
>
> > It also reduces the learning
> > curve and helps with reportability.
>
> Right, the idea is that someone used to programming in C and C++ should be able to transfer that knowledge to using D with a minimum of gotchas.
>
>