Walter wrote:

> Your trend idea is a good one; what I've done is do /+  +/ for nested
> comments.
> ...
>     /+
>         code
>         code
>      +/
>
> or even:
>
>     /+++++++++++++
>         code that doesn't work
>         code that doesn't work
>      +++++++++++++/

My favorite block comment looks like this:

/*\
|*|  My comment block.
|*|
\*/

When I had a "more important" comment, the above would become:

/**\
|**|  My function() declaration.
|**|
\**/

And a top-level documentation comment would be:

/***\
|***|  My explanation for why I did this.
|***|
\***/

If nesting is a problem, these can easily become:

///*\
//|*|  Slashes rock.
//|*|
//\*/

Decades ago I wrote emacs lisp code to automate the process of adding, moving, nesting and removing this style of comment.  Then I stopped using emacs and just did it manually.  No hassle, really.

Of course, this looks just dandy too:

/++\
|++|  Then again, on the plus side...
|++|
\++/

We just need to make sure that a back-slash in comments has no special meaning
(a given in D).


-BobC

"Walter" <walter@digitalmars.com> ha scritto nel messaggio news:a3a5nd$2a39$1@digitaldaemon.com...
>
> Your trend idea is a good one; what I've done is do /+  +/ for nested comments. Why not /{  }/? It just didn't look right on the page. I also worried about things like:
>
>     foo() { blah... }// comment
>
> the } and the / just don't go together. The /+ looks similar enough to /*
to
> be recognizable as a comment, but different enough to not be confusing:
>
>     /+
>         code
>         code
>      +/
>
> or even:
>
>     /+++++++++++++
>         code that doesn't work
>         code that doesn't work
>      +++++++++++++/
>
> has a bit of a cachet to it. I thought of /- -/, but it wound up looking like someone trying to draw a picture instead of a comment <g>.

please note that  a = b/-c; is a valid C/C++ statement, and also a = b/+c; BTW, also *p = *q/*r; is a valid C/C++ statement...

Why life is so complicated?

Ciao

"Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:a3at25$2jjj$1@digitaldaemon.com...
> please note that  a = b/-c; is a valid C/C++ statement, and also a = b/+c; BTW, also *p = *q/*r; is a valid C/C++ statement...

We've already learned to live with q/*r, so I don't think that b/+c will be a problem, especially since there is no point to the + in +c.

I prefer my comments not to look like ASCII art.  This is no longer the nineties.  ;)  I find syntax highlighting alone is really good enough.  I set my comment color to grey so it looks like it's greyed out (yet still readable).  I just wish the IDE's would catch up and allow you to specify HTML templates to control how different kinds of things are displayed.  I guess some tools like Together do this.

I kinda like /+ +/, but dang that's gonna be wierd to get used to typing. ;)  I'll get it though.  First time is the roughest.  heh

Thanks, Walter!

Sean

"Robert W. Cunningham" <rwc_2001@yahoo.com> wrote in message news:3C58C0E5.2585BBF4@yahoo.com...
>
> My favorite block comment looks like this:
>
> /*\
> |*|  My comment block.
> |*|
> \*/
>
> When I had a "more important" comment, the above would become:
>
> /**\
> |**|  My function() declaration.
> |**|
> \**/
>
> And a top-level documentation comment would be:
>
> /***\
> |***|  My explanation for why I did this.
> |***|
> \***/
>
> If nesting is a problem, these can easily become:
>
> ///*\
> //|*|  Slashes rock.
> //|*|
> //\*/
>
> Decades ago I wrote emacs lisp code to automate the process of adding,
moving,
> nesting and removing this style of comment.  Then I stopped using emacs
and
> just did it manually.  No hassle, really.
>
> Of course, this looks just dandy too:
>
> /++\
> |++|  Then again, on the plus side...
> |++|
> \++/
>
> We just need to make sure that a back-slash in comments has no special
meaning
> (a given in D).
>
>
> -BobC

This wouldn't be a problem if our keyboards had ÷ on them.  ;)

Walter, is # going to be used for anything in D?  No preprocessor anymore...

Sean


"Walter" <walter@digitalmars.com> wrote in message news:a3avoq$2m8s$1@digitaldaemon.com...
>
> "Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:a3at25$2jjj$1@digitaldaemon.com...
> > please note that  a = b/-c; is a valid C/C++ statement, and also a =
b/+c;
> > BTW, also *p = *q/*r; is a valid C/C++ statement...
>
> We've already learned to live with q/*r, so I don't think that b/+c will
be
> a problem, especially since there is no point to the + in +c.

I have no plans for #. -Walter

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a3b1sg$2na1$1@digitaldaemon.com...
> This wouldn't be a problem if our keyboards had ÷ on them.  ;)
>
> Walter, is # going to be used for anything in D?  No preprocessor
anymore...
>
> Sean
>
>
> "Walter" <walter@digitalmars.com> wrote in message news:a3avoq$2m8s$1@digitaldaemon.com...
> >
> > "Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:a3at25$2jjj$1@digitaldaemon.com...
> > > please note that  a = b/-c; is a valid C/C++ statement, and also a =
> b/+c;
> > > BTW, also *p = *q/*r; is a valid C/C++ statement...
> >
> > We've already learned to live with q/*r, so I don't think that b/+c will
> be
> > a problem, especially since there is no point to the + in +c.
>
>
>

> BTW, also *p = *q/*r; is a valid C/C++ statement...

Are you sure ?

If so, then this should compile ok:

main( )
{
 char *p,*q,*r;
 *p = *q/*r;
}

but it does not, sc t.cpp gives:

t.cpp(8) : Lexical error: end of file found before end of comment, line 1 Fatal error: premature end of source file
--- errorlevel 1

If memory serves my write:

In C/C++
 pre-processing of the source is performed before any lexical analysis.
Since it is the pre-processor that replaces comments by white space the
following is not legal C/C++.

If my memory is faulty then I ask forgiveness.

Martin


"Marc Cote" <cotemark@globetrotter.net> wrote in message news:a3bsie$1kte$1@digitaldaemon.com...
> > BTW, also *p = *q/*r; is a valid C/C++ statement...
>
> Are you sure ?
>
> If so, then this should compile ok:
>
> main( )
> {
>  char *p,*q,*r;
>  *p = *q/*r;
> }
>
> but it does not, sc t.cpp gives:
>
> t.cpp(8) : Lexical error: end of file found before end of comment, line 1 Fatal error: premature end of source file
> --- errorlevel 1
>
>
>

Actually, the rule is that "tokens are parsed as the longest possible token" or
some such.  That means that while "/*" could be parsed as 2 tokens, '/' and
'*', it instead is parsed as one token.  It's part of the C standard.
Otherwise we couldn't parse the expression
    c << 2
as the "<<" might be parsed as two '<' tokens.  This led to the classic C++
template error:
    Foo<Bar<Baz>>
which had to be re-written as:
    Foo<Bar<Baz> >
to avoid confusing the compiler.

In C, you must use spaces to separate some combinations of operators.  I think that what Walter meant was that the expression is "conceptually right", but, as you found out, it is a syntax error.

--
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))) ]

I thought of the comment about is being a valid stament was to point out
that ' *p      /       *r' is valid
and *p/*r looks the same but is in fact *p/<comment-start>
and that's been there for years, and no one complained.
so just 'cos /+s is valid does not full discount /+ +/ as nested comment

or is it just that a very similar example was in the pclint advert in DrDobbs last year

"Marc Cote" <cotemark@globetrotter.net> wrote in message news:a3bsie$1kte$1@digitaldaemon.com...
> > BTW, also *p = *q/*r; is a valid C/C++ statement...
>
> Are you sure ?
>
> If so, then this should compile ok:
>
> main( )
> {
>  char *p,*q,*r;
>  *p = *q/*r;
> }
>
> but it does not, sc t.cpp gives:
>
> t.cpp(8) : Lexical error: end of file found before end of comment, line 1 Fatal error: premature end of source file
> --- errorlevel 1
>
>
>