tigrisek@interia.pl ("Robert Kawulak") wrote in message news:<cc672c$r7g$1@nemesis.news.tpi.pl>...
> > > > If you have large units of abstraction (classes, functions,
> > > > statements, blocks, etc.), or large, nested, cascading if-else,
> > > > switch-case, for-loops, pages and pages long, then it may be hard to
> > > > keep track of which closing brace belongs to what. However, the real
> > > > problem is the large, complex units, not lack of comments.
>
>   Generally, I agree with you that it's better to have less complex and
> smaller units. Unfortunately, it's not always as easy as it seems.

As mentioned, it's my experience that more experienced people are
better at modularising software (just take a look at the Boost
libraries, for example. A lot can be learned by looking at the code).
In contrast, some of the current codebase I'm working on, is some of
the most unvieldy mess I've seen. I'm working on refactoring it, but
it's a lot of work. It essentially involves creating appropriate
abstractions, doing what the original developers should have done.
However, I know that letting the mess stay means even more work (when
it comes to maintaining and extending it).

> Sometimes
> it's better to cope with imperfect things in the best way you can rather
> than think how to make them perfect.

Naturally, it's a cost/benefit analysis. I didn't start refactoring
the codebase until the situation really started to hurt (since I knew
it would be a lot of work). When it was clear that we were likely (and
now it's certain) to extend it quite a lot, I started on the work, to
make less work extending it.

>   Consider, for instance, quite long switch statement (this is something
> usual, e.g. when programming in Win32 API). Nobody will split it into
> several smaller switch statements or whatever just because it doesn't fit on
> one screen. I know many people will answer not to use Win32 API because
> it's ugly (which I agree), but sometimes I have to (or I want to because
> it's the easiest way)

I was faced with this a few years ago, as a private project - to use
the Windows API. However, I found that I didn't like neither the Win32
API nor MFC, so I started on writing a wrapper for Win32, to create an
event-based GUI library (so that it would resemble Java's way of doing
it, adding "event listeners" (Observers) to event producers). So, yes,
this is an answer to the question "What to do with a large
switch-statement?": "Mu!" In other words, don't create one to begin
with.

I stopped developing the above library when I found wxWindows, which I
found to be a quite clean GUI API (if very old C++ - no templates,
exceptions, etc.), better than MFC. If I were to do something today
with the Windows GUI, I'd probably use wxWindows (even if I didn't
need platform portability, although it's a nice plus). As it's free, I
really don't see any objection to using it, rather than Win32, at
least for new projects.

> and C++ is meant to support many programming styles,
> techniques, paradigms or whatever you call it - to be universal as it
> possibly can be.

Indeed, and I like that.

>   Also, when there are several nested blocks, it's very easy to get bogged
> in closing brace brackets.

Then you might be better off extracting some of the loop contents into
functions. There's a general guideline that Francis Glassborow once
mentioned, about not nesting loops, or having two loops in succession
in the same function. The rationale for it was that then the function
may have too much responsibility.

Regarding what you've said about real-life systems: I've found that
keeping systems modular becomes more important, the bigger they are.

> I still insist that confirmations improve
> legibility in such places and in many others, because you don't waste your
> time figuring out which bracket corresponds to which block (which is a case
> even in well indented code). You write, however, that the problem is rather
> using large and nested blocks. But there's no way, IMO, to ged completely
> rid of them. One might make every block a function and place the function
> call instead of it, but I don't thing it would make following the code
> easier :-/ You would have to jump from one function's body to another all
> the time.

The key is to create cohesive units - and to use meaningful names to
describe what each part does. That allows you to "drill down" in the
structure, and to view it at different levels of abstraction, rather
than having it as a "flat structure". This "fractal" nature of a
system is arguable a cornerstone of good software design.

>   Moreover, I use commented-out confirmations even in non-complex code - in
> classes definitions, switch statements, and so on. They simply do help me
> and I think it's a good habit to use them.

You may think it's a good habit for you, and that's just fine, but
others may not find it the same way for themselves. This is of course
very subjective.

Interestingly, as Frank Birbacher mentions in a later posting, I also
tend to use such "confirmations" on namespaces (possibly with
indentation), because they may span quite a lot:

namespace a {
namespace b {
namespace c {
..
} // namespace c
} // namespace b
} // namespace a

The reason I haven't mentioned that before, is that it wasn't among
your code examples in the original posting (although I see you
mentioned it in the posting).


Regards,

Terje

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> > > If you have large units of abstraction (classes, functions,
> > > statements, blocks, etc.), or large, nested, cascading if-else,
> > > switch-case, for-loops, pages and pages long, then it may be hard to
> > > keep track of which closing brace belongs to what. However, the real
> > > problem is the large, complex units, not lack of comments.

  Generally, I agree with you that it's better to have less complex and
smaller units. Unfortunately, it's not always as easy as it seems. Sometimes
it's better to cope with imperfect things in the best way you can rather
than think how to make them perfect. Simply nothing can be made really
perfect in real world, or trying to make it perfect may simply cost you too
much and be unprofitable.
  Consider, for instance, quite long switch statement (this is something
usual, e.g. when programming in Win32 API). Nobody will split it into
several smaller switch statements or whatever just because it doesn't fit on
one screen. I know many people will answer not to use Win32 API because
it's ugly (which I agree), but sometimes I have to (or I want to because
it's the easiest way) and C++ is meant to support many programming styles,
techniques, paradigms or whatever you call it - to be universal as it
possibly can be.
  Also, when there are several nested blocks, it's very easy to get bogged
in closing brace brackets. I still insist that confirmations improve
legibility in such places and in many others, because you don't waste your
time figuring out which bracket corresponds to which block (which is a case
even in well indented code). You write, however, that the problem is rather
using large and nested blocks. But there's no way, IMO, to ged completely
rid of them. One might make every block a function and place the function
call instead of it, but I don't thing it would make following the code
easier :-/ You would have to jump from one function's body to another all
the time. Sometimes making a bit of code which is used only once a separate
function doesn't make sence (I know it'a an exaggeration, but I've used it
to present my way of thinking).
  Moreover, I use commented-out confirmations even in non-complex code - in
classes definitions, switch statements, and so on. They simply do help me
and I think it's a good habit to use them.

> the comments (or similar language construct) might instead end
> up more as clutter than help.

  I agree, that in some cases using a confirmation may worsen legibility.
Nobody would use them for one line long function. Nobody is forced to use
them at all.

Greetings,
RK




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi!

Robert Kawulak wrote:
>   Some time ago I've written here about the idea of letting a programmer
> explicitly repeat the name of a function (class, namespace etc.) after it's
> closing bracket (make a name "confirmation"). Not many people replied, and
> those who did, commented on my example (inappropriate one, I confess ;)
> rather than on the idea itself. Doesn't anybody like the idea and feel it
> might be useful to be able to write such confirmations?

Except for namespace (which I comment) and class scopes, a scope
shouldn't be much larger than a screen page. In this case
indentation makes things clear. I never felt the need for name
confirmation.

Frank

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> However, currently, all comments are stripped before the compiler (i.e.
> that part of the implementation that actually 'understands' source code)
> runs. Note that comments are tokenised as whitespace in translation
> phase 3. Your proposal would have radical implications on this process.

You've probably confused the proposal with Mr. James Kuyper's post:

>> I think (correct me if I'm wrong) that the whole point of the OP was
>> that the compiler would *check* the confirmation, if you provide it.
>> The compiler can't check comments. I certainly like the OP's idea very
>> much, but it might be difficult to do it without breaking existing
>> code, although maybe one can come up with some clever
>> backward-compatible syntax.
>There's no reason why the compiler couldn't check comments; it would
>be a bad idea, but there's no reason why it couldn't be done. The
>standard could mandate that a comment in some specific format be
>parsed by the compiler, and if that format is used, the standard could
>mandate a diagnostic if the function or class name didn't match.

My proposal consists in replacing comments with names confirmations, so
there would be no comments to check by compiler (this actually would be a
horrible solution IMO ;-).


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi!

> >   Some time ago I've written here about the idea of letting a programmer
> > explicitly repeat the name of a function (class, namespace etc.) after
it's
> > closing bracket (make a name "confirmation").
[...]
>     Another price exacted by C++ is the penalty for breaking
> up class member functions.  Adding a function member to a
> class requires modifying the class declaration, which can
> impact modules that use the class.  This encourages function
> bloat.  There are workarounds involving "implementation
> classes", but they add code bloat too.
>
>     As I've pointed out before, there's no major problem
> with allowing file-local private member functions that don't
> appear in the class definition.  That would be a useful,
> and safe, relaxation of the rules.  (If you think it's unsafe,
> think about who can call a private function.)

I fully agree with you, although I can't see any connection with the idea of
explicit names confirmations... Is there something I've missed?


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi!

> He feels it adds clarity to the code (like you argue). However, this
> is clearly subjective, and for me, the comments are just visual
> clutter, and I find the code clearer without it:

There are as many programming styles as programmers ;-)

> If you have large units of abstraction (classes, functions,
> statements, blocks, etc.), or large, nested, cascading if-else,
> switch-case, for-loops, pages and pages long, then it may be hard to
> keep track of which closing brace belongs to what. However, the real
> problem is the large, complex units, not lack of comments.

You mean one should try to break a unit into smaller units rather than try
to cope with the large one. This is generally good. However, in real-world
programming, it's not always as easy as it seems, or sometimes it can make
your design even more compilcated. The best proof for usefulness of the
feature is the number of programmers using some kind of their own-invented
confirmations in a form of comments. So why shouldn't we 'civilise' and
_standarise_ the confirmations and make them a part of the language? (With
standarised confirmations the code containing them will be much easier to
read and understand.)

> Moreover, like all comments, they risk getting out of sync with the
> code (or be wrong to begin with). I've experienced being thrown off by
> a wrong comment (i.e. "// end if", when it should be "// end for"),
> and wrong comments are worse than no comments.

And this is one of the reasons for my idea ;-)

> However, even with compiler checking, adding the name at the end of
> the blocks constitutes duplication, and duplication in general is bad.
> It means two places to update, to change the name, rather than just
> one.

I agree with you, but keep in mind, that in this case such an error (when
you change a name, but forget to change the corresponding confirmation)
would be caught by compiler no matter what, so there's no danger resulting
from duplication at all. And catching it by compiler is the point of the
idea of confirmations! Moreover, you duplicate the name only once and only
in one strictly specified place (right after the end of a block), so it's
rather a different kind of duplication than for instance writing everywhere
3.14 instead of using a constant named Pi.

Greetings,
RK


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> There would be no market for BoundsCheckers or PC-lints
> of the world if all those checks are made by the compiler.  People
> have got to eat, you know.

It sounds to me a little bit like 'why should we have the standard library -
there are so many creative people who would like to do it their way'... The
main reason is *compatibility* which is not the case when we use external
tools to solve a problem - only the standard guarantees that (well, at least
in theory ;-).



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <cbjhjo$kc3$1@atlantis.news.tpi.pl>, Robert Kawulak
<tigrisek@interia.pl> writes
>I agree with you, but keep in mind, that in this case such an error (when
>you change a name, but forget to change the corresponding confirmation)
>would be caught by compiler no matter what, so there's no danger resulting
>from duplication at all. And catching it by compiler is the point of the
>idea of confirmations! Moreover, you duplicate the name only once and only
>in one strictly specified place (right after the end of a block), so it's
>rather a different kind of duplication than for instance writing everywhere
>3.14 instead of using a constant named Pi.

However, currently, all comments are stripped before the compiler (i.e.
that part of the implementation that actually 'understands' source code)
runs. Note that comments are tokenised as whitespace in translation
phase 3. Your proposal would have radical implications on this process.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

tigrisek@interia.pl ("Robert Kawulak") wrote in message news:<cbjhjo$kc3$1@atlantis.news.tpi.pl>...
>
> > If you have large units of abstraction (classes, functions,
> > statements, blocks, etc.), or large, nested, cascading if-else,
> > switch-case, for-loops, pages and pages long, then it may be hard to
> > keep track of which closing brace belongs to what. However, the real
> > problem is the large, complex units, not lack of comments.
>
> You mean one should try to break a unit into smaller units rather than try
> to cope with the large one.

The units should be cohesive - the well-known high cohesion, low
coupling (HCLC) principle. Size doesn't really have anything to do
with it, and a function can be a single line, or quite long, depending
on what it does. A long function in itself doesn't necessarily mean
it's bad, but it's a sign that it might need refactoring.

In general, each unit should do one thing. However, whether something
is one thing, or several things, I guess also depends on the level of
abstraction.

> This is generally good. However, in real-world
> programming, it's not always as easy as it seems, or sometimes it can make
> your design even more compilcated.

I can't see how that could be. Do you mean if something is broken up
into "too many" parts? I guess what constitutes the right granularity
is a judgement call, but my expeience is that more experienced
developers tend to end up with smaller units of abstraction.

This is not at least important in "real-world programming". I'm doing
real-world programming, and the lack of modularisation and use of
appropriate abstraction by previous developers has caused us a real
maintenance nightmare. So this is not just some "academical" concern.

> The best proof for usefulness of the
> feature is the number of programmers using some kind of their own-invented
> confirmations in a form of comments.

Well, my point of the prevoius posting, was to point out that the
perceived need for comments, or a language feature for this, may be
motivated by something that can be solved with better modularisation,
where the comments (or similar language construct) might instead end
up more as clutter than help.

Regards,

Terje

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Robert Kawulak wrote:

> Hi!
>
>   Some time ago I've written here about the idea of letting a programmer
> explicitly repeat the name of a function (class, namespace etc.) after it's
> closing bracket (make a name "confirmation").

    Wirth tried this in one of the Modula variants, but it didn't
catch on.

    The real problem is that C++ is hard to automatically indent.
Few editors can get it right.  "astyle" does reasonably well,
but can become confused.  C++ is, of course, a context-dependent
language, and can't be parsed without seeing all the declarations.
A price is paid for this.

    Another price exacted by C++ is the penalty for breaking
up class member functions.  Adding a function member to a
class requires modifying the class declaration, which can
impact modules that use the class.  This encourages function
bloat.  There are workarounds involving "implementation
classes", but they add code bloat too.

    As I've pointed out before, there's no major problem
with allowing file-local private member functions that don't
appear in the class definition.  That would be a useful,
and safe, relaxation of the rules.  (If you think it's unsafe,
think about who can call a private function.)

    John Nagle
    Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:

>    As I've pointed out before, there's no major problem
> with allowing file-local private member functions that don't
> appear in the class definition.  That would be a useful,
> and safe, relaxation of the rules.  (If you think it's unsafe,
> think about who can call a private function.)

I mostly agree, but I think those function should also be non-virtual.

--=20
Lo=EFc

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <4hODc.78882$WV1.2835@newssvr29.news.prodigy.com>, John Nagle
<nagle@animats.com> writes
>   As I've pointed out before, there's no major problem
>with allowing file-local private member functions that don't
>appear in the class definition.  That would be a useful,
>and safe, relaxation of the rules.  (If you think it's unsafe,
>think about who can call a private function.)

Yes, and I for one would welcome some coherent proposal to the WG21
Evolution workgroup proposing a mechanism whereby functions in an
unnamed namespace can be called in definitions of member functions in
the same file and granted private access.

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 06/21/2004 03:56 PM, Robert Kawulak wrote:
> Hi!
>
>   Some time ago I've written here about the idea of letting a programmer
> explicitly repeat the name of a function (class, namespace etc.) after it's
> closing bracket (make a name "confirmation"). Not many people replied, and
> those who did, commented on my example (inappropriate one, I confess ;)
> rather than on the idea itself. Doesn't anybody like the idea and feel it
> might be useful to be able to write such confirmations?
I do.
>   I don't feel up to make the best implementation of this feature; this,
> however, is what I think it *could* possibly look like:
>
>   class c {
>     //...
>   } for c;
>
>   namespace n {
>     //...
>   } for n;
>
>   or maybe even:
>
>   if ( cond )
>   {
>     //...
>   } for if;
>
FWIW, I use //end xxx whenever the distance between { and } is
large.  For example:

   class c
   {
   //...
   }//end c class

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

cppljevans@cox-internet.com (Larry Evans) wrote in message news:<10dekgm9gob1q82@corp.supernews.com>...
> On 06/21/2004 03:56 PM, Robert Kawulak wrote:
> > Hi!
> >
> >   Some time ago I've written here about the idea of letting a programmer
> > explicitly repeat the name of a function (class, namespace etc.) after it's
> > closing bracket (make a name "confirmation"). Not many people replied, and
> > those who did, commented on my example (inappropriate one, I confess ;)
> > rather than on the idea itself. Doesn't anybody like the idea and feel it
> > might be useful to be able to write such confirmations?
>  I do.
> >   I don't feel up to make the best implementation of this feature; this,
> > however, is what I think it *could* possibly look like:
> >
> >  <code>
> FWIW, I use //end xxx whenever the distance between { and } is
> large.  For example:
>
>    class c
>    {
>    //...
>    }//end c class

I think (correct me if I'm wrong) that the whole point of the OP was
that the compiler would *check* the confirmation, if you provide it.
The compiler can't check comments. I certainly like the OP's idea very
much, but it might be difficult to do it without breaking existing
code, although maybe one can come up with some clever
backward-compatible syntax.

--                                    --
To iterate is human, to recurse divine.
-L. Peter Deutsch
--                                    --

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kprateek88@yahoo.com (Prateek R Karandikar) wrote in message news:<607f883e.0406211827.74b833e3@posting.google.com>...
> cppljevans@cox-internet.com (Larry Evans) wrote in message news:<10dekgm9gob1q82@corp.supernews.com>...
..
> > FWIW, I use //end xxx whenever the distance between { and } is
> > large.  For example:
> >
> >    class c
> >    {
> >    //...
> >    }//end c class
>
> I think (correct me if I'm wrong) that the whole point of the OP was
> that the compiler would *check* the confirmation, if you provide it.
> The compiler can't check comments. I certainly like the OP's idea very
> much, but it might be difficult to do it without breaking existing
> code, although maybe one can come up with some clever
> backward-compatible syntax.

There's no reason why the compiler couldn't check comments; it would
be a bad idea, but there's no reason why it couldn't be done. The
standard could mandate that a comment in some specific format be
parsed by the compiler, and if that format is used, the standard could
mandate a diagnostic if the function or class name didn't match.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> I think (correct me if I'm wrong) that the whole point of the OP was
> that the compiler would *check* the confirmation, if you provide it.

Exactly.

> I certainly like the OP's idea very
> much, but it might be difficult to do it without breaking existing
> code, although maybe one can come up with some clever
> backward-compatible syntax.

That's right. So if anybody finds the proposition with 'for' keyword flawed
or has got some other proposition, please write it here.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> > I think (correct me if I'm wrong) that the whole point of the OP was
> > that the compiler would *check* the confirmation, if you provide it.
> > The compiler can't check comments. I certainly like the OP's idea very
> > much, but it might be difficult to do it without breaking existing
> > code, although maybe one can come up with some clever
> > backward-compatible syntax.
>
> There's no reason why the compiler couldn't check comments; it would
> be a bad idea, but there's no reason why it couldn't be done. The
> standard could mandate that a comment in some specific format be
> parsed by the compiler, and if that format is used, the standard could
> mandate a diagnostic if the function or class name didn't match.

I meant that checking comments can't be done without breaking existing
code and making significant changes to the Phases of Translation, as
removal of comments is done much before other synctatic and semantic
analysis.

--                                    --
To iterate is human, to recurse divine.
-L. Peter Deutsch
--                                    --

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Prateek R Karandikar wrote:
> cppljevans@cox-internet.com (Larry Evans) wrote in message news:<10dekgm9gob1q82@corp.supernews.com>...
>
>>On 06/21/2004 03:56 PM, Robert Kawulak wrote:
>>
>>>Hi!
>>>
>>>  Some time ago I've written here about the idea of letting a programmer
>>>explicitly repeat the name of a function (class, namespace etc.) after it's
>>>closing bracket (make a name "confirmation"). Not many people replied, and
>>>those who did, commented on my example (inappropriate one, I confess ;)
>>>rather than on the idea itself. Doesn't anybody like the idea and feel it
>>>might be useful to be able to write such confirmations?
>>
>> I do.
>>
>>>  I don't feel up to make the best implementation of this feature; this,
>>>however, is what I think it *could* possibly look like:
>>>
>>> <code>
>>
>>FWIW, I use //end xxx whenever the distance between { and } is
>>large.  For example:
>>
>>   class c
>>   {
>>   //...
>>   }//end c class
>
>
> I think (correct me if I'm wrong) that the whole point of the OP was
> that the compiler would *check* the confirmation, if you provide it.
> The compiler can't check comments. I certainly like the OP's idea very
> much, but it might be difficult to do it without breaking existing
> code, although maybe one can come up with some clever
> backward-compatible syntax.

I for one don't think that such task should be dropped on compiler's
shoulders.  There would be no market for BoundsCheckers or PC-lints
of the world if all those checks are made by the compiler.  People
have got to eat, you know.  Besides, just like Microsoft's Class Wiz
reads '//{{' and '//}}' in the source, so could some tools that would
check your closing curly braces.

Keep the functionality provided by the language to the bare minimum
and then we have a decent, extendable, language, fast compilers, etc.

Victor

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

tigrisek@interia.pl ("Robert Kawulak") wrote in message news:<cb7h5c$kt1$1@nemesis.news.tpi.pl>...
> Hi!
>
>   Some time ago I've written here about the idea of letting a programmer
> explicitly repeat the name of a function (class, namespace etc.) after it's
> closing bracket (make a name "confirmation"). Not many people replied, and
> those who did, commented on my example (inappropriate one, I confess ;)
> rather than on the idea itself. Doesn't anybody like the idea and feel it
> might be useful to be able to write such confirmations?
>   Once again I'd like to emphasise, that this feature would be optional,
> nobody would be forced to use it. What we could gain from it is better
> clarity of code (which is now achieved by adding such confirmations in
> comments) and letting a compiler check whether the code is what we expect it
> to be (by letting it see the confirmations since they wouldn't be commented
> out anymore).
>   I don't feel up to make the best implementation of this feature; this,
> however, is what I think it *could* possibly look like:
>
>   class c {
>     //...
>   } for c;
>
>   namespace n {
>     //...
>   } for n;
>
>   or maybe even:
>
>   if ( cond )
>   {
>     //...
>   } for if;

I have a coworker who likes to write code like this:

void f()
{
  for(...)
  {
    if(...)
    {
      ...
    } // end if
  } // end for
} // end f

He feels it adds clarity to the code (like you argue). However, this
is clearly subjective, and for me, the comments are just visual
clutter, and I find the code clearer without it:

void f()
{
  for(...)
  {
    if(...)
    {
      ...
    }
  }
}

I think these comments, like all comments, may instead hide deeper
problems. If you have large units of abstraction (classes, functions,
statements, blocks, etc.), or large, nested, cascading if-else,
switch-case, for-loops, pages and pages long, then it may be hard to
keep track of which closing brace belongs to what. However, the real
problem is the large, complex units, not lack of comments.

Moreover, like all comments, they risk getting out of sync with the
code (or be wrong to begin with). I've experienced being thrown off by
a wrong comment (i.e. "// end if", when it should be "// end for"),
and wrong comments are worse than no comments. However, as your
proposal involves compiler checking, this is not an issue in this
case.

However, even with compiler checking, adding the name at the end of
the blocks constitutes duplication, and duplication in general is bad.
It means two places to update, to change the name, rather than just
one.

Regards,

Terje

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 21 Jun 2004 20:56:57 +0000 (UTC), tigrisek@interia.pl ("Robert
Kawulak") wrote:

>Hi!
>
>  Some time ago I've written here about the idea of letting a programmer
>explicitly repeat the name of a function (class, namespace etc.) after it's
>closing bracket (make a name "confirmation"). Not many people replied, and
>those who did, commented on my example (inappropriate one, I confess ;)
>rather than on the idea itself. Doesn't anybody like the idea and feel it
>might be useful to be able to write such confirmations?
>  Once again I'd like to emphasise, that this feature would be optional,
>nobody would be forced to use it. What we could gain from it is better
>clarity of code (which is now achieved by adding such confirmations in
>comments) and letting a compiler check whether the code is what we expect it
>to be (by letting it see the confirmations since they wouldn't be commented
>out anymore).

However, it just adds further redundancy to source code. The clarity
in these things is usually gained from following coding guidelines.
e.g.

1. Indent consistently
2. One namespace and/or class per file
3. Keep functions short
4. etc.

What's more, any decent editor should be able to show you the matching
bracket and the name of the function/class/namespace/file you are
editing.

I suppose I'm just saying that I for one wouldn't find it useful,
which isn't to say that others won't.

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi!

  Some time ago I've written here about the idea of letting a programmer
explicitly repeat the name of a function (class, namespace etc.) after it's
closing bracket (make a name "confirmation"). Not many people replied, and
those who did, commented on my example (inappropriate one, I confess ;)
rather than on the idea itself. Doesn't anybody like the idea and feel it
might be useful to be able to write such confirmations?
  Once again I'd like to emphasise, that this feature would be optional,
nobody would be forced to use it. What we could gain from it is better
clarity of code (which is now achieved by adding such confirmations in
comments) and letting a compiler check whether the code is what we expect it
to be (by letting it see the confirmations since they wouldn't be commented
out anymore).
  I don't feel up to make the best implementation of this feature; this,
however, is what I think it *could* possibly look like:

  class c {
    //...
  } for c;

  namespace n {
    //...
  } for n;

  or maybe even:

  if ( cond )
  {
    //...
  } for if;

Greetz,
RK


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]