www.digitalmars.com         C & C++   DMDScript  

D - real destructors

reply "Sandor Hojtsy" <hojtsy index.hu> writes:
You no longer need to manually release dynamically allocated memory. So no
destructors anymore? Wrong! You have to release thousand other types of
phisical and logical resources. This is considered very rare and
unimportant. I would rather say it has a moderate chance and has the same
priority than releasing memory. That is: essential and inevitable. You
should not accept workarounds here.

I think having real and deterministic destructors does not conflict with the
garbage collection concept. I propose the following solution:

The destructor should be called when an object is ready for garbage
collection (ref. count is 0), not when it is actually collected. In this
case you can release any resources in the destructor.

What use is a destructor called anywhere else? Any example for a useful
destructor with the current garbage collection concept?

You could say this will be slow. Well only a few of the objects need
destuction anyway.

Let's consider this code. It is beyond awful:

int fn()
{
  my_type1  my_obj1 = new my_obj1;
  my_type2  my_obj2 = new my_obj2;
  my_type3  my_obj3 = new my_obj3;
  try {
    try {
     try {
       whatever();
     } finally { my_obj3.close(); }
    } finally { my_obj2.release(); }
  } finally { my_obj1.destroy(); }
}

Ideas?

Sandor Hojtsy
May 15 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Sandor Hojtsy" <hojtsy index.hu> wrote in message
news:abttuj$1ak$1 digitaldaemon.com...


 The destructor should be called when an object is ready for garbage
 collection (ref. count is 0), not when it is actually collected. In this
 case you can release any resources in the destructor.


D garbage collector is not reference-counting. So, even if you nullify
the reference, it'll take time for garbage collector to make a cycle
and detect the null pointer.


 What use is a destructor called anywhere else? Any example for a useful
 destructor with the current garbage collection concept?


Yes. I use destructors in my WinD project. Since GC is run at least once,
at the end of the program, you can be sure that all non-closed windows
will be closed, all DCs, brushes and pens freed, etc.

By the way, the same applies to files. If you forget to close() the
File, it will be closed from the destructor, as soon as GC will run.


 Let's consider this code. It is beyond awful:

 int fn()
 {
   my_type1  my_obj1 = new my_obj1;
   my_type2  my_obj2 = new my_obj2;
   my_type3  my_obj3 = new my_obj3;
   try {
     try {
      try {
        whatever();
      } finally { my_obj3.close(); }
     } finally { my_obj2.release(); }
   } finally { my_obj1.destroy(); }
 }

 Ideas?


Yep. Rewrite it as:

    try try try
    {
        whatever()
    }
    finally my_obj3.close();
    finally my_obj2.release();
    finally my_obj1.destroy();

=)
May 15 2002
next sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Pavel Minayev wrote:


 What use is a destructor called anywhere else? Any example for a useful
 destructor with the current garbage collection concept?


 Yes. I use destructors in my WinD project. Since GC is run at least once,
 at the end of the program, you can be sure that all non-closed windows
 will be closed, all DCs, brushes and pens freed, etc.

 By the way, the same applies to files. If you forget to close() the
 File, it will be closed from the destructor, as soon as GC will run.


You still have the potential for (temporary) memory leaks, even if they are
cleaned up eventually.  In Windows, you could get a LOT of allocated objects
very quickly if the GC didn't get around to running soon enough.

It would be very useful for the OS to be able to send a message/signal to the
program when memory ran low, asking it to run the GC.  In such an
architecture, you wouldn't even need to schedule a regular GC run...whenever
the OS detected a low memory condition, every program would get a "GC signal",
and the various GC's would release whatever memory they were holding on to
that wasn't needed.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
May 15 2002
next sibling parent "OddesE" <OddesE_XYZ hotmail.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3CE29345.44CEF1D7 deming-os.org...

 Pavel Minayev wrote:


 What use is a destructor called anywhere else? Any example for a






useful

 destructor with the current garbage collection concept?


 Yes. I use destructors in my WinD project. Since GC is run at least




once,

 at the end of the program, you can be sure that all non-closed windows
 will be closed, all DCs, brushes and pens freed, etc.

 By the way, the same applies to files. If you forget to close() the
 File, it will be closed from the destructor, as soon as GC will run.


 You still have the potential for (temporary) memory leaks, even if they


are

 cleaned up eventually.  In Windows, you could get a LOT of allocated


objects

 very quickly if the GC didn't get around to running soon enough.

 It would be very useful for the OS to be able to send a message/signal to


the

 program when memory ran low, asking it to run the GC.  In such an
 architecture, you wouldn't even need to schedule a regular GC


run...whenever

 the OS detected a low memory condition, every program would get a "GC


signal",

 and the various GC's would release whatever memory they were holding on to
 that wasn't needed.

 --
 The Villagers are Online! villagersonline.com

 .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
 .[ (a version.of(English).(precise.more)) is(possible) ]
 ?[ you want.to(help(develop(it))) ]



Or better yet, make the OS able of doing garbage collection!

--
Stijn
OddesE_XYZ hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail
May 15 2002
prev sibling next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3CE29345.44CEF1D7 deming-os.org...


 You still have the potential for (temporary) memory leaks, even if they


are

 cleaned up eventually.  In Windows, you could get a LOT of allocated


objects

 very quickly if the GC didn't get around to running soon enough.


Yes, you are right. Nothing I can do much with, though - window handles
are released when windows are closed, and DCs are deleted, but pens
and brushes might be used somewhere else, and thus can't be disposed
that easy.
May 15 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3CE29345.44CEF1D7 deming-os.org...

 You still have the potential for (temporary) memory leaks, even if they


are

 cleaned up eventually.  In Windows, you could get a LOT of allocated


objects

 very quickly if the GC didn't get around to running soon enough.


It's not that bad. Just use:

    f = new Foo();
    f.acquire_resource();
    f.operations();
    f.release_resource();

In the normal case, your resources get released. Only when an exception
occurs does the release_resource() get skipped, but it still gets run some
time later when the GC runs (if Foo is written right). If that isn't enough,
just use try-finally.


 It would be very useful for the OS to be able to send a message/signal to


the

 program when memory ran low, asking it to run the GC.  In such an
 architecture, you wouldn't even need to schedule a regular GC


run...whenever

 the OS detected a low memory condition, every program would get a "GC


signal",

 and the various GC's would release whatever memory they were holding on to
 that wasn't needed.


Just execute:

    gc.fullCollect();
May 15 2002
next sibling parent "Matthew Wilson" <mwilson nextgengaming.com> writes:
I have to say I strongly disagree with this strong coupling of object
destruction/finalisation with memory garbage collection.

It is this very model that is one of the three big criticisms of Java, along
with lack of out parameters (big thanks for putting that in D, Walter) and
lack of const. Java could also do with templates, but one can forgive them
for avoiding the difficulties in that case.

One of my friends is a major a Java guru, having worked in the inner circle
at Sun for a long time, and he poo-poos my criticism of Java's denial of the
so-useful-we-don't-even-think-about-it-any-more "resource acquisition is
initialisation" idiom, and its built-in support in C++. However, it seems to
me to be the most basic (fundamental, as well as easily understood) tenet of
object-orientation that an object clears up after itself.

I have heard many times, from Java proponents, that finalisation eventuates
and so resource cleanup is carried out, but isn't this like a naughty child
who will clean up his room "later". The analogy is not as purile as it may
seem, since in order to get, say, a .NET file stream to clear up after
itself before disappearing out of scope, we have to call Close(), rather
like making your child do the room tidy before going out for the evening.
Seriously, if a file is locked and preventing another thread/process from
accessing it, then this is a bug in any practical sense, despite the
original locker begin guaranteed to unlock it sometime later.

The answere in Java & .NET is to pepper one's code with try/finally blocks.
Wasn't part of the reason for the introduction of exception handling to
reduce error-handling clutter obfuscating that actual task-specific code?
Even the use of a using/scope block to enforce dtor/finalise call at the end
of the scope is adding code.

Another criticism from Java/.NET proponents is that this is forcing an idiom
on a lot of code that does not need/want it. This is not the case, since one
could quite easily omit a definition of Finalise/~dtor, and presumably the
runtime system can take advantage of this omission for the purposes of its
internal efficiencies, only calling the destructor when explicitly there (or
in a superordinate class). If we get them off the soap-box for a mo,
however, we surely have to ask what is the point of defining a function that
_may_ get called at some time in the future, or just as well may not?

We witness some acknowledgement of this horrible omission in Java in the

their Dispose idiom: an utter load of nonsense.

If one doesn't need destruction, don't define a destructor. If one needs
(deterministic) destruction, let's have it. If one wants non-deterministic
destruction, I have to ask: what are you asking for? why do you want it?
Hopefully someone can enlighten me.

I hope that D can avoid this coupling, and continue with what seems in all
other regards to be a superb idea.

Matthew

"Walter" <walter digitalmars.com> wrote in message
news:<abunoi$o4u$1 digitaldaemon.com>...

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3CE29345.44CEF1D7 deming-os.org...

 You still have the potential for (temporary) memory leaks, even if they


 are

 cleaned up eventually. In Windows, you could get a LOT of allocated


 objects

 very quickly if the GC didn't get around to running soon enough.


 It's not that bad. Just use:

 f = new Foo();
 f.acquire_resource();
 f.operations();
 f.release_resource();

 In the normal case, your resources get released. Only when an exception
 occurs does the release_resource() get skipped, but it still gets run some
 time later when the GC runs (if Foo is written right). If that isn't


enough,

 just use try-finally.


 It would be very useful for the OS to be able to send a message/signal




to

 the

 program when memory ran low, asking it to run the GC. In such an
 architecture, you wouldn't even need to schedule a regular GC


 run...whenever

 the OS detected a low memory condition, every program would get a "GC


 signal",

 and the various GC's would release whatever memory they were holding on




to

 that wasn't needed.


 Just execute:

 gc.fullCollect();


"Walter" <walter digitalmars.com> wrote in message
news:abunoi$o4u$1 digitaldaemon.com...

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3CE29345.44CEF1D7 deming-os.org...

 You still have the potential for (temporary) memory leaks, even if they


 are

 cleaned up eventually.  In Windows, you could get a LOT of allocated


 objects

 very quickly if the GC didn't get around to running soon enough.


 It's not that bad. Just use:

     f = new Foo();
     f.acquire_resource();
     f.operations();
     f.release_resource();

 In the normal case, your resources get released. Only when an exception
 occurs does the release_resource() get skipped, but it still gets run some
 time later when the GC runs (if Foo is written right). If that isn't


enough,

 just use try-finally.


 It would be very useful for the OS to be able to send a message/signal




to

 the

 program when memory ran low, asking it to run the GC.  In such an
 architecture, you wouldn't even need to schedule a regular GC


 run...whenever

 the OS detected a low memory condition, every program would get a "GC


 signal",

 and the various GC's would release whatever memory they were holding on




to

 that wasn't needed.


 Just execute:

     gc.fullCollect();
May 15 2002
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:


 It would be very useful for the OS to be able to send a message/signal to


 the

 program when memory ran low, asking it to run the GC.  In such an
 architecture, you wouldn't even need to schedule a regular GC


 run...whenever

 the OS detected a low memory condition, every program would get a "GC


 signal",

 and the various GC's would release whatever memory they were holding on to
 that wasn't needed.


 Just execute:

     gc.fullCollect();


I would also like to be able to register objects with the GC such that when
fullCollect() is called, these objects get callbacks (before garbage collection
runs).  The callback would allow the object to release any memory that it is
holding but is not critical.

For instance, when I allocate & deallocate hundreds of little objects, I like to
use a "pool class," which, in C++, is like this:

    template <class X> class Pool
    {
    protected:
        X *array;  // dynamically sized

    public:
        X *Get()
        {
            if(array_is_empty)
                return new Pool;
            else
                return remove_first_element_from_array;
        }
        void Put(X *ptr)
        {
            add_ptr_to_array;
        }
        void Flush(int count=0)
        {
            while(count_in_array > count)
                delete remove_first_element_from_array;
            reallocate_array_to_size_count
        }
}



When gc.fullCollect() is called, I would like the garbage collector to call
Flush(0) on all of my registered pool objects.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
May 16 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3CE3AD39.BBC8F78A deming-os.org...


 When gc.fullCollect() is called, I would like the garbage collector to


call

 Flush(0) on all of my registered pool objects.


This is usually called a "destructor". =)
Don't forget, destructors are always called when objects get destroyed,
be it a delete operator or a GC cycle.

By the way, there are no default values for function arguments in D.
May 16 2002
parent Keith Ray <k1e2i3t4h5r6a7y 1m2a3c4.5c6o7m> writes:
In article <ac0dfr$26p6$1 digitaldaemon.com>,
 "Pavel Minayev" <evilone omen.ru> wrote:


 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3CE3AD39.BBC8F78A deming-os.org...
 

 When gc.fullCollect() is called, I would like the garbage collector to


 call

 Flush(0) on all of my registered pool objects.


 
 This is usually called a "destructor". =)
 Don't forget, destructors are always called when objects get destroyed,
 be it a delete operator or a GC cycle.


In garbage-collected languages other than D, this is usually known as a 
"finalizer", though sometimes the thread that calls the finalize method 
is called the finalizer.

<http://www.google.com/search?hl=en&q=garbage+collector+finalizer&btnG=Go
ogle+Search>
-- 
C. Keith Ray

<http://homepage.mac.com/keithray/xpminifaq.html>
May 20 2002
prev sibling next sibling parent Patrick Down <pat codemoon.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in news:abu1gg$47v$1
 digitaldaemon.com:


 
 Yep. Rewrite it as:
 
     try try try
     {
         whatever()
     }
     finally my_obj3.close();
     finally my_obj2.release();
     finally my_obj1.destroy();
 


What might be a nice piece of syntactic sugar
that would be something like this.

try(File f("data.dat"),Foo b(12))
{
  f.read(...)// blah blah
}

which would be rewriten as:

try
{
  f = new File("data.dat");
  b = new Foo(12);

  f.read(...)//blah blah
}
finally
{
  delete b;
  delete f;
}


This deals with stack lifetime issues.

For object lifetime issues maybe a new keyword
"owned"

class Foo
{
  owned File f;
}

When Foo is deleted or collected the finalizer
goes through all the objects "owned" pointers and
deletes them.
May 15 2002
prev sibling parent reply "Sandor Hojtsy" <hojtsy index.hu> writes:
 int fn()
 {
   my_type1  my_obj1 = new my_obj1;
   my_type2  my_obj2 = new my_obj2;
   my_type3  my_obj3 = new my_obj3;
   try {
     try {
      try {
        whatever();
      } finally { my_obj3.close(); }
     } finally { my_obj2.release(); }
   } finally { my_obj1.destroy(); }
 }

 Ideas?


 Yep. Rewrite it as:

     try try try
     {
         whatever()
     }
     finally my_obj3.close();
     finally my_obj2.release();
     finally my_obj1.destroy();


I was interested if anyone will notice that correctly this is written as:

int fn()
{
   my_type1  my_obj1 = new my_obj1;
   try {
     my_type2  my_obj2 = new my_obj2;
     try {
       my_type3  my_obj3 = new my_obj3;
       try {
         whatever();
      } finally my_obj3.close();
    } finally my_obj2.release();
  } finally my_obj1.destroy();
}

I consider that noone has noticed this,
a sign of lack of understandability, and of difficult debugging.
I cannot think of any syntactic sugar that could help here.
It needs more fundamental changes.

Yours,
Sandor Hojtsy
May 16 2002
parent reply "anderson" <anderson firestar.com.au> writes:
syntactic sugar

Try could act simular to an "if" statement, where "{" can be left if one
statement follows.

ie
int fn()
{
    my_type1  my_obj1 = new my_obj1;

    try my_type2  my_obj2 = new my_obj2;

        try my_type3 my_obj3 = new my_obj3;

            try whatever();
            finally my_obj3.close();

        finally my_obj2.release();

   finally my_obj1.destroy();
}

//If that looks any neater? I don't know, parhaps my layout style could be
improved.

PS - I hope my tabed layout is not wrecked by the news writter.


"Sandor Hojtsy" <hojtsy index.hu> wrote in message
news:abvl54$1fd8$1 digitaldaemon.com...

 I was interested if anyone will notice that correctly this is written as:

 int fn()
 {
    my_type1  my_obj1 = new my_obj1;
    try {
      my_type2  my_obj2 = new my_obj2;
      try {
        my_type3  my_obj3 = new my_obj3;
        try {
          whatever();
       } finally my_obj3.close();
     } finally my_obj2.release();
   } finally my_obj1.destroy();
 }

 I consider that noone has noticed this,
 a sign of lack of understandability, and of difficult debugging.
 I cannot think of any syntactic sugar that could help here.
 It needs more fundamental changes.

 Yours,
 Sandor Hojtsy
May 24 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"anderson" <anderson firestar.com.au> wrote in message
news:acl30i$2sht$1 digitaldaemon.com...


 syntactic sugar

 Try could act simular to an "if" statement, where "{" can be left if one
 statement follows.


It does. There's no such stupidity as in C++, which requires { } around
try-block.
May 24 2002
parent "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
Hi,

"Pavel Minayev" <evilone omen.ru> wrote in message
news:acl7qf$4mq$1 digitaldaemon.com...


 Try could act simular to an "if" statement, where "{" can be left if one
 statement follows.


 It does. There's no such stupidity as in C++, which requires { } around
 try-block.


It is specified that it is required, see:
http://www.digitalmars.com/d/statement.html#try
So, if it works for you without them, either the specification or the
implementation is flawed.

Regards,
Martin M. Pedersen
May 24 2002
prev sibling parent reply "Roberto Mariottini" <rmariottini lycosmail.com> writes:
"anderson" <anderson firestar.com.au> ha scritto nel messaggio
news:acl30i$2sht$1 digitaldaemon.com...
[...]

 int fn()
 {
     my_type1  my_obj1 = new my_obj1;

     try my_type2  my_obj2 = new my_obj2;

         try my_type3 my_obj3 = new my_obj3;

             try whatever();
             finally my_obj3.close();

         finally my_obj2.release();

    finally my_obj1.destroy();
 }


[...]

I hate this...
I vote for mandatory brackets.

Ciao
May 24 2002
next sibling parent reply C.R.Chafer <blackmarlin nospam.asean-mail.com> writes:
Roberto Mariottini wrote:


 "anderson" <anderson firestar.com.au> ha scritto nel messaggio
 news:acl30i$2sht$1 digitaldaemon.com...
 [...]

 int fn()
 {
     my_type1  my_obj1 = new my_obj1;

     try my_type2  my_obj2 = new my_obj2;

         try my_type3 my_obj3 = new my_obj3;

             try whatever();
             finally my_obj3.close();

         finally my_obj2.release();

    finally my_obj1.destroy();
 }


 [...]
 
 I hate this...
 I vote for mandatory brackets.


I disagree - the language should be internally consistant,  therefore 
anywhere where block statements are permissable it should be possible 
should be possible to be replace them with a singe statement - even if the 
result is less than perfect,  as in this case.

C 2002/5/24
May 24 2002
next sibling parent reply "Roberto Mariottini" <rmariottini lycosmail.com> writes:
"C.R.Chafer" <blackmarlin nospam.asean-mail.com> wrote in message
news:aclb1b$8rh$1 digitaldaemon.com...

 I disagree - the language should be internally consistant,  therefore
 anywhere where block statements are permissable it should be possible
 should be possible to be replace them with a singe statement - even if the
 result is less than perfect,  as in this case.


Sure, then we can apply it to functions:

int func(int x, int y, int z) return x+2*y+3*z*x;
void func2(int x, int *y) *y = func(x, x+*y, x-*y);

Or to switch:

switch(number)    case 1:    return 0;

Good. And what about structs:

struct Astruct
   int i;

Beautiful. :-(
I vote for mandatory brackets everywhere (so the language would be
internally consistant).

Ciao.
May 24 2002
next sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
I'm for this.  The IDE could auto insert braces.

Sean

"Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
news:aclmhe$jit$1 digitaldaemon.com...

 "C.R.Chafer" <blackmarlin nospam.asean-mail.com> wrote in message
 news:aclb1b$8rh$1 digitaldaemon.com...

 I disagree - the language should be internally consistant,  therefore
 anywhere where block statements are permissable it should be possible
 should be possible to be replace them with a singe statement - even if




the

 result is less than perfect,  as in this case.


 Sure, then we can apply it to functions:

 int func(int x, int y, int z) return x+2*y+3*z*x;
 void func2(int x, int *y) *y = func(x, x+*y, x-*y);

 Or to switch:

 switch(number)    case 1:    return 0;

 Good. And what about structs:

 struct Astruct
    int i;

 Beautiful. :-(
 I vote for mandatory brackets everywhere (so the language would be
 internally consistant).

 Ciao.
May 24 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:aclt0n$pm0$1 digitaldaemon.com...


 I'm for this.  The IDE could auto insert braces.


The Only True IDE Is Command Line! (tm)

I just HATE code with unnecessary braces. I understand why you
want 'em. But let me write MY code in a way I want to see it.
May 24 2002
parent reply "Roberto Mariottini" <rmariottini lycosmail.com> writes:
"Pavel Minayev" <evilone omen.ru> ha scritto nel messaggio
news:acm17i$tao$1 digitaldaemon.com...

 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:aclt0n$pm0$1 digitaldaemon.com...


 I'm for this.  The IDE could auto insert braces.


 The Only True IDE Is Command Line! (tm)


So are you woking with a line-editor?
I love line editors, but only used with a teletype.


 I just HATE code with unnecessary braces. I understand why you
 want 'em. But let me write MY code in a way I want to see it.


I disagree on the term 'unnecessary'. Most modern languages have many
things that are 'unnecessary', 'features' that old languages missed.
Time tells that many things, once considered unnecessary, are required
to make the program clearer ad more robust.
BASIC considered variable declaration unnecessary. Function
prototypes were considered unnecessary by the original C authors.
C++ got rid of many things, but laks many others (that Java andD add
to it, for example).

The python language author chose to make indentation part of the
language. While some people objected (there is always some), the
vast majority of pyhton programmers adopted the new style.
What python want is something impossible with other languages:
good indentation of programs.
But in my opinion "good indentation" is not the real problem,
"good readability" is the real one.
When you get a more-than-a-million-lines-of-code C project
written by others without following a coding standard (this is not
uncommon in my experience) to work on, you'll understand that
your work would be beautiful if only you won't have to deal with
something like this:

   if (a < b)
   if (c <d)
   if (e < f)
      a = b;
   else a = c;
   else break;

   if (a<b && c()<d || e<f() && h()<g() && j<k || l()<m())
        ...

I often find bugs introduced by co-workers that misunderstood the
flow of the original code when trying to modify it. I think the company
I work for is loosing money everyday for stupid things like this.
I bet the tab-configuration of most IDE and editors is making
loose millions of dollars per year to software houses all over the
world.

I think this is _important_, not 'unnecessary'.

Ciao
May 28 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
news:acvhbk$1cgn$1 digitaldaemon.com...


 The Only True IDE Is Command Line! (tm)


 So are you woking with a line-editor?
 I love line editors, but only used with a teletype.


I should have said "console mode".
Yes, I type 99% of my programs in text-mode (full screen only) editors.
I use FAR + Colorer under Win32, and Midnight Commander's builtin
editor in QNX (my two development platforms).

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! =)


 I disagree on the term 'unnecessary'. Most modern languages have many
 things that are 'unnecessary', 'features' that old languages missed.
 Time tells that many things, once considered unnecessary, are required
 to make the program clearer ad more robust.


When I say "unnecessary", I mean that code is absolutely clear, easy
to read, and will correctly compile without those braces. The definition
of "clear" and "easy to read" code is left up to the coder, in this
case it's me. =) I do insert braces sometimes even though the compiler
doesn't need them, for example, in case-blocks, and in some complex
nested if-statements. I just don't insert them _everywhere_. In my
opinion, it just makes the code more beautiful.
May 28 2002
parent "Walter" <walter digitalmars.com> writes:
"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.
May 30 2002
prev sibling next sibling parent reply C.R.Chafer <blackmarlin nospam.asean-mail.com> writes:
 I vote for mandatory brackets everywhere (so the language would be
 internally consistant).


Had I designed the language that would have been the case,  however the 
language was designed to be like C - and therefore the block / statement 
rule - special cases are bad and lead to gotchas in the language,  D so far 
seems to be good at avoiding these so why should the try .. finally be 
different from the if .. else statement?  After all you are not required to 
omit the braces.

As for your example with the switch statement,  you use two statements and 
therefore require a block,  but for the function definitions I see no 
reason why that syntax should be invalid (and writing it this way should 
simplify that implementation of the parser).

C 2002/5/24
May 25 2002
parent reply Keith Ray <k1e2i3t4h5r6a7y 1m2a3c4.5c6o7m> writes:
In article <aclulo$r5i$1 digitaldaemon.com>,
 C.R.Chafer <blackmarlin nospam.asean-mail.com> wrote:


 I vote for mandatory brackets everywhere (so the language would be
 internally consistant).


 
 Had I designed the language that would have been the case,  however the 
 language was designed to be like C - and therefore the block / statement 
 rule - special cases are bad and lead to gotchas in the language,  D so far 
 seems to be good at avoiding these so why should the try .. finally be 
 different from the if .. else statement?  After all you are not required to 
 omit the braces.


C doesn't have try...finally so language compatibility isn't an issue.
-- 
C. Keith Ray

<http://homepage.mac.com/keithray/xpminifaq.html>
May 26 2002
next sibling parent C.R.Chafer <blackmarlin nospam.asean-mail.com> writes:
Keith Ray wrote:


 In article <aclulo$r5i$1 digitaldaemon.com>,
  C.R.Chafer <blackmarlin nospam.asean-mail.com> wrote:
 

 I vote for mandatory brackets everywhere (so the language would be
 internally consistant).


 
 Had I designed the language that would have been the case,  however the
 language was designed to be like C - and therefore the block / statement
 rule - special cases are bad and lead to gotchas in the language,  D so
 far seems to be good at avoiding these so why should the try .. finally
 be
 different from the if .. else statement?  After all you are not required
 to omit the braces.


 
 C doesn't have try...finally so language compatibility isn't an issue.


Compatability is an issue in the remainder of the language (id est - if .. 
else, for, while, etcetra) and to ease new users into the language it 
should be internally consistant (so that if a particular format works with 
one type of statement it should work with any applicable similar 
statements).  By the reasoning I concude try .. finally should have a 
similar syntax to if .. else.

C 2002/5/27
May 27 2002
prev sibling next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Keith Ray" <k1e2i3t4h5r6a7y 1m2a3c4.5c6o7m> wrote in message
news:k1e2i3t4h5r6a7y-1983E2.21242926052002 digitalmars.com...


 C doesn't have try...finally so language compatibility isn't an issue.


But C++ does have try..catch, which was NOT consistent to the other
parts of the language. I'm glad to see D not going this track...
May 27 2002
prev sibling parent reply "anderson" <anderson firestar.com.au> writes:
Although D doesn't try to be 100% compatible with c++, it is very simular.
I'm sure that was done on purpose. Taking what was learned from C++ and
applying/improving it to D is a good thing. It also reduces the learning
curve and helps with reportability.


--
If apples and oranges both tasted like water, which would you pick? (I'd
have both)


"Keith Ray" <k1e2i3t4h5r6a7y 1m2a3c4.5c6o7m> wrote in message
news:k1e2i3t4h5r6a7y-1983E2.21242926052002 digitalmars.com...

 In article <aclulo$r5i$1 digitaldaemon.com>,
  C.R.Chafer <blackmarlin nospam.asean-mail.com> wrote:


 I vote for mandatory brackets everywhere (so the language would be
 internally consistant).


 Had I designed the language that would have been the case,  however the
 language was designed to be like C - and therefore the block / statement
 rule - special cases are bad and lead to gotchas in the language,  D so




far

 seems to be good at avoiding these so why should the try .. finally be
 different from the if .. else statement?  After all you are not required




to

 omit the braces.


 C doesn't have try...finally so language compatibility isn't an issue.
 --
 C. Keith Ray

 <http://homepage.mac.com/keithray/xpminifaq.html>
May 27 2002
parent reply "Walter" <walter digitalmars.com> writes:
"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.
May 31 2002
next sibling parent "Sean L. Palmer" <seanpalmer earthlink.net> writes:
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.
Jun 01 2002
prev sibling parent "anderson" <anderson firestar.com.au> writes:
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.
Jun 01 2002
prev sibling next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
news:aclmhe$jit$1 digitaldaemon.com...


 Sure, then we can apply it to functions:

 int func(int x, int y, int z) return x+2*y+3*z*x;
 void func2(int x, int *y) *y = func(x, x+*y, x-*y);


Yes, why not? It would be a useful feature for property gettors & settors:

    void width(int w) width = w;
    int width() return width;

Unfortunately, it cannot be done, due to the ambiguity between forward
declaration and empty statement:

    void width();    // does it have a body consisting only of ;, or is it a
declaration?

So we _have_ to use braces here, to disambiguate.

Try-catch, on other hand, does not cause ambiguity.


 Or to switch:

 switch(number)    case 1:    return 0;


There needs to be some way for the compiler to find end of switch
block. In your example, it does not know where the case ends.
So, braces are required here.


 Good. And what about structs:

 struct Astruct
    int i;


Again, why not? There is no ambiguity here, so I guess the compiler could
treat struct declarations that way.

But even here, there's a difference. struct is a _declaration_, it's
not a statement. if-else is a statement and is defined as:

    if (<condition>) <statement> else <statement>

Where "statement" is ANY statement. Since complex statement { } is just
a way to group together simple statements, it suites as well. It has
nothing to do with struct.


 Beautiful. :-(


Maybe not for you.


 I vote for mandatory brackets everywhere (so the language would be
 internally consistant).


I vote for NO mandatory brackets everywhere it can be allowed (and
maybe where it makes sence, since struct or class consisting of
one member is not something you're gonna use more than once a year =)):
that is, everywhere except for functions, switch, struct, class
and enum. In other words, I vote for what is in DMD today.

I don't really understand "consistency" here - why would anybody care
why braces around struct are required, not so for if blocks...
I care more about line count:

    if (flag)
        live();
    else
        die();

Short AND clear, as long as you indent everything properly. Why waste
4 more lines?

    if (flag)
    {
        live();
    }
    else
    {
        die();
    }

I don't understand... is it ANY better, clearer, easier to read than
the first version?
May 24 2002
next sibling parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:acm1t1$tuu$1 digitaldaemon.com...

 Unfortunately, it cannot be done, due to the ambiguity between forward
 declaration and empty statement:

     void width();    // does it have a body consisting only of ;, or is it


a

 declaration?


There would be no such conflict; see:
http://www.digitalmars.com/d/statement.html#empty

Anyway, I vote for braces.


 I don't really understand "consistency" here - why would anybody care
 why braces around struct are required, not so for if blocks...
 I care more about line count:

     if (flag)
         live();
     else
         die();

 Short AND clear, as long as you indent everything properly. Why waste
 4 more lines?


Nothing is wasted by a few more lines. In the old days, I never wrote a
function more that 24 lines long because it didn't fit the screen. Likewise,
lines was rarely longer than 80 character. Back then, the number of lines
was valuable. Now, I adjust the window size to suit my needs.

Indenting is in my experience not to be relied to heavily on. I have seen it

others, such as carelessness). Different people use tools with different tab
sizes, and sometimes they become silently expanded, thereby causing havoc
for indenting. And when it happens, it probably does not even show because
it still compiles fine. So it lives on and the source is maintained. It is
changed from that point on, changed again and again, elsewhere in the file,
without anyone noticing. Some day, somebody is going to maintain the code
where the indeting was damaged many revisions ago. There, the trouble
begins.


     {
         die();
     }

 I don't understand... is it ANY better, clearer, easier to read than
 the first version?


It is easier and safer to maintain. And if used consistently, yes, it is
also easier to read.


Regards,
Martin M. Pedersen
May 24 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:acm5gq$116p$1 digitaldaemon.com...


 Nothing is wasted by a few more lines. In the old days, I never wrote a


Nor anything is given. So why would you want something that just
takes place and doesn't give anything?..


 Indenting is in my experience not to be relied to heavily on. I have seen


it




are

 others, such as carelessness). Different people use tools with different


tab

 sizes, and sometimes they become silently expanded, thereby causing havoc
 for indenting. And when it happens, it probably does not even show because
 it still compiles fine. So it lives on and the source is maintained. It is
 changed from that point on, changed again and again, elsewhere in the


file,

 without anyone noticing. Some day, somebody is going to maintain the code
 where the indeting was damaged many revisions ago. There, the trouble
 begins.


This has nothing to do with braces, though. Unindented code with braces
is just as unreadable as unindented code without. For the examples of
both, take a look at Phobos source - Walter seems to dislike the TAB key...
=)


 It is easier and safer to maintain. And if used consistently, yes, it is


How is it easier to maintain? I agree that you have to add braces whenever
you want to insert another statement into the block, but you do it just
once anyhow - when you type it first or when you see it's really needed.


 also easier to read.


HOW is it easier to read? For you, maybe. But personally, I really hate
unneeded braces.

Once again, it's just a MATTER OF PERSONAL TASTE. It has nothing to do
with consistency, speed, safety, etc etc. It's just what one particular
person considers neater (or easier to read, whichever you prefer). But
even though most people seem to prefer to put braces everywhere, it's NOT
the reason to force other people to code in their style. You wanna code
it that way - NOTHING stops you from doing so. You work in a team - adopt
a standard to be used by all members of that team. Just don't decide
for other people, that might have opinion different from yours. As long as
it doesn't harm, at least. And does it?

Otherwise, I'll ask to forbid spaces used for indentation, and require
tabs to be used for this purpose always. Or maybe I'll claim that lines
should not be longer than 70 characters, and compiler should give an
error if line is any longer... heh! Or how about a mandatory space between
"if" and "(" (so "if (" is legal, while "if(" is not)? We could also
require braces around the return expression: "return (0)" instead of
just "return 0". Why, it's consistency - if/while/for all have braces,
so why not require the same for return? And then for throw? Especially
since assert requires braces...
May 24 2002
next sibling parent reply "Carlos" <carlos8294 msn.com> writes:
 Once again, it's just a MATTER OF PERSONAL TASTE. It has nothing to do
 with consistency, speed, safety, etc etc. It's just what one particular
 person considers neater (or easier to read, whichever you prefer). But
 even though most people seem to prefer to put braces everywhere, it's NOT
 the reason to force other people to code in their style. You wanna code
 it that way - NOTHING stops you from doing so. You work in a team - adopt
 a standard to be used by all members of that team. Just don't decide
 for other people, that might have opinion different from yours. As long as
 it doesn't harm, at least. And does it?


I agree that it's about personal taste. I also don't like braces. I use them
because they're needed, but if there could be another way to do it (like in
Basic, where every block has a starting and ending sentence) I would do it
that way (not like Pascal, because BEGIN and END are even worse than
braces). But there's something about what you've said: braces DO affect
speed. As far as I know, whenever a compiler finds a (, [, {, /*, or
something like that, it has to look for ), ], }, */, or something, so it
makes it slower. I'm not sure if D does the same.


 Otherwise, I'll ask to forbid spaces used for indentation, and require
 tabs to be used for this purpose always. Or maybe I'll claim that lines
 should not be longer than 70 characters, and compiler should give an
 error if line is any longer... heh! Or how about a mandatory space between
 "if" and "(" (so "if (" is legal, while "if(" is not)? We could also
 require braces around the return expression: "return (0)" instead of
 just "return 0". Why, it's consistency - if/while/for all have braces,
 so why not require the same for return? And then for throw? Especially
 since assert requires braces...


About tabs and not spaces, length of lines, etc., it's also about personal
taste. Like you said, you can't decide for other people. And about the space
after if, probably an IDE could do it. But it also depends on the code. For
example,

bit a;
...
if(a) ...;

I think it's clear enough to add a space.
May 24 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"Carlos" <carlos8294 msn.com> wrote in message
news:acmhd7$1cur$1 digitaldaemon.com...


 braces). But there's something about what you've said: braces DO affect
 speed. As far as I know, whenever a compiler finds a (, [, {, /*, or
 something like that, it has to look for ), ], }, */, or something, so it
 makes it slower. I'm not sure if D does the same.


I doubt you will notice the difference even if you compile a 10000-liner
on 80486. =)


 About tabs and not spaces, length of lines, etc., it's also about personal
 taste. Like you said, you can't decide for other people. And about the


space

 after if, probably an IDE could do it. But it also depends on the code.


For

 example,

 bit a;
 ...
 if(a) ...;

 I think it's clear enough to add a space.


Well, I do. That's my style. But I don't force other people to do the same.
That's what I just wanted to say...
May 24 2002
prev sibling parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
Hi,

"Pavel Minayev" <evilone omen.ru> wrote in message
news:acm7f7$130f$1 digitaldaemon.com...

 "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
 news:acm5gq$116p$1 digitaldaemon.com...

 HOW is it easier to read? For you, maybe. But personally, I really hate
 unneeded braces.

 Once again, it's just a MATTER OF PERSONAL TASTE. It has nothing to do
 with consistency, speed, safety, etc etc. It's just what one particular
 person considers neater (or easier to read, whichever you prefer). But
 even though most people seem to prefer to put braces everywhere, it's NOT
 the reason to force other people to code in their style. You wanna code
 it that way - NOTHING stops you from doing so. You work in a team - adopt
 a standard to be used by all members of that team. Just don't decide
 for other people, that might have opinion different from yours. As long as
 it doesn't harm, at least. And does it?


Of cause it is a matter of personal taste. I find it easier to maintain,
mainly because it is easier for me to read. And it is easier to read,
because I have gained the habbit due to style guides we are using. In C, I
will claim that it is also safer, because you don't see errors like this
one:

    if (something);
        conditional_statement;

However, this issue is already addressed by other means in D (by eliminating
";" as the empty statement).

Style guides are valuable within a development group, and I'll claim that
some of the elements normally found in style guides can be moved into the
language for the benefit of us all. The empty statement is a good example of
this, already considered by Walter. Other elements that should definitely
not be moved into the languages are guide lines that needs to be broken,
although rarely, in order to solve specific problems. An example is a line
length limit; if D had a limit on the line length, it would make it
impossible to refer to extremely long external symbols. Also, when
considering making a some style guide part of the language, the complexity
of the language should be considered. Requiring braces does not making the
language any more complex.

I'll prefer consistency over freedom, as long as no freedom is taken away
from me, that I need to solve problems. Because a piece of code is part of
one project today, it does not mean that it is not part of a dozen other
projects tomorrow. And I would like the code in these projects to be
consistent too.

Regards,
Martin M. Pedersen
May 28 2002
next sibling parent "anderson" <anderson firestar.com.au> writes:
I agree,

On another tact, D needs to maintain as much backwards compatibility as
possible. And the more that can be ported to D, the faster it will gain
acceptance. Image porting some program and having to check each if
statement. Simple find replace tools are difficult to use in these
situations.

Style guidelines can be very valuable when working in teams. I've found the
best style guides to be ones with project specific ones with things like,

"All classes must attempt to be state machines"
"One space between closely related (or opposites) and two spaces between
less realated things"
"All properties will be sorted by letter"
or alternatively
"All properties/methods will be sorted by there association, under
categories"
"Categories will be listed as a contents and will be numbered."
"Each Categories will have a discription"
"Methods/Properties in categories will be indented, while ones that haven't
been placed into at cattorgory (yet) will not be."
"All structs/typedef/enums will appear at the top of the program" -Thats
less specific but you get the idea.
(Although some of these could probably be used in all cases)

Because then you know what to expect and where to find things.


"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:ad09eo$2gdj$1 digitaldaemon.com...

 Hi,

 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:acm7f7$130f$1 digitaldaemon.com...

 "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
 news:acm5gq$116p$1 digitaldaemon.com...

 HOW is it easier to read? For you, maybe. But personally, I really hate
 unneeded braces.

 Once again, it's just a MATTER OF PERSONAL TASTE. It has nothing to do
 with consistency, speed, safety, etc etc. It's just what one particular
 person considers neater (or easier to read, whichever you prefer). But
 even though most people seem to prefer to put braces everywhere, it's




NOT

 the reason to force other people to code in their style. You wanna code
 it that way - NOTHING stops you from doing so. You work in a team -




adopt

 a standard to be used by all members of that team. Just don't decide
 for other people, that might have opinion different from yours. As long




as

 it doesn't harm, at least. And does it?


 Of cause it is a matter of personal taste. I find it easier to maintain,
 mainly because it is easier for me to read. And it is easier to read,
 because I have gained the habbit due to style guides we are using. In C, I
 will claim that it is also safer, because you don't see errors like this
 one:

     if (something);
         conditional_statement;

 However, this issue is already addressed by other means in D (by


eliminating

 ";" as the empty statement).

 Style guides are valuable within a development group, and I'll claim that
 some of the elements normally found in style guides can be moved into the
 language for the benefit of us all. The empty statement is a good example


of

 this, already considered by Walter. Other elements that should definitely
 not be moved into the languages are guide lines that needs to be broken,
 although rarely, in order to solve specific problems. An example is a line
 length limit; if D had a limit on the line length, it would make it
 impossible to refer to extremely long external symbols. Also, when
 considering making a some style guide part of the language, the complexity
 of the language should be considered. Requiring braces does not making the
 language any more complex.

 I'll prefer consistency over freedom, as long as no freedom is taken away
 from me, that I need to solve problems. Because a piece of code is part of
 one project today, it does not mean that it is not part of a dozen other
 projects tomorrow. And I would like the code in these projects to be
 consistent too.

 Regards,
 Martin M. Pedersen
May 28 2002
prev sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:ad09eo$2gdj$1 digitaldaemon.com...


 Style guides are valuable within a development group, and I'll claim that
 some of the elements normally found in style guides can be moved into the
 language for the benefit of us all. The empty statement is a good example


of

 this, already considered by Walter. Other elements that should definitely
 not be moved into the languages are guide lines that needs to be broken,
 although rarely, in order to solve specific problems. An example is a line
 length limit; if D had a limit on the line length, it would make it
 impossible to refer to extremely long external symbols. Also, when
 considering making a some style guide part of the language, the complexity
 of the language should be considered. Requiring braces does not making the
 language any more complex.


I'd say such things are better left to the group.


 I'll prefer consistency over freedom, as long as no freedom is taken away
 from me, that I need to solve problems. Because a piece of code is part of
 one project today, it does not mean that it is not part of a dozen other
 projects tomorrow. And I would like the code in these projects to be
 consistent too.


The problem is, if I would use that piece of code in my projects,
I'd prefer it to be "consistent" in a way slightly different from
yours...
May 28 2002
parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
Hi,


 I'll prefer consistency over freedom, as long as no freedom is taken




away

 from me, that I need to solve problems. Because a piece of code is part




of

 one project today, it does not mean that it is not part of a dozen other
 projects tomorrow. And I would like the code in these projects to be
 consistent too.


 The problem is, if I would use that piece of code in my projects,
 I'd prefer it to be "consistent" in a way slightly different from
 yours...


I don't think that neither yours or my personal preferences are very
important. Of cause, I have preferences, and have arguments for them. So do
you. But the real value comes when there is consensus in a larger group, and
the larger the group is, the more valuable it is. Moving some aspects into
the langauge makes the group the global community for these aspects. I would
like to see both your and my as input to a style guide (whether enforced or
not) that have as broad an audience as possible. When concensus is there, I
would set my own preferences aside, and stick to that. Reaching consensus is
what is difficult. I don't think it can be done by one dictator; it needs to
be done using some sort of democratic process with lots of discussions -
like the one we had. Perhaps http://www.digitalmars.com/d/dstyle.html is
what I'm talking about, but I don't think it digs into enough detail as it
is now. Perhaps we also need more experience with the language in order to
develop this any further.

Regards,
Martin M. Pedersen
May 29 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:ad2rch$pj3$1 digitaldaemon.com...


 the larger the group is, the more valuable it is. Moving some aspects into
 the langauge makes the group the global community for these aspects. I


would

Large groups are very unefficient when trying to find a consensus. Even
in not very large teams (> 10 members), the coding style is set by the
team leader, and is NOT the result of the consensus (some small parts
of it can be, but 90% is not) - in my practice it is so, at least.


 like to see both your and my as input to a style guide (whether enforced


or

 not) that have as broad an audience as possible. When concensus is there,


I

 would set my own preferences aside, and stick to that. Reaching consensus


is

I wouldn't. As long as it differences from my concept significatly (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?


 what is difficult. I don't think it can be done by one dictator; it needs


to

 be done using some sort of democratic process with lots of discussions -


Democratic institutes tend to be unstable in general, and the whole
principle
don't work at all often when applied to the Net. Besides, democracy means
freedom for everybody, not freedom for the largest group only - and the
latter
is what I see in those syntax proposals.

It is nice to have some general rules, something like what we've seen in
the D reference, maybe a bit more detailed... but whether to follow them or
not should be the _free_ choice of any coder. Sacrificing interests of ones
for the benefit of others is something that should be avoided, IMO.
May 29 2002
parent reply "anderson" <anderson firestar.com.au> writes:
"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.
May 30 2002
parent reply C.R.Chafer <blackmarlin nospam.asean-mail.com> writes:
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
May 31 2002
parent "Walter" <walter digitalmars.com> writes:
"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.
May 31 2002
prev sibling parent reply "Roberto Mariottini" <rmariottini lycosmail.com> writes:
"Pavel Minayev" <evilone omen.ru> ha scritto nel messaggio
news:acm1t1$tuu$1 digitaldaemon.com...

 "Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
 news:aclmhe$jit$1 digitaldaemon.com...


 Sure, then we can apply it to functions:

 int func(int x, int y, int z) return x+2*y+3*z*x;
 void func2(int x, int *y) *y = func(x, x+*y, x-*y);


 Yes, why not? It would be a useful feature for property gettors & settors:

     void width(int w) width = w;
     int width() return width;

 Unfortunately, it cannot be done, due to the ambiguity between forward
 declaration and empty statement:

     void width();    // does it have a body consisting only of ;, or is it


a

 declaration?
 So we _have_ to use braces here, to disambiguate.


It's a declaration, in D you can't use ; to indicate an empty statement.
So no ambiguity here, just 'inconsistenceness'.

Note that if braces were required you could use ; as an empty instruction.


 Or to switch:

 switch(number)    case 1:    return 0;


 There needs to be some way for the compiler to find end of switch
 block. In your example, it does not know where the case ends.
 So, braces are required here.


Case is fall-through, so the above would be perfectly legal, as if you
write:

switch (number) { case 1: } return 0;


 Good. And what about structs:

 struct Astruct
    int i;


 Again, why not? There is no ambiguity here, so I guess the compiler could
 treat struct declarations that way.

 But even here, there's a difference. struct is a _declaration_, it's
 not a statement. if-else is a statement and is defined as:

     if (<condition>) <statement> else <statement>

 Where "statement" is ANY statement. Since complex statement { } is just
 a way to group together simple statements, it suites as well. It has
 nothing to do with struct.


But has something to do with 'consistency', that we were talking of.
I propose:
    if (<expression>) <block> [else <block>]
that is consistent with:
   <type-decl> <ident> ( <arg_list>) <block>
for functions.


 Beautiful. :-(


 Maybe not for you.


Definitely.


 I vote for mandatory brackets everywhere (so the language would be
 internally consistant).


 I vote for NO mandatory brackets everywhere it can be allowed (and
 maybe where it makes sence, since struct or class consisting of
 one member is not something you're gonna use more than once a year =)):
 that is, everywhere except for functions, switch, struct, class
 and enum. In other words, I vote for what is in DMD today.

 I don't really understand "consistency" here - why would anybody care
 why braces around struct are required, not so for if blocks...
 I care more about line count:

     if (flag)
         live();
     else
         die();

 Short AND clear, as long as you indent everything properly. Why waste
 4 more lines?

     if (flag)
     {
         live();
     }
     else
     {
         die();
     }

 I don't understand... is it ANY better, clearer, easier to read than
 the first version?


This is the wrong example. The hello wold program is better if written
in BASIC:

PRINT "Hello World!"

In D:

import something;
int main()
{
    printf("%s\n", "Hello, World!");
}

Is it ANY better, clearer, easier to read?
Look:

if (flag1)
  if (flag2)
      live();
  else
     if (flag3)
        if (flag4)
           die();
     else
        live();
else
    die();

Insert the right braces, and then tell me.

Ciao
May 28 2002
next sibling parent reply "anderson" <anderson firestar.com.au> writes:
"Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
news:acvicq$1ds6$1 digitaldaemon.com...

 "Pavel Minayev" <evilone omen.ru> ha scritto nel messaggio
 news:acm1t1$tuu$1 digitaldaemon.com...

 "Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
 news:aclmhe$jit$1 digitaldaemon.com...


 Sure, then we can apply it to functions:

 int func(int x, int y, int z) return x+2*y+3*z*x;
 void func2(int x, int *y) *y = func(x, x+*y, x-*y);


 Yes, why not? It would be a useful feature for property gettors &




settors:

     void width(int w) width = w;
     int width() return width;

 Unfortunately, it cannot be done, due to the ambiguity between forward
 declaration and empty statement:

     void width();    // does it have a body consisting only of ;, or is




it

 a

 declaration?
 So we _have_ to use braces here, to disambiguate.


 It's a declaration, in D you can't use ; to indicate an empty statement.
 So no ambiguity here, just 'inconsistenceness'.

 Note that if braces were required you could use ; as an empty instruction.


 Or to switch:

 switch(number)    case 1:    return 0;


 There needs to be some way for the compiler to find end of switch
 block. In your example, it does not know where the case ends.
 So, braces are required here.


 Case is fall-through, so the above would be perfectly legal, as if you
 write:

 switch (number) { case 1: } return 0;


 Good. And what about structs:

 struct Astruct
    int i;


 Again, why not? There is no ambiguity here, so I guess the compiler




could

 treat struct declarations that way.

 But even here, there's a difference. struct is a _declaration_, it's
 not a statement. if-else is a statement and is defined as:

     if (<condition>) <statement> else <statement>

 Where "statement" is ANY statement. Since complex statement { } is just
 a way to group together simple statements, it suites as well. It has
 nothing to do with struct.


 But has something to do with 'consistency', that we were talking of.
 I propose:
     if (<expression>) <block> [else <block>]
 that is consistent with:
    <type-decl> <ident> ( <arg_list>) <block>
 for functions.


 Beautiful. :-(


 Maybe not for you.


 Definitely.


 I vote for mandatory brackets everywhere (so the language would be
 internally consistant).


 I vote for NO mandatory brackets everywhere it can be allowed (and
 maybe where it makes sence, since struct or class consisting of
 one member is not something you're gonna use more than once a year =)):
 that is, everywhere except for functions, switch, struct, class
 and enum. In other words, I vote for what is in DMD today.

 I don't really understand "consistency" here - why would anybody care
 why braces around struct are required, not so for if blocks...
 I care more about line count:

     if (flag)
         live();
     else
         die();

 Short AND clear, as long as you indent everything properly. Why waste
 4 more lines?

     if (flag)
     {
         live();
     }
     else
     {
         die();
     }

 I don't understand... is it ANY better, clearer, easier to read than
 the first version?


 This is the wrong example. The hello wold program is better if written
 in BASIC:

 PRINT "Hello World!"

 In D:

 import something;
 int main()
 {
     printf("%s\n", "Hello, World!");
 }

 Is it ANY better, clearer, easier to read?
 Look:

 if (flag1)
   if (flag2)
       live();
   else
      if (flag3)
         if (flag4)
            die();
      else
         live();
 else
     die();


try,

    if (flag1)
    {
        if (flag2)
            live();
        else if (flag3)
           (flag4)?die():live();
    }
    else
          die();

I think it's a matter of balance to many {} make things look ugly and too
little can also. Bracket compainers probably even use non-bracket syntax
without even realizing it. When I program,

if (I use brackets)
{
        then I leave them in when I reduce the line count to 1
}
else
{
        unless it looks ugly
}.

Which the above does

if (I use brackets) then I leave them in when I reduce the line count to 1
else unless it looks ugly.

I like to read code my code as if was reading a well written book or text.
If things are small I like to put them into one line ie

if (a == b) f(n) else g(n)

because (to me at least) they may have the potential to be converted to,

(a == b)?f(n):g(n);

Which may change into something more optimal.

The moral is don't go overboard....

(flag1)?
    (flag2)?
        live()
    :(flag3)?
        ((flag4)?die():live()):
    die():0;



 Insert the right braces, and then tell me.

 Ciao
May 28 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"anderson" <anderson firestar.com.au> wrote in message
news:acvo58$1o2a$1 digitaldaemon.com...


 I think it's a matter of balance to many {} make things look ugly and too
 little can also. Bracket compainers probably even use non-bracket syntax
 without even realizing it. When I program,


Exactly! That's what I was trying to explain for about a month already...
(or was it more?)
May 28 2002
parent reply "anderson" <anderson firestar.com.au> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:ad01q8$27au$1 digitaldaemon.com...

 "anderson" <anderson firestar.com.au> wrote in message
 news:acvo58$1o2a$1 digitaldaemon.com...


 I think it's a matter of balance to many {} make things look ugly and




too

 little can also. Bracket compainers probably even use non-bracket syntax
 without even realizing it. When I program,


 Exactly! That's what I was trying to explain for about a month already...
 (or was it more?)



Thanks,

Sorry for changing the subject on you Pavel Minayev (it was partly Sandor
Hojtsy fault as well) but
wow, I've never had a reply this long before. And I'm kind of happy Walter
keep out of this flame war.

--
Lets shake brakes and make up.
May 28 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"anderson" <anderson firestar.com.au> wrote in message
news:ad02u6$28pq$1 digitaldaemon.com...


 wow, I've never had a reply this long before. And I'm kind of happy Walter
 keep out of this flame war.


Oh yes. I'm even more happy because the way D currently works is
mostly what I'd like to see... =)
May 28 2002
prev sibling parent reply C.R.Chafer <blackmarlin nospam.asean-mail.com> writes:
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
May 28 2002
next sibling parent "anderson" <anderson firestar.com.au> writes:
Nice, but I though the objective was to make things simple. But the idea is
sound "get out of the square".

"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
May 28 2002
prev sibling next sibling parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"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



You have waaaaay to much time on your hands!
Get a life!    :P   :)


--
Stijn
OddesE_XYZ hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail
May 29 2002
parent C.R.Chafer <blackmarlin nospam.asean-mail.com> writes:
OddesE wrote:


 "C.R.Chafer" <blackmarlin nospam.asean-mail.com> wrote in message



 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


 
 
 You have waaaaay to much time on your hands!
 Get a life!    :P   :)
 


hehehe. By the way this only took 10 minutes - you can tell by the way I 
messed up and wrote flag4() due to inadequate checking :-)

C 2002/5/30

PS: I think this works though I have not tested it,  but by my method it 
seems logically sound.
May 30 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
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
May 31 2002
prev sibling next sibling parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
news:aclmhe$jit$1 digitaldaemon.com...

 "C.R.Chafer" <blackmarlin nospam.asean-mail.com> wrote in message
 news:aclb1b$8rh$1 digitaldaemon.com...

 I disagree - the language should be internally consistant,  therefore
 anywhere where block statements are permissable it should be possible
 should be possible to be replace them with a singe statement - even if




the

 result is less than perfect,  as in this case.


 Sure, then we can apply it to functions:

 int func(int x, int y, int z) return x+2*y+3*z*x;
 void func2(int x, int *y) *y = func(x, x+*y, x-*y);

 Or to switch:

 switch(number)    case 1:    return 0;

 Good. And what about structs:

 struct Astruct
    int i;


Mmmm... I didn't think he meant declarations, but
statements. struct and function declarations surely
should have mandatory braces! But I do think that in
a switch braces should not be necessary. And that
the fall-through behaviour should be fixed, but that
is another point!



 Beautiful. :-(
 I vote for mandatory brackets everywhere (so the language would be
 internally consistant).

 Ciao.


Yuck!
Compare this:

if (i < 0)
{
    printf ('a');
}
else if (i == 0)
{
    printf ('b');
}
else
{
    printf ('c');
}

To this:

if (i < 0)
    printf ('a');
else if (i == 0)
    printf ('b');
else
    printf ('c');


--
Stijn
OddesE_XYZ hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail
May 26 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:acqeh4$6d5$1 digitaldaemon.com...


 Yuck!
 Compare this:

 if (i < 0)
 {
     printf ('a');
 }
 else if (i == 0)
 {
     printf ('b');
 }
 else
 {
     printf ('c');
 }


In fact, the right version would be even worse if brackets are mandatory:

    if (i < 0)
    {
        printf("a");
    }
    else
    {
        if (i == 0)
        {
            printf("b");
        }
        else
        {
            printf("c");
        }
    }
May 26 2002
parent "Roberto Mariottini" <rmariottini lycosmail.com> writes:
"Pavel Minayev" <evilone omen.ru> ha scritto nel messaggio
news:acqiq9$9te$1 digitaldaemon.com...

 "OddesE" <OddesE_XYZ hotmail.com> wrote in message
 news:acqeh4$6d5$1 digitaldaemon.com...


 Yuck!
 Compare this:

 if (i < 0)
 {
     printf ('a');
 }
 else if (i == 0)
 {
     printf ('b');
 }
 else
 {
     printf ('c');
 }


 In fact, the right version would be even worse if brackets are mandatory:

     if (i < 0)
     {
         printf("a");
     }
     else
     {
         if (i == 0)
         {
             printf("b");
         }
         else
         {
             printf("c");
         }
     }


In my proposal, the else-if is handled as a particular case:

  if-instr ::=  if ( <expr>) <block> |  if ( <expr>) <block> else
<else-istr>
  else-istr ::= <block> | <if-instr>

Ciao
May 28 2002
prev sibling parent reply "Roberto Mariottini" <rmariottini lycosmail.com> writes:
"OddesE" <OddesE_XYZ hotmail.com> ha scritto nel messaggio
news:acqeh4$6d5$1 digitaldaemon.com...

 "Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
 news:aclmhe$jit$1 digitaldaemon.com...

 Sure, then we can apply it to functions:

 int func(int x, int y, int z) return x+2*y+3*z*x;
 void func2(int x, int *y) *y = func(x, x+*y, x-*y);

 Or to switch:

 switch(number)    case 1:    return 0;

 Good. And what about structs:

 struct Astruct
    int i;


 Mmmm... I didn't think he meant declarations, but
 statements. struct and function declarations surely
 should have mandatory braces!


Function _declarations_ are prototypes.
Theese are function _definitions_, so instructions.
May 28 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
news:acviir$1e8g$1 digitaldaemon.com...

 "OddesE" <OddesE_XYZ hotmail.com> ha scritto nel messaggio
 news:acqeh4$6d5$1 digitaldaemon.com...

 "Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
 news:aclmhe$jit$1 digitaldaemon.com...

 Sure, then we can apply it to functions:

 int func(int x, int y, int z) return x+2*y+3*z*x;
 void func2(int x, int *y) *y = func(x, x+*y, x-*y);

 Or to switch:

 switch(number)    case 1:    return 0;

 Good. And what about structs:

 struct Astruct
    int i;


 Mmmm... I didn't think he meant declarations, but
 statements. struct and function declarations surely
 should have mandatory braces!


 Function _declarations_ are prototypes.
 Theese are function _definitions_, so instructions.


I guess you are right that they are definitions, but
to then conclude that that makes them instructions...Mmm

At least if you talk about statements, I consider them
to be kind-of atomic in nature. A function is a definition
of a whole block of statements that can be called under
one name. I understand your standpoints and there is a
lot to say for mandatory braces, but I have tried both
styles and I just don't like mandatory braces. I feel
it obfuscates my code because the pieces of code where
the 'action' happens get spread to thin.

I am not saying I want to save lines, just that I like
to keep the 'action' together. I often code like this:


// ==========================================
/**
  Documentation....
*/
// ==========================================
void myFunction()
{
   myOtherFunction();
   anotherFunction();
   yetAnotherFunction();
}
// ------------------------------------------



// ==========================================
/**
  Documentation....
*/
// ==========================================
void myOtherFunction
{
   // ...
}
// ------------------------------------------


Note how there is lots of space between functions.
Some people call this wasting lines, but I think
that newlines are cheap :) and it helps me easily
seeing where a function ends and where a new one
begins.

Whith code like this however:

if (cond())
{
   myFunction();
}
else
{
   anotherFunction();
}
else if (cond2())
{
   yetAnotherfunction();
}
else
{
   return;
}

I feel the code gets spread too thin and I lose
oversight. Compare it to this:

if (cond())
   myFunction();
else
   anotherFunction();
else if (cond2())
   yetAnotherfunction();
else
   return;

A lot more compact. If there is more code it will
often mean the difference between making a complex
if structure fit on your screen or not. And out of
the screen, out of the heart and mind so to speak... :)

But unlike Pavel, if global consensus where reached
on this I would lay aside my proud and adopt them.
But this is easy to say, because I seriously doubt
that concensus on this wil ever be reached!


--
Stijn
OddesE_XYZ hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail
May 29 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:ad365a$160j$1 digitaldaemon.com...


 But unlike Pavel, if global consensus where reached
 on this I would lay aside my proud and adopt them.
 But this is easy to say, because I seriously doubt
 that concensus on this wil ever be reached!


Yes, exactly. The problem is, there are just two radical solutions:
require braces or not. Whichever you choose, there will be A LOT
of people unsatisfied with your choice. I'm afraid that true concensus
is just impossible to reach on this subject.

In the meantime, we could discuss the problem of soft vs hard tabs... =)
May 29 2002
prev sibling next sibling parent Ben Cohen <bc skygate.co.uk> writes:
On Fri, 24 May 2002 16:39:16 +0100, Roberto Mariottini wrote:


 Or to switch:
 
 switch(number)    case 1:    return 0;


That works in GCC and (I'm told) Visual C++.  I don't know whether it's
actually valid C.
May 27 2002
prev sibling parent "Matthew Wilson" <mwilson nextgengaming.com> writes:
Completely agree. Once you get in the habit any additional effort is
unnoticeable (esp. where one uses IDE macros to insert them)


"Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
news:aclmhe$jit$1 digitaldaemon.com...

 "C.R.Chafer" <blackmarlin nospam.asean-mail.com> wrote in message
 news:aclb1b$8rh$1 digitaldaemon.com...

 I disagree - the language should be internally consistant,  therefore
 anywhere where block statements are permissable it should be possible
 should be possible to be replace them with a singe statement - even if




the

 result is less than perfect,  as in this case.


 Sure, then we can apply it to functions:

 int func(int x, int y, int z) return x+2*y+3*z*x;
 void func2(int x, int *y) *y = func(x, x+*y, x-*y);

 Or to switch:

 switch(number)    case 1:    return 0;

 Good. And what about structs:

 struct Astruct
    int i;

 Beautiful. :-(
 I vote for mandatory brackets everywhere (so the language would be
 internally consistant).

 Ciao.
May 27 2002
prev sibling parent "OddesE" <OddesE_XYZ hotmail.com> writes:
"C.R.Chafer" <blackmarlin nospam.asean-mail.com> wrote in message
news:aclb1b$8rh$1 digitaldaemon.com...
<SNIP>

 I disagree - the language should be internally consistant,  therefore
 anywhere where block statements are permissable it should be possible
 should be possible to be replace them with a singe statement - even if the
 result is less than perfect,  as in this case.

 C 2002/5/24


Agreed!


--
Stijn
OddesE_XYZ hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail
May 26 2002
prev sibling next sibling parent "anderson" <anderson firestar.com.au> writes:
"Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
news:acla54$84a$1 digitaldaemon.com...

 "anderson" <anderson firestar.com.au> ha scritto nel messaggio
 news:acl30i$2sht$1 digitaldaemon.com...
 [...]

 int fn()
 {
     my_type1  my_obj1 = new my_obj1;

     try my_type2  my_obj2 = new my_obj2;

         try my_type3 my_obj3 = new my_obj3;

             try whatever();
             finally my_obj3.close();

         finally my_obj2.release();

    finally my_obj1.destroy();
 }


 [...]

 I hate this...
 I vote for mandatory brackets.

 Ciao


That's a POV (point of view).  I agree that, in this situtuation brackets
look better. Sometimes those brakets can look ugly though, and triesome code
blotters.
May 24 2002
prev sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
news:acla54$84a$1 digitaldaemon.com...


 "anderson" <anderson firestar.com.au> ha scritto nel messaggio
 news:acl30i$2sht$1 digitaldaemon.com...
 [...]

 int fn()
 {
     my_type1  my_obj1 = new my_obj1;

     try my_type2  my_obj2 = new my_obj2;

         try my_type3 my_obj3 = new my_obj3;

             try whatever();
             finally my_obj3.close();

         finally my_obj2.release();

    finally my_obj1.destroy();
 }


 [...]

 I hate this...


Don't like it - don't use it. But let other people do what they want.
By the way, the code above is not correct: there are TWO statements
in each try-block (since declaration is also a statement), so
curly braces are required

And it's not that awful. Consider something like this:

    Foo foo = new Foo;
    try
        foo.bar();
    finally
        delete foo;

And compare this to:

    Foo foo = new Foo;
    try
    { foo.bar()
    } finally
    { delete foo;
    }

Now, which looks better? =) It's a matter of taste, after all.
May 24 2002
parent reply "anderson" <anderson firestar.com.au> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:aclgbn$dso$1 digitaldaemon.com...

 Don't like it - don't use it. But let other people do what they want.
 By the way, the code above is not correct: there are TWO statements
 in each try-block (since declaration is also a statement), so
 curly braces are required


I'd have to dissagree (I don't know if the code is correct for D but
consider and if-else)

if (...) ...
    if (...) ...
        if (...) ...
        else ...
    else ...
else ...

(... = some code)

a try-finally should be considered one statement just as if-else.


 And it's not that awful. Consider something like this:

     Foo foo = new Foo;
     try
         foo.bar();
     finally
         delete foo;


That looks good.


 And compare this to:

     Foo foo = new Foo;
     try
     { foo.bar()
     } finally
     { delete foo;
     }

 Now, which looks better? =) It's a matter of taste, after all.
May 24 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"anderson" <anderson firestar.com.au> wrote in message
news:acmt64$1mru$1 digitaldaemon.com...


 I'd have to dissagree (I don't know if the code is correct for D but
 consider and if-else)

 if (...) ...
     if (...) ...
         if (...) ...
         else ...
     else ...
 else ...

 (... = some code)

 a try-finally should be considered one statement just as if-else.


No, no, I didn't mean that. Of course it should. But in your code,
in the try block (not in the catch block!), you had two statements:
declaration, and function call.
May 24 2002
parent "anderson" <anderson firestar.com.au> writes:
Your right! How'd I miss that.

"Pavel Minayev" <evilone omen.ru> wrote in message
news:acn1km$1q7p$1 digitaldaemon.com...

 "anderson" <anderson firestar.com.au> wrote in message
 news:acmt64$1mru$1 digitaldaemon.com...


 I'd have to dissagree (I don't know if the code is correct for D but
 consider and if-else)

 if (...) ...
     if (...) ...
         if (...) ...
         else ...
     else ...
 else ...

 (... = some code)

 a try-finally should be considered one statement just as if-else.


 No, no, I didn't mean that. Of course it should. But in your code,
 in the try block (not in the catch block!), you had two statements:
 declaration, and function call.
May 25 2002