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