Is there a class name macro?

[tony_in_da_uk@yahoo.co.uk]

Re: Is there a class name macro?

On Sep 17, 10:06 am, tony_in_da...@y ahoo.co.uk wrote:

On Sep 16, 10:22 am, Peng Yu <PengYu...@gmai l.comwrote:

__PRETTY_FUNCTI ON__ is a macro that gives function name, etc. I'm
wondering if there is a macro to get the class name inside a member
function.

>
Your question almost answers itself. Just do a little parsing on the
__PRETTY_FUNCTI ON__ string to extract the class name. From quick
thought, I can't see any issue with scanning for '(' then working
backwards to "::" then taking the preceding identifier. You've got it
easy, as the types are already resolved for you - raw source code can
have templated types being instantiated with arbitrary expressions
also containing "(" etc..

std::string less_pretty(con st char pretty_func[])
{
const char* p = strrchr(pretty_ func, '(');
BOOTSTRAP_ASSER T(p);
const char* end = p;
while (p[-1] != ':' && p[-1] != ' ')
--p;
BOOTSTRAP_ASSER T(p pretty_func); // should always be space after
type...
const char* fn_name = p;
if (p[-1] == ':')
{
p -= 2;
BOOTSTRAP_ASSER T(p pretty_func && *p == ':');
while (p pretty_func && (isalnum(p[-1]) || p[-1] == '_'))
--p;
// simplify constructors "idn::idn() " back to idn()...
if (strncmp(p, fn_name, fn_name - p - sizeof(" ")) == 0)
p = fn_name;
}
// std::cerr << "less_prett y('" << pretty_func << "') return '"
// << std::string(p, end - p) << "'\n";
return std::string(p, end - p);
}

[Jorgen Grahn]

Re: Is there a class name macro?

On Tue, 16 Sep 2008 07:28:42 -0700 (PDT), James Kanze <james.kanze@gm ail.comwrote:

On Sep 16, 2:31 pm, Jorgen Grahn <grahn+n...@sni pabacken.sewrot e:

....

>I have used __func__ as a C++ extension in g++, but I forget
>exactly how they chose to do it. It's in the documentation
>though.

>
They just output the simple function name.

Yes, you're right. Strange when you think of it -- you can have lots
of operator< (), set() and so on in even a medium-sized program.

The real question is what it is to be used for. What you want
to output depends on that, more than anything else. If it is
for logging messages, I'm not sure what is best. To find the
actual function, you need the fully qualified name, and even
that causes problems for anything in anonymous namespaces, or
member functions of local classes. And what about static
functions.

Surely the purpose is log/trace messages, assertions and so on. I can
see no other reason to have it, especially since it's
implementation-defined.

If the goal of putting it in a log file is to be able to find
the place in the source code later, a better solution is to use
__FILE__, __LINE__ and the version number inserted by your
version control system.

And version number isn't needed if you have some out-of-band way of
knowing what version produced the message, and finding the source code
for that version.

I have to say that for me, __func__ *is* useful.

I have used "date time: file:line function(): ..." a lot for log/trace
messages in one application. File and line is enough to find the
source code, but the function name gives context to the message you
are printing, so that the message itself can be more brief.

I have also been hacking code which used function names in trace
messages, but didn't use __func__. It's painful -- it gets in the way
when reading the code because function names appear in the strings
(false positives when you search or grep). Also, you can bet money
that some of the strings are incorrect due to cut & paste errors.

/Jorgen

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.se R'lyeh wgah'nagl fhtagn!

[Chris Gordon-Smith]

Re: Is there a class name macro?

James Kanze wrote:

The real question is what it is to be used for.

>

>I'll probably use it in my trace utility. In most cases I put
>classes in files with the name of the class, so using __FILE__
>__func__ and __LINE__ will put an entry in my trace file that
>indicates (in the majority of cases) the class and the
>function.

>
If you have the line number, and can find the source file, then
the filename and line number should indicate unambiguously which
class and which function the trace was in.
>
Finding the correct source file can be a bit tricky. That's why
I suggested adding some versioning information somewhere. (The
other alternative is to put the versioning information in static
C style strings in the file, and use something like "strings" to
read it from the executable, when needed.)
>

I don't get your point. Can you explain?
I always trace the latest version of my program and the trace output will
include the filename, so why is finding the source file a bit tricky?

And why is versioning information needed, and what would that information
be?

>For the cases where the class does not have the same name as
>the file, or cases where a function is overloaded, the
>__LINE__ will resolve the ambiguity.

>

>My code will be simpler, because instead of putting:-

>

>TRACE(ClassNam e::FunctionName );

>

>at the start of each function, I'll just put:-

>

>TRACE;

>
Exactly. Generally, I think that there's such a thing as being
too succinct. But in the case of tracing, the easier it is to
use, the more it will be used. And that's what you want.
>

Yes, code must be easy to understand. My take on it would be that succinct
code is OK so long as it does not become cryptic and impenetrable.

Chris Gordn-Smith

https://www.simsoup.info

[James Kanze]

Re: Is there a class name macro?

On Sep 17, 11:29 pm, Chris Gordon-Smith <use.addr...@my .homepage>
wrote:

James Kanze wrote:

The real question is what it is to be used for.

I'll probably use it in my trace utility. In most cases I put
classes in files with the name of the class, so using __FILE__
__func__ and __LINE__ will put an entry in my trace file that
indicates (in the majority of cases) the class and the
function.

If you have the line number, and can find the source file, then
the filename and line number should indicate unambiguously which
class and which function the trace was in.

Finding the correct source file can be a bit tricky. That's why
I suggested adding some versioning information somewhere. (The
other alternative is to put the versioning information in static
C style strings in the file, and use something like "strings" to
read it from the executable, when needed.)

I don't get your point. Can you explain?

As soon as you have two or more instances of the program,
fatally, sooner or later, you'll run into the problem of
different versions. And to exploit filename/line number, you
need to know the version of the file which created the trace.
I've almost always seen this in the form of static variables in
the code, and I've almost always had issues finding out which
executable generated the trace, and getting a copy of it, so
that I could know which version of the program generated the
trace. When all is said and done, it's probably a good idea to
add this information to the trace automatically. (And having
the trace macro refer to it ensures that it will be there; all
too often, I've found it missing completely, and you just have
to guess.)

I always trace the latest version of my program and the trace
output will include the filename, so why is finding the source
file a bit tricky?

If there is only one instance of the program in existance at any
one time, there's no problem. In practice, however, this isn't
the case that often.

And why is versioning information needed, and what would that
information be?

For the cases where the class does not have the same name
as the file, or cases where a function is overloaded, the
__LINE__ will resolve the ambiguity.

My code will be simpler, because instead of putting:-

TRACE(ClassName ::FunctionName) ;

at the start of each function, I'll just put:-

TRACE;

Exactly. Generally, I think that there's such a thing as
being too succinct. But in the case of tracing, the easier
it is to use, the more it will be used. And that's what you
want.

Yes, code must be easy to understand. My take on it would be
that succinct code is OK so long as it does not become cryptic
and impenetrable.

Succinctness is, in itself, a quality. Good code should be
clear and concise. Generally speaking, however, using macros to
make code more succinct, and especially using a macro to hide a
function call, costs too much clarity to be considered. Tracing
is, IMHO, a special case, however: it's not part of the program
logic, and you really have to make it as easy to use as
possible, so that it will be used. (And of course, you want to
invoke it via a macro anyway, so that you can automatically
insert __FILE__ and __LINE__.)

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[Chris Gordon-Smith]

Re: Is there a class name macro?

James Kanze wrote:

On Sep 17, 11:29 pm, Chris Gordon-Smith <use.addr...@my .homepage>
wrote:

>James Kanze wrote:

The real question is what it is to be used for.

>

>I'll probably use it in my trace utility. In most cases I put
>classes in files with the name of the class, so using __FILE__
>__func__ and __LINE__ will put an entry in my trace file that
>indicates (in the majority of cases) the class and the
>function.

>

If you have the line number, and can find the source file, then
the filename and line number should indicate unambiguously which
class and which function the trace was in.

>

Finding the correct source file can be a bit tricky. That's why
I suggested adding some versioning information somewhere. (The
other alternative is to put the versioning information in static
C style strings in the file, and use something like "strings" to
read it from the executable, when needed.)

>

>I don't get your point. Can you explain?

>
As soon as you have two or more instances of the program,
fatally, sooner or later, you'll run into the problem of
different versions. And to exploit filename/line number, you
need to know the version of the file which created the trace.
I've almost always seen this in the form of static variables in
the code, and I've almost always had issues finding out which
executable generated the trace, and getting a copy of it, so
that I could know which version of the program generated the
trace. When all is said and done, it's probably a good idea to
add this information to the trace automatically. (And having
the trace macro refer to it ensures that it will be there; all
too often, I've found it missing completely, and you just have
to guess.)
>

OK - I see the point.

In my case things are a lot simpler. I'm doing a one person spare time
project so I don't have multiple program instances / parallel realease, and
I always know which execuatble generated trace output.

>I always trace the latest version of my program and the trace
>output will include the filename, so why is finding the source
>file a bit tricky?

>
If there is only one instance of the program in existance at any
one time, there's no problem. In practice, however, this isn't
the case that often.
>

>And why is versioning information needed, and what would that
>information be?

>

>For the cases where the class does not have the same name
>as the file, or cases where a function is overloaded, the
>__LINE__ will resolve the ambiguity.

>

>My code will be simpler, because instead of putting:-

>

>TRACE(ClassNam e::FunctionName );

>

>at the start of each function, I'll just put:-

>

>TRACE;

>

Exactly. Generally, I think that there's such a thing as
being too succinct. But in the case of tracing, the easier
it is to use, the more it will be used. And that's what you
want.

>

>Yes, code must be easy to understand. My take on it would be
>that succinct code is OK so long as it does not become cryptic
>and impenetrable.

>
Succinctness is, in itself, a quality. Good code should be
clear and concise.

Indeed.

Generally speaking, however, using macros to
make code more succinct, and especially using a macro to hide a
function call, costs too much clarity to be considered. Tracing
is, IMHO, a special case, however: it's not part of the program
logic, and you really have to make it as easy to use as
possible, so that it will be used. (And of course, you want to
invoke it via a macro anyway, so that you can automatically
insert __FILE__ and __LINE__.)
>

I agree that in this case using a macro is OK (I suppose I must since I've
done it!). Macros do need to be used sparingly, and its important to keep
them as simple as possible. My TRACE macro has a single line, and by
calling the macro just once at the start of a function I get an 'Enter
Function' trace line and a second 'Leave Function' line just before the
function returns.

Another advantage of using a macro is that I can (and do) conditionally
compile it, so that I can completely remove the Trace code (although I can
also control it programmaticall y). Conditional compilation should also be
used sparingly, and this is the only place I use it in what has now become
a substantial sized project.

Another place I use macros is to replace curly brackets. Eg

// Global include

#define THEN {
#define ELSEIF }else if
#define ELSE }else{
#define ENDIF }
// -----------------

Then I can write

if (condition)
THEN
// Do something
ELSE
// Do something else
ENDIF

This may be controversial, but I think it makes code clearer. My code
automatically documents where the various parts of the if statement are,
rather than leaving the reader to count brackets and look at indentation.

Chris Gordon-Smith

https://www.simsoup.info

[Jorgen Grahn]

Re: Is there a class name macro?

On Thu, 18 Sep 2008 21:13:35 +0100, Chris Gordon-Smith <use.address@my .homepagewrote:

James Kanze wrote:
>

>On Sep 17, 11:29 pm, Chris Gordon-Smith <use.addr...@my .homepage>
>wrote:

>>James Kanze wrote:

....

>Finding the correct source file can be a bit tricky. That's why
>I suggested adding some versioning information somewhere. (The
>other alternative is to put the versioning information in static
>C style strings in the file, and use something like "strings" to
>read it from the executable, when needed.)

>>

>>I don't get your point. Can you explain?

>>
>As soon as you have two or more instances of the program,
>fatally, sooner or later, you'll run into the problem of
>different versions. And to exploit filename/line number, you
>need to know the version of the file which created the trace.
>I've almost always seen this in the form of static variables in
>the code, and I've almost always had issues finding out which
>executable generated the trace, and getting a copy of it, so
>that I could know which version of the program generated the
>trace. When all is said and done, it's probably a good idea to
>add this information to the trace automatically. (And having
>the trace macro refer to it ensures that it will be there; all
>too often, I've found it missing completely, and you just have
>to guess.)
>>

OK - I see the point.
>
In my case things are a lot simpler. I'm doing a one person spare time
project so I don't have multiple program instances / parallel realease, and
I always know which execuatble generated trace output.
>

>>I always trace the latest version of my program and the trace
>>output will include the filename, so why is finding the source
>>file a bit tricky?

>>
>If there is only one instance of the program in existance at any
>one time, there's no problem. In practice, however, this isn't
>the case that often.

It depends a lot on who your customers are. Where I am right now, they
are fairly close, and I can make demands. I make a point of only
giving them releases which can be traced back to one version of the
source code, and they know (or can find out) which release they are
using. Come to think of it, it's printed first in the log file.

In that scenario, file and line is enough.

/Jorgen

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.se R'lyeh wgah'nagl fhtagn!

[James Kanze]

Re: Is there a class name macro?

On Sep 18, 10:13 pm, Chris Gordon-Smith <use.addr...@my .homepage>
wrote:

James Kanze wrote:

[...]

Another advantage of using a macro is that I can (and do)
conditionally compile it, so that I can completely remove the
Trace code (although I can also control it programmaticall y).
Conditional compilation should also be used sparingly, and
this is the only place I use it in what has now become a
substantial sized project.

I've provided for this possibility many times as well. I've
never had to use it, but often, it's a necessary argument to
sell tracing.

Another place I use macros is to replace curly brackets. Eg

// Global include

#define THEN {
#define ELSEIF }else if
#define ELSE }else{
#define ENDIF }
// -----------------

Then I can write

if (condition)
THEN
// Do something
ELSE
// Do something else
ENDIF

This may be controversial,

It's not controversial; it's proven bad practice. You've just
made your code unreadable by any other C++ programmer, and by
any other tool which doesn't to a full parse (syntax
highlighting and indenting by the editor, for example).

C++ has a defined syntax. I don't always like it either, but
that's the way it is. You can't really create a new language
with macros, and you don't really want to, since no one else
(and no tool) knows that language. For better or for worse, you
have to live with C++ as it is.

(Also, if you were doing it, the #defines would be:

#define IF if (
#define THEN ) {
#define ELSE } else {
#define ELSIF } else if (
#define END }

..)

but I think it makes code clearer. My code automatically
documents where the various parts of the if statement are,
rather than leaving the reader to count brackets and look at
indentation.

How is counting the brackets and looking at the indentation any
better than counting the THEN/ELSE and looking at the
indentation. My editor does the indentation automatically (as
do most, I think), which ensures that it is correct, and it's
doubtlessly the easiest thing to follow. (And of course, I
don't nest overly deep, so there's not that much to follow
anyway.)

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[James Kanze]

Re: Is there a class name macro?

On Sep 19, 9:12 am, Jorgen Grahn <grahn+n...@sni pabacken.sewrot e:

On Thu, 18 Sep 2008 21:13:35 +0100, Chris Gordon-Smith
<use.addr...@my .homepagewrote:

[...]

If there is only one instance of the program in existance
at any one time, there's no problem. In practice, however,
this isn't the case that often.

It depends a lot on who your customers are. Where I am right
now, they are fairly close, and I can make demands. I make a
point of only giving them releases which can be traced back to
one version of the source code, and they know (or can find
out) which release they are using. Come to think of it, it's
printed first in the log file.

In that scenario, file and line is enough.

If you're managing your sources correctly, that should be
enough. In practice, it depends on the organization, and more
than once, even knowing the version of the executable, I've had
difficulty determining which version of a specific source it
contained. In such cases, adding the version only adds a few
characters to the line header (which already contains the
filename, line number and a timestamp), and seems worth it. In
better run organizations, it's probably not worth the bother.

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[Chris Gordon-Smith]

Re: Is there a class name macro?

James Kanze wrote:

On Sep 18, 10:13 pm, Chris Gordon-Smith <use.addr...@my .homepage>
wrote:

>James Kanze wrote:

>
[...]

>Another advantage of using a macro is that I can (and do)
>conditionall y compile it, so that I can completely remove the
>Trace code (although I can also control it programmaticall y).
>Conditional compilation should also be used sparingly, and
>this is the only place I use it in what has now become a
>substantial sized project.

>
I've provided for this possibility many times as well. I've
never had to use it, but often, it's a necessary argument to
sell tracing.
>

>Another place I use macros is to replace curly brackets. Eg

>

>// Global include

>

>#define THEN {
>#define ELSEIF }else if
>#define ELSE }else{
>#define ENDIF }
>// -----------------

>

>Then I can write

>

>if (condition)
>THEN
>// Do something
>ELSE
>// Do something else
>ENDIF

>

>This may be controversial,

>
It's not controversial; it's proven bad practice. You've just
made your code unreadable by any other C++ programmer, and by
any other tool which doesn't to a full parse (syntax
highlighting and indenting by the editor, for example).

I think the main issue when picking up someone else's code is understanding
the overall application design, how it works, and all the other application
specific aspects. Finding your way around unfamiliar (but intuitive) syntax
is a small step compared to this.

Syntax highlighting works with my editor.

>
C++ has a defined syntax. I don't always like it either, but
that's the way it is. You can't really create a new language
with macros, and you don't really want to, since no one else
(and no tool) knows that language. For better or for worse, you
have to live with C++ as it is.

I haven't created a new language, but I have varied the syntax slightly. It
is working fine for me, and I don't have to live with the curly brackets
that annoy me. I do realise however that the approach I like may annoy
other people.

>
(Also, if you were doing it, the #defines would be:
>
#define IF if (
#define THEN ) {
#define ELSE } else {
#define ELSIF } else if (
#define END }
>
.)

The seem to be different ways of doing it. I don't have a #define for "if"
(that does seem to be unnecessary), and I have separate #defines for END
and ENDIF. That way I can distinguish between the end of an "if" statement
and the end of a "for" loop (for which I use END).

>

>but I think it makes code clearer. My code automatically
>documents where the various parts of the if statement are,
>rather than leaving the reader to count brackets and look at
>indentation.

>
How is counting the brackets and looking at the indentation any
better than counting the THEN/ELSE and looking at the
indentation.

There is less reliance on counting and checking indentation. Instead of
looking at a "}"curly bracket and wondering what kind of block it ends, I
see ENDIF and know immediately what it means.

My editor does the indentation automatically (as
do most, I think), which ensures that it is correct, and it's
doubtlessly the easiest thing to follow. (And of course, I
don't nest overly deep, so there's not that much to follow
anyway.)

I don't use automatic indentation. I tried it for a while with Emacs but
couldn't get it to indent the way I wanted.

Agree about the over-deep nesting.

Chris Gordon-Smith

https://www.simsoup.info

[Richard Herring]

Re: Is there a class name macro?

In message <6jifmvF3ht0bU1 @mid.individual .net>, Chris Gordon-Smith
<use.address@my .homepagewrites

>James Kanze wrote:
>

>On Sep 18, 10:13 pm, Chris Gordon-Smith <use.addr...@my .homepage>
>wrote:

>>#define THEN {

[etc]

>>

>>This may be controversial,

>>
>It's not controversial; it's proven bad practice. You've just
>made your code unreadable by any other C++ programmer, and by
>any other tool which doesn't to a full parse (syntax
>highlighting and indenting by the editor, for example).

>I think the main issue when picking up someone else's code is understanding
>the overall application design, how it works, and all the other application
>specific aspects. Finding your way around unfamiliar (but intuitive)

Intuitive? ...

>syntax
>is a small step compared to this.
>
>Syntax highlighting works with my editor.
>

>>
>C++ has a defined syntax. I don't always like it either, but
>that's the way it is. You can't really create a new language
>with macros, and you don't really want to, since no one else
>(and no tool) knows that language. For better or for worse, you
>have to live with C++ as it is.

>I haven't created a new language, but I have varied the syntax slightly. It
>is working fine for me, and I don't have to live with the curly brackets
>that annoy me. I do realise however that the approach I like may annoy
>other people.

Meiosis.

>>
>(Also, if you were doing it, the #defines would be:
>>
> #define IF if (
> #define THEN ) {
> #define ELSE } else {
> #define ELSIF } else if (
> #define END }
>>
>.)

>
>The seem to be different ways of doing it.

.... which implies that it's not intuitive, as claimed above.

I don't have a #define for "if"
>(that does seem to be unnecessary),

(and the other macros aren't?)

So you have a construct with a language keyword at the top and macros
elsewhere. Foolish consistency, at the very least, would dictate using
macros throughout if you must use then at all.

>and I have separate #defines for END
>and ENDIF. That way I can distinguish between the end of an "if" statement
>and the end of a "for" loop (for which I use END).

(why not ENDFOR?)
But can someone else who picks up your code and doesn't notice that
there are two macros for } ?

>>

>>but I think it makes code clearer. My code automatically
>>documents where the various parts of the if statement are,
>>rather than leaving the reader to count brackets and look at
>>indentation .

>>
>How is counting the brackets and looking at the indentation any
>better than counting the THEN/ELSE and looking at the
>indentation.

>There is less reliance on counting and checking indentation. Instead of
>looking at a "}"curly bracket and wondering what kind of block it ends,

The usual solution to that is to write, mutatis mutandis, something like
} // end if (condition)

>I
>see ENDIF and know immediately what it means.

Unless you (or someone else) typed the wrong macro :-(
The compiler won't provide any helpful error messages if you do.

>

>My editor does the indentation automatically (as
>do most, I think), which ensures that it is correct, and it's
>doubtlessly the easiest thing to follow. (And of course, I
>don't nest overly deep, so there's not that much to follow
>anyway.)

>
>I don't use automatic indentation. I tried it for a while with Emacs but
>couldn't get it to indent the way I wanted.
>
>Agree about the over-deep nesting.
>

--
Richard Herring

[James Kanze]

Re: Is there a class name macro?

On Sep 22, 10:54 am, Richard Herring <junk@[127.0.0.1]wrote:

In message <6jifmvF3ht0... @mid.individual .net>, Chris Gordon-Smith
<use.addr...@my .homepagewrites

James Kanze wrote:

On Sep 18, 10:13 pm, Chris Gordon-Smith <use.addr...@my .homepage>
wrote:
>#define THEN {

[etc]

(Also, if you were doing it, the #defines would be:

#define IF if (
#define THEN ) {
#define ELSE } else {
#define ELSIF } else if (
#define END }

.)

>

The seem to be different ways of doing it.

... which implies that it's not intuitive, as claimed above.

I don't have a #define for "if"
(that does seem to be unnecessary),

(and the other macros aren't?)

So you have a construct with a language keyword at the top and
macros elsewhere. Foolish consistency, at the very least,
would dictate using macros throughout if you must use then at
all.

Consistency would dictate that at the very least, if THEN and
ELSE are all caps, then IF should be as well. And probably all
of the other keywords, which means a few more macros.

IMHO, consistency would also dictate that if you aren't writing
C++, you conform to the use of some other language, which is why
my definitions of IF and THEN have the parentheses. Of course,
common sense would also dictate that if you want to write in
some other language, the obvious solution would be to use a
compiler for that language, and not to try to fool the C++
compiler (and your readers).

and I have separate #defines for END
and ENDIF. That way I can distinguish between the end of an "if" statement
and the end of a "for" loop (for which I use END).

(why not ENDFOR?)

And ENDWHILE. And ENDFUNCTION, and ENDCLASS. Let's do this
right:-).

But can someone else who picks up your code and doesn't notice
that there are two macros for } ?

And for {, I suppose. Otherwise:

for ( ... ) {
// ...
END

>but I think it makes code clearer. My code automatically
>documents where the various parts of the if statement are,
>rather than leaving the reader to count brackets and look at
>indentation.

How is counting the brackets and looking at the indentation
any better than counting the THEN/ELSE and looking at the
indentation.

There is less reliance on counting and checking indentation.
Instead of looking at a "}"curly bracket and wondering what
kind of block it ends,

The usual solution to that is to write, mutatis mutandis,
something like

} // end if (condition)

The one point I'd disagree with. The usual solution is to
write:
}
, correctly indented, and if the { is so far away that it isn't
evident, then to break the function up into smaller, more
manageable chunks.

I see ENDIF and know immediately what it means.

Unless you (or someone else) typed the wrong macro :-( The
compiler won't provide any helpful error messages if you do.

And of course, the casual reader won't know exactly what it
means.

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[Richard Herring]

Re: Is there a class name macro?

In message
<01ace80e-0796-4750-9966-8b0dd24cdddb@e5 3g2000hsa.googl egroups.com>,
James Kanze <james.kanze@gm ail.comwrites

>On Sep 22, 10:54 am, Richard Herring <junk@[127.0.0.1]wrote:

>In message <6jifmvF3ht0... @mid.individual .net>, Chris Gordon-Smith
><use.addr...@m y.homepagewrite s

>

>James Kanze wrote:

>

>On Sep 18, 10:13 pm, Chris Gordon-Smith <use.addr...@my .homepage>
>wrote:
>>#define THEN {

>

>[etc]

>(Also, if you were doing it, the #defines would be:

>

> #define IF if (
> #define THEN ) {
> #define ELSE } else {
> #define ELSIF } else if (
> #define END }

>

>.)

>>

>The seem to be different ways of doing it.

>

>... which implies that it's not intuitive, as claimed above.

>

I don't have a #define for "if"
>(that does seem to be unnecessary),

>

>(and the other macros aren't?)

>

>So you have a construct with a language keyword at the top and
>macros elsewhere. Foolish consistency, at the very least,
>would dictate using macros throughout if you must use then at
>all.

>
>Consistency would dictate that at the very least, if THEN and
>ELSE are all caps, then IF should be as well. And probably all
>of the other keywords, which means a few more macros.
>
>IMHO, consistency would also dictate that if you aren't writing
>C++, you conform to the use of some other language, which is why
>my definitions of IF and THEN have the parentheses. Of course,
>common sense would also dictate that if you want to write in
>some other language, the obvious solution would be to use a
>compiler for that language, and not to try to fool the C++
>compiler (and your readers).
>

>and I have separate #defines for END
>and ENDIF. That way I can distinguish between the end of an "if" statement
>and the end of a "for" loop (for which I use END).

>

>(why not ENDFOR?)

>
>And ENDWHILE. And ENDFUNCTION, and ENDCLASS. Let's do this
>right:-).
>

>But can someone else who picks up your code and doesn't notice
>that there are two macros for } ?

>
>And for {, I suppose. Otherwise:
>
for ( ... ) {
// ...
END
>

>>but I think it makes code clearer. My code automatically
>>documents where the various parts of the if statement are,
>>rather than leaving the reader to count brackets and look at
>>indentation .

>

>How is counting the brackets and looking at the indentation
>any better than counting the THEN/ELSE and looking at the
>indentation.
>There is less reliance on counting and checking indentation.
>Instead of looking at a "}"curly bracket and wondering what
>kind of block it ends,

>

>The usual solution to that is to write, mutatis mutandis,
>something like

>

>} // end if (condition)

>
>The one point I'd disagree with. The usual solution is to
>write:
}
>, correctly indented, and if the { is so far away that it isn't
>evident, then to break the function up into smaller, more
>manageable chunks.

I suspect I write more multidimensiona l numerical code than you do.
Sometimes the "most manageable chunk" is unavoidably several levels deep
in nested loops, and splitting it into separate functions would actually
obscure the structure of the algorithm.

Besides, in the OP's case:

>>>I don't use automatic indentation. I tried it for a while with Emacs
>>>but couldn't get it to indent the way I wanted.

;-/

--
Richard Herring

[Hendrik Schober]

Re: Is there a class name macro?

Richard Herring wrote:

In message
<01ace80e-0796-4750-9966-8b0dd24cdddb@e5 3g2000hsa.googl egroups.com>,
James Kanze <james.kanze@gm ail.comwrites

>[...]
>The one point I'd disagree with. The usual solution is to
>write:
> }
>, correctly indented, and if the { is so far away that it isn't
>evident, then to break the function up into smaller, more
>manageable chunks.

>
I suspect I write more multidimensiona l numerical code than you do.
Sometimes the "most manageable chunk" is unavoidably several levels deep
in nested loops, and splitting it into separate functions would actually
obscure the structure of the algorithm.

I have never seen an algorithm that wouldn't benefit from
giving parts of them names and calling it by those. Would
you care to give an example?

Schobi

[Chris Gordon-Smith]

Re: Is there a class name macro?

Richard Herring wrote:

In message
<01ace80e-0796-4750-9966-8b0dd24cdddb@e5 3g2000hsa.googl egroups.com>,
James Kanze <james.kanze@gm ail.comwrites

>>On Sep 22, 10:54 am, Richard Herring <junk@[127.0.0.1]wrote:

>>In message <6jifmvF3ht0... @mid.individual .net>, Chris Gordon-Smith
>><use.addr...@ my.homepagewrit es

>>

>>James Kanze wrote:

>>

>>On Sep 18, 10:13 pm, Chris Gordon-Smith <use.addr...@my .homepage>
>>wrote:
>>>#define THEN {

>>

>>[etc]
>>(Also, if you were doing it, the #defines would be:

>>

>> #define IF if (
>> #define THEN ) {
>> #define ELSE } else {
>> #define ELSIF } else if (
>> #define END }

>>

>>.)
>>>
>>The seem to be different ways of doing it.

>>

>>... which implies that it's not intuitive, as claimed above.

Its the syntax that is intuitive, not necessarily the macros used to enable
it.

>>

>I don't have a #define for "if"
>>(that does seem to be unnecessary),

>>

>>(and the other macros aren't?)

>>

>>So you have a construct with a language keyword at the top and
>>macros elsewhere. Foolish consistency, at the very least,
>>would dictate using macros throughout if you must use then at
>>all.

I use the macros to make the code more readable to me. I find that
replacing "}" with "ENDIF" helps understanding. Replacing "if" with "IF"
would not help understanding. It would have the disadvantage of removing
syntax highlighting with no compensating advantage.

>>
>>Consistency would dictate that at the very least, if THEN and
>>ELSE are all caps, then IF should be as well. And probably all
>>of the other keywords, which means a few more macros.
>>
>>IMHO, consistency would also dictate that if you aren't writing
>>C++, you conform to the use of some other language, which is why
>>my definitions of IF and THEN have the parentheses.

The code compiles, so strictly speakig I think it must be C++, albeit with
somewhat unusual usage.

>>Of course,
>>common sense would also dictate that if you want to write in
>>some other language, the obvious solution would be to use a
>>compiler for that language, and not to try to fool the C++
>>compiler (and your readers).
>>

>>and I have separate #defines for END
>>and ENDIF. That way I can distinguish between the end of an "if"
>>statement and the end of a "for" loop (for which I use END).

>>

>>(why not ENDFOR?)

>>
>>And ENDWHILE. And ENDFUNCTION, and ENDCLASS. Let's do this
>>right:-).
>>

>>But can someone else who picks up your code and doesn't notice
>>that there are two macros for } ?

I think they would very soon work it out.

>>
>>And for {, I suppose. Otherwise:
>>
> for ( ... ) {
> // ...
> END
>>

>>>but I think it makes code clearer. My code automatically
>>>documents where the various parts of the if statement are,
>>>rather than leaving the reader to count brackets and look at
>>>indentatio n.

>>

>>How is counting the brackets and looking at the indentation
>>any better than counting the THEN/ELSE and looking at the
>>indentation .
>>There is less reliance on counting and checking indentation.
>>Instead of looking at a "}"curly bracket and wondering what
>>kind of block it ends,

>>

>>The usual solution to that is to write, mutatis mutandis,
>>something like

>>

>>} // end if (condition)

Where possible, I prefer to write code that documents itself rather than
write a comment.

>>
>>The one point I'd disagree with. The usual solution is to
>>write:
> }
>>, correctly indented, and if the { is so far away that it isn't
>>evident, then to break the function up into smaller, more
>>manageable chunks.

>
I suspect I write more multidimensiona l numerical code than you do.
Sometimes the "most manageable chunk" is unavoidably several levels deep
in nested loops, and splitting it into separate functions would actually
obscure the structure of the algorithm.
>
Besides, in the OP's case:
>

>>>>I don't use automatic indentation. I tried it for a while with Emacs
>>>>but couldn't get it to indent the way I wanted.

>
;-/
>

I'll make a couple of other points on this overall discussion.

1) Personal Project Taste

This is an approach I have chosen to adopt for a particular project. It is
used consistently throughout the project.

I see it as a matter of personal taste, not as an issue of fundamental
importance that anyone should take an entrenched position over.

This is in contrast with principles such as good use of modularisation,
information hiding, minimising dependencies, appropriate use of inheritance
and polymorphism. These are issues that "really matter", and over which it
is worth arguing to get the approach right.

I am reminded of the item "Don't Sweat The Small Stuff" in Sutter and
Alexandrescu's C++ Coding Standards.

2) Tolerance for Different Approaches

I started re-reading Stroustrup's "The Design and Evolution of C++" over the
weekend. Here is a quote from section 1.3 (General Background):-

"Often when I was tempted to outlaw a feature I personally disliked, I
refrained from doing so because I did not think I had the right to force my
views on others. ..... A high degree of tolerance and acceptance that
different people think in different ways and strongly prefer to do things
differently is to me far preferable"

I think this is a good general principle, particularly in a case such as
this which is a matter of taste rather than one of fundamental importance.

Chris Gordon-Smith

https://www.simsoup.info

[Richard Herring]

Re: Is there a class name macro?

In message <gb8phn$1f1$2@c b.generation-online.de>, Hendrik Schober
<spamtrap@gmx.d ewrites

>Richard Herring wrote:

>In message <01ace80e-0796-4750-9966-8b0dd24cdddb@e5 3g2000hsa.googl eg
>>roups.com>, James Kanze <james.kanze@gm ail.comwrites

>>[...] The one point I'd disagree with. The usual solution is to
>>write:
>> }
>>, correctly indented, and if the { is so far away that it isn't
>>evident, then to break the function up into smaller, more
>>manageable chunks.

> I suspect I write more multidimensiona l numerical code than you do.
>>Sometimes the "most manageable chunk" is unavoidably several levels
>>deep in nested loops, and splitting it into separate functions would
>>actually obscure the structure of the algorithm.

>
I have never seen an algorithm that wouldn't benefit from
giving parts of them names and calling it by those.

Only if a meaningful name for the part is shorter than the code it
contains ;-)

>Would
you care to give an example?

Just look at FFT or matrix inversion code, or something similar. Here's
a fragment taken from a simple one-dimensional FFT:

int j = 0;
for (int i = 0; i<n; ++i)
{
if (j>i)
{
for (int k=0; k<span; ++k)
{
swap(a[span*i+k], a[span*j+k]);
}
}
int m = n/2;
while (m>=2 && j>=m)
{
j -= m;
m /= 2;
}
j += m;
}

--
Richard Herring