Define a larger code block

Hi,

As I can define something like

#define ABC(x) if(x){x = NULL;}

but how can I define something similar but the code block is relatively
large (like several lines testing different cases, etc)?

Thanks,
Alan

Brian
Fri Jul 20 17:36:21 CDT 2007

Use "\" as a continuation marker, as in

#define ABC(x) if(x) \
{ \
x = NULL; \
}

(Sorry if they don't line up right. My editor is display as "Arial")

Brian

Alan
Fri Jul 20 17:50:01 CDT 2007

Thank you!

"Brian Muth" wrote:

> Use "\" as a continuation marker, as in
>
> #define ABC(x) if(x) \
> { \
> x = NULL; \
> }
>
> (Sorry if they don't line up right. My editor is display as "Arial")
>
> Brian
>
>
>

Doug
Fri Jul 20 19:21:08 CDT 2007

On Fri, 20 Jul 2007 15:18:02 -0700, Alan <Alan@discussions.microsoft.com>
wrote:

>Hi,
>
>As I can define something like
>
>#define ABC(x) if(x){x = NULL;}
>
>but how can I define something similar but the code block is relatively
>large (like several lines testing different cases, etc)?
>
>Thanks,
>Alan

FWIW, in C++, you should almost always write inline functions instead of
macros.

--
Doug Harrison
Visual C++ MVP

Tom
Sat Jul 21 00:35:11 CDT 2007

Hi Doug,

You're right in general of course, but I still think macros are handy for
lots of things like:

#define LogCriticalEvent(val) theApp.LogEventObject._LogEvent(#val, val,
_T(__FUNCTION__), __LINE__, 0, true)

Where this would be more difficult to do in a function. I kind of miss
being able to do this sort of thing when writing C# code :o)

Tom

"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:16k2a3hojomr6k9q9g79mfjchh9joll1p5@4ax.com...
> On Fri, 20 Jul 2007 15:18:02 -0700, Alan <Alan@discussions.microsoft.com>
> wrote:
>
>>Hi,
>>
>>As I can define something like
>>
>>#define ABC(x) if(x){x = NULL;}
>>
>>but how can I define something similar but the code block is relatively
>>large (like several lines testing different cases, etc)?
>>
>>Thanks,
>>Alan
>
> FWIW, in C++, you should almost always write inline functions instead of
> macros.
>
> --
> Doug Harrison
> Visual C++ MVP

Doug
Sat Jul 21 13:23:03 CDT 2007

On Fri, 20 Jul 2007 22:35:11 -0700, "Tom Serface"
<tom.nospam@camaswood.com> wrote:

>Hi Doug,
>
>You're right in general of course, but I still think macros are handy for
>lots of things like:
>
> #define LogCriticalEvent(val) theApp.LogEventObject._LogEvent(#val, val,
>_T(__FUNCTION__), __LINE__, 0, true)
>
>Where this would be more difficult to do in a function.

Sure, you have to use macros for that. I guess it would be more accurate to
say that when you have a choice, inline functions are preferable to macros.

>I kind of miss
>being able to do this sort of thing when writing C# code :o)

C#, what's that? :)

--
Doug Harrison
Visual C++ MVP

Alex
Sat Jul 21 13:39:06 CDT 2007

"Doug Harrison [MVP]" wrote:
>
> C#, what's that? :)

They say it has something to do with a music. Go figure.
:)

Tom
Sun Jul 22 01:03:25 CDT 2007

Unfortunately, although it's kind of fun so far, I'm on an ASP.NET project
and it was C# or VB and I chose C#. So now I'm writing full time C++ and
the other full time C#/ASP.NET. It's kind of hard to keep it all straight,
but I'm seeing more benefit to the shared IDE concept now.

Tom

"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:khj4a35l53o5qt0u6op7erj3b7cf3oup3r@4ax.com...

> C#, what's that? :)

Tom
Sun Jul 22 01:04:38 CDT 2007

BTW, I agree that inline functions are a much better choice than writing
"functions" using macros so we're actually agreeing even though I'm sort of
doing it in my usual obtuse way :o)

Tom

"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:khj4a35l53o5qt0u6op7erj3b7cf3oup3r@4ax.com...
> On Fri, 20 Jul 2007 22:35:11 -0700, "Tom Serface"
> <tom.nospam@camaswood.com> wrote:
>
>>Hi Doug,
>>
>>You're right in general of course, but I still think macros are handy for
>>lots of things like:
>>
>> #define LogCriticalEvent(val) theApp.LogEventObject._LogEvent(#val, val,
>>_T(__FUNCTION__), __LINE__, 0, true)
>>
>>Where this would be more difficult to do in a function.
>
> Sure, you have to use macros for that. I guess it would be more accurate
> to
> say that when you have a choice, inline functions are preferable to
> macros.
>
>>I kind of miss
>>being able to do this sort of thing when writing C# code :o)
>
> C#, what's that? :)
>
> --
> Doug Harrison
> Visual C++ MVP

Ben
Sat Jul 21 09:02:03 CDT 2007


"Tom Serface" <tom.nospam@camaswood.com> wrote in message
news:DB8275F0-3EFA-48D2-9C44-C70D4CD8A69C@microsoft.com...
> Hi Doug,
>
> You're right in general of course, but I still think macros are handy for
> lots of things like:
>
> #define LogCriticalEvent(val) theApp.LogEventObject._LogEvent(#val, val,

Sees user identifier starting with underscore+capital and shudders...

> _T(__FUNCTION__), __LINE__, 0, true)
>
> Where this would be more difficult to do in a function. I kind of miss
> being able to do this sort of thing when writing C# code :o)
>
> Tom
>
> "Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
> news:16k2a3hojomr6k9q9g79mfjchh9joll1p5@4ax.com...
>> On Fri, 20 Jul 2007 15:18:02 -0700, Alan <Alan@discussions.microsoft.com>
>> wrote:
>>
>>>Hi,
>>>
>>>As I can define something like
>>>
>>>#define ABC(x) if(x){x = NULL;}
>>>
>>>but how can I define something similar but the code block is relatively
>>>large (like several lines testing different cases, etc)?
>>>
>>>Thanks,
>>>Alan
>>
>> FWIW, in C++, you should almost always write inline functions instead of
>> macros.
>>
>> --
>> Doug Harrison
>> Visual C++ MVP
>

Jim
Mon Jul 23 00:31:46 CDT 2007

"Ben Voigt [C++ MVP]" <rbv@nospam.nospam> wrote in message
news:A1B08482-949F-4697-8843-600CE9DBDB41@microsoft.com...
>
> "Tom Serface" <tom.nospam@camaswood.com> wrote in message
> news:DB8275F0-3EFA-48D2-9C44-C70D4CD8A69C@microsoft.com...
>> Hi Doug,
>>
>> You're right in general of course, but I still think macros are handy for
>> lots of things like:
>>
>> #define LogCriticalEvent(val) theApp.LogEventObject._LogEvent(#val, val,
>
> Sees user identifier starting with underscore+capital and shudders...
>
>> _T(__FUNCTION__), __LINE__, 0, true)

Actually, those are Windows define functions. _T is a define defined in
some windows header as is __FUNCTION__ and __LINE__
None of his defines/functions/macros are declaring variables with leading
underscores, he's just using library ones.


>>
>> Where this would be more difficult to do in a function. I kind of miss
>> being able to do this sort of thing when writing C# code :o)
>>
>> Tom
>>
>> "Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
>> news:16k2a3hojomr6k9q9g79mfjchh9joll1p5@4ax.com...
>>> On Fri, 20 Jul 2007 15:18:02 -0700, Alan
>>> <Alan@discussions.microsoft.com>
>>> wrote:
>>>
>>>>Hi,
>>>>
>>>>As I can define something like
>>>>
>>>>#define ABC(x) if(x){x = NULL;}
>>>>
>>>>but how can I define something similar but the code block is relatively
>>>>large (like several lines testing different cases, etc)?
>>>>
>>>>Thanks,
>>>>Alan
>>>
>>> FWIW, in C++, you should almost always write inline functions instead of
>>> macros.
>>>
>>> --
>>> Doug Harrison
>>> Visual C++ MVP
>>
>

Tom
Mon Jul 23 08:03:42 CDT 2007

Yeah, it's a handy set of macros I use for writing log files. I can do
something like LogEvent(CString cs = _T("This is a test")); and it will
write CString cs = _T("This is a test") to my log and do the assignment. I
could never figure out how to do it with inline code and get the same
effect.

Tom

"Jim Langston" <tazmaster@rocketmail.com> wrote in message
news:63Xoi.58$QR4.9@newsfe05.lga...

> Actually, those are Windows define functions. _T is a define defined in
> some windows header as is __FUNCTION__ and __LINE__
> None of his defines/functions/macros are declaring variables with leading
> underscores, he's just using library ones.

Ben
Mon Jul 23 10:43:34 CDT 2007


"Jim Langston" <tazmaster@rocketmail.com> wrote in message
news:63Xoi.58$QR4.9@newsfe05.lga...
> "Ben Voigt [C++ MVP]" <rbv@nospam.nospam> wrote in message
> news:A1B08482-949F-4697-8843-600CE9DBDB41@microsoft.com...
>>
>> "Tom Serface" <tom.nospam@camaswood.com> wrote in message
>> news:DB8275F0-3EFA-48D2-9C44-C70D4CD8A69C@microsoft.com...
>>> Hi Doug,
>>>
>>> You're right in general of course, but I still think macros are handy
>>> for lots of things like:
>>>
>>> #define LogCriticalEvent(val) theApp.LogEventObject._LogEvent(#val, val,
>>
>> Sees user identifier starting with underscore+capital and shudders...
>>
>>> _T(__FUNCTION__), __LINE__, 0, true)
>
> Actually, those are Windows define functions. _T is a define defined in
> some windows header as is __FUNCTION__ and __LINE__
> None of his defines/functions/macros are declaring variables with leading
> underscores, he's just using library ones.

__FUNCTION__ and __LINE__ are provided by a C++ standard compliant compiler,
not by Windows header files.

"_LogEvent", however, is not. It is a user-identifier beginning with
underscore+capital which is reserved. For example, it is permitted for
Microsoft to #define _LogEvent to something else in any of their headers
files in a future version, which would break the code.

That's why my comment immediately followed the use of "_LogEvent". Why you
associated it with other lines of code which followed my statement I do not
know.

Tom
Mon Jul 23 13:15:21 CDT 2007

Hi Ben,

I didn't know that was "reserved". It compiles OK. I just named it that
because the actual functions in the object are named that as well and ... oh
well. It's only in my code so not harming anyone else.

Tom

"Ben Voigt [C++ MVP]" <rbv@nospam.nospam> wrote in message
news:%23fgFcBUzHHA.4004@TK2MSFTNGP05.phx.gbl...

>
> __FUNCTION__ and __LINE__ are provided by a C++ standard compliant
> compiler, not by Windows header files.
>
> "_LogEvent", however, is not. It is a user-identifier beginning with
> underscore+capital which is reserved. For example, it is permitted for
> Microsoft to #define _LogEvent to something else in any of their headers
> files in a future version, which would break the code.
>
> That's why my comment immediately followed the use of "_LogEvent". Why
> you associated it with other lines of code which followed my statement I
> do not know.
>

Alexander
Mon Jul 23 13:38:58 CDT 2007

In reality, nothing prevents mixing the two. The macro can simply
call a function after all, or perform a simple if and call different
functions as the case may be. More complex macros usually do
more harm than good...

Also note, if you are optimizing for size than for speed, using
inline functions can be optimized by disabling inline expansion,
but using inline code via macros can't.

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@mvps.org
MVP VC FAQ: http://vcfaq.mvps.org
=====================================

"Tom Serface" <tom.nospam@camaswood.com> wrote in message
news:A80EA6FD-D557-4C1A-9064-CD36D95AE99B@microsoft.com...
> BTW, I agree that inline functions are a much better choice than writing
> "functions" using macros so we're actually agreeing even though I'm sort
> of doing it in my usual obtuse way :o)
>
> Tom
>
> "Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
> news:khj4a35l53o5qt0u6op7erj3b7cf3oup3r@4ax.com...
>> On Fri, 20 Jul 2007 22:35:11 -0700, "Tom Serface"
>> <tom.nospam@camaswood.com> wrote:
>>
>>>Hi Doug,
>>>
>>>You're right in general of course, but I still think macros are handy for
>>>lots of things like:
>>>
>>> #define LogCriticalEvent(val) theApp.LogEventObject._LogEvent(#val, val,
>>>_T(__FUNCTION__), __LINE__, 0, true)
>>>
>>>Where this would be more difficult to do in a function.
>>
>> Sure, you have to use macros for that. I guess it would be more accurate
>> to
>> say that when you have a choice, inline functions are preferable to
>> macros.
>>
>>>I kind of miss
>>>being able to do this sort of thing when writing C# code :o)
>>
>> C#, what's that? :)
>>
>> --
>> Doug Harrison
>> Visual C++ MVP
>

Ben
Mon Jul 23 13:40:11 CDT 2007


"Tom Serface" <tom.nospam@camaswood.com> wrote in message
news:B0C999E5-17F5-49A3-ADFC-CD61377B40EB@microsoft.com...
> Hi Ben,
>
> I didn't know that was "reserved". It compiles OK. I just named it that
> because the actual functions in the object are named that as well and ...
> oh well. It's only in my code so not harming anyone else.

... until the next Windows SDK comes out with a line like:

#define _LogEvent _EventList[4]

http://msdn2.microsoft.com/en-us/library/565w213d(vs.80).aspx

"Use of two sequential underscore characters ( __ ) at the beginning of an
identifier, or a single leading underscore followed by a capital letter, is
reserved for C++ implementations in all scopes."

http://www.noncombatant.org/trove/c-reserved-identifiers.html#Groups

>
> Tom
>
> "Ben Voigt [C++ MVP]" <rbv@nospam.nospam> wrote in message
> news:%23fgFcBUzHHA.4004@TK2MSFTNGP05.phx.gbl...
>
>>
>> __FUNCTION__ and __LINE__ are provided by a C++ standard compliant
>> compiler, not by Windows header files.
>>
>> "_LogEvent", however, is not. It is a user-identifier beginning with
>> underscore+capital which is reserved. For example, it is permitted for
>> Microsoft to #define _LogEvent to something else in any of their headers
>> files in a future version, which would break the code.
>>
>> That's why my comment immediately followed the use of "_LogEvent". Why
>> you associated it with other lines of code which followed my statement I
>> do not know.
>>
>

Doug
Mon Jul 23 13:50:21 CDT 2007

On Mon, 23 Jul 2007 13:40:11 -0500, "Ben Voigt [C++ MVP]"
<rbv@nospam.nospam> wrote:

>http://msdn2.microsoft.com/en-us/library/565w213d(vs.80).aspx
>
>"Use of two sequential underscore characters ( __ ) at the beginning of an
>identifier, or a single leading underscore followed by a capital letter, is
>reserved for C++ implementations in all scopes."

s/at the beginning of an/in an/


--
Doug Harrison
Visual C++ MVP

Ben
Mon Jul 23 17:26:34 CDT 2007


"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:5pt9a39c6h0ngdug17tu6hrbiongh034e9@4ax.com...
> On Mon, 23 Jul 2007 13:40:11 -0500, "Ben Voigt [C++ MVP]"
> <rbv@nospam.nospam> wrote:
>
>>http://msdn2.microsoft.com/en-us/library/565w213d(vs.80).aspx
>>
>>"Use of two sequential underscore characters ( __ ) at the beginning of an
>>identifier, or a single leading underscore followed by a capital letter,
>>is
>>reserved for C++ implementations in all scopes."
>
> s/at the beginning of an/in an/

Yet another Microsoft documentation bug.

>
>
> --
> Doug Harrison
> Visual C++ MVP

Tom
Mon Jul 23 18:47:59 CDT 2007

Thanks. This is easy for me to fix so I am... no sense in taking chances.

Tom

"Ben Voigt [C++ MVP]" <rbv@nospam.nospam> wrote in message
news:ucyJLkVzHHA.4800@TK2MSFTNGP05.phx.gbl...
>
> "Tom Serface" <tom.nospam@camaswood.com> wrote in message
> news:B0C999E5-17F5-49A3-ADFC-CD61377B40EB@microsoft.com...
>> Hi Ben,
>>
>> I didn't know that was "reserved". It compiles OK. I just named it that
>> because the actual functions in the object are named that as well and ...
>> oh well. It's only in my code so not harming anyone else.
>
> ... until the next Windows SDK comes out with a line like:

Doug
Mon Jul 23 20:47:35 CDT 2007

On Mon, 23 Jul 2007 17:26:34 -0500, "Ben Voigt [C++ MVP]"
<rbv@nospam.nospam> wrote:

>Yet another Microsoft documentation bug.

Yep. All most people need to remember is, "Underscore at the beginning bad,
two underscores in a row bad." The first part is overstated a tad, but IMO
it's as much as any normal user can be expected to remember.

--
Doug Harrison
Visual C++ MVP

Tom
Mon Jul 23 23:12:36 CDT 2007

What were we supposed to remember :o)

Tom

"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:4amaa35thd6nck8rpk3r96frra0vb6m9h0@4ax.com...
> On Mon, 23 Jul 2007 17:26:34 -0500, "Ben Voigt [C++ MVP]"
> <rbv@nospam.nospam> wrote:
>
>>Yet another Microsoft documentation bug.
>
> Yep. All most people need to remember is, "Underscore at the beginning
> bad,
> two underscores in a row bad." The first part is overstated a tad, but IMO
> it's as much as any normal user can be expected to remember.
>
> --
> Doug Harrison
> Visual C++ MVP

Bo
Tue Jul 24 05:08:14 CDT 2007

Tom Serface wrote:
:: What were we supposed to remember :o)

Two underscores in a row is reserved. Period.
Beginning with and underscore and uppercase letter is reserved.
Period.

Beginning with an underscore and lowercase letter is reserved in the
global namespace and in namespace std.

Add to this that the next C++ standard seems to reserve underscore
digit as a placeholder in bind expressions. Formally in a nested
namespace, but code will have to do a "using std::placeholders" to
make it work properly.


So, theoretically, you are allowed to use names beginning with
underscore lower case character in places other than namespace std and
the global namespace.


But before you do, please take a look at things like MS' tchar.h
header which has about 2000 #defines of names beginning with
underscore lowercase character. Seems like macros don't respect
namespaces, and will invade your code, even though they shouldn't.
Oops!


So, in practice, "Underscore at the beginning bad, two underscores in
a row bad."


Bo Persson


::
:: Tom
::
:: "Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
:: news:4amaa35thd6nck8rpk3r96frra0vb6m9h0@4ax.com...
::: On Mon, 23 Jul 2007 17:26:34 -0500, "Ben Voigt [C++ MVP]"
::: <rbv@nospam.nospam> wrote:
:::
:::: Yet another Microsoft documentation bug.
:::
::: Yep. All most people need to remember is, "Underscore at the
::: beginning bad,
::: two underscores in a row bad." The first part is overstated a
::: tad, but IMO it's as much as any normal user can be expected to
::: remember.
:::
::: --
::: Doug Harrison
::: Visual C++ MVP