Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Conditional compilation oddity

Reply
Thread Tools

Conditional compilation oddity

 
 
Ian Collins
Guest
Posts: n/a
 
      08-13-2013
David Brown wrote:
> On 13/08/13 09:53, Ian Collins wrote:
>> David Brown wrote:
>>> On 13/08/13 07:41, Ian Collins wrote:
>>>> Juha Nieminen wrote:
>>>>> ?? Tiib <(E-Mail Removed)> wrote:
>>>>>> On Monday, 12 August 2013 14:03:19 UTC+3, Juha Nieminen wrote:
>>>>>>> James Kanze <(E-Mail Removed)> wrote:
>>>>>>>> To be more exact: when evaluating a preprocessor expression,
>>>>>>>> symbols which are unknown to the preprocessor are replaced with
>>>>>>>> 0.
>>>>>>>
>>>>>>> I think that was a horrible idea from the people who first designed
>>>>>>> the C preprocessor. But I suppose it's too late to change it now.
>>>>>>
>>>>>> Why?
>>>>>
>>>>> What do you mean why? How exactly is it a good thing that unknown
>>>>> symbols are replaced with 0 instead of giving an error message?
>>>>
>>>> Lots of system headers rely on this behaviour. Whether this is a good
>>>> think or not is open for debate, but it does make sense for checks to
>>>> return false if the value is undefined. I guess checks for __cplusplus
>>>> being greater than some version in a header shared by C and C++ would be
>>>> one example.
>>>>
>>>
>>> I prefer to enable the gcc "-Wundef" warning in all my code - this turns
>>> pre-processor references to undefined macros into warnings rather than
>>> 0. gcc disables such warnings for system headers (unless you ask it not
>>> to), so it doesn't affect them - and it helps catch bugs in your own
>>> code. It's not hard to use "#ifdef XXX" rather than "#if XXX" for
>>> symbols that might be undefined.

>>
>> Or as C++ programmers, not to use the preprocessor at all! You can't
>> use #if for a comparison and comparisons often occur in a complex
>> expression so not defined = 0 makes sense.
>>

>
> Perhaps I am misunderstanding you, but you certainly /can/ use "#if" for
> comparisons:


Sorry, I should have written "You can't use #ifdef for a comparison".

--
Ian Collins
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      08-13-2013
Fred Zwarts (KVI) wrote:
> "Ian Collins" wrote in message news:(E-Mail Removed)...
>>
>> David Brown wrote:
>>> On 13/08/13 09:53, Ian Collins wrote:
>>>> David Brown wrote:
>>>>> On 13/08/13 07:41, Ian Collins wrote:
>>>>>> Juha Nieminen wrote:
>>>>>>> ?? Tiib <(E-Mail Removed)> wrote:
>>>>>>>> On Monday, 12 August 2013 14:03:19 UTC+3, Juha Nieminen wrote:
>>>>>>>>> James Kanze <(E-Mail Removed)> wrote:
>>>>>>>>>> To be more exact: when evaluating a preprocessor expression,
>>>>>>>>>> symbols which are unknown to the preprocessor are replaced with
>>>>>>>>>> 0.
>>>>>>>>>
>>>>>>>>> I think that was a horrible idea from the people who first designed
>>>>>>>>> the C preprocessor. But I suppose it's too late to change it now.
>>>>>>>>
>>>>>>>> Why?
>>>>>>>
>>>>>>> What do you mean why? How exactly is it a good thing that unknown
>>>>>>> symbols are replaced with 0 instead of giving an error message?
>>>>>>
>>>>>> Lots of system headers rely on this behaviour. Whether this is a good
>>>>>> think or not is open for debate, but it does make sense for checks to
>>>>>> return false if the value is undefined. I guess checks for
>>>>>> __cplusplus
>>>>>> being greater than some version in a header shared by C and C++ would
>>>>>> be
>>>>>> one example.
>>>>>>
>>>>>
>>>>> I prefer to enable the gcc "-Wundef" warning in all my code - this
>>>>> turns
>>>>> pre-processor references to undefined macros into warnings rather than
>>>>> 0. gcc disables such warnings for system headers (unless you ask it
>>>>> not
>>>>> to), so it doesn't affect them - and it helps catch bugs in your own
>>>>> code. It's not hard to use "#ifdef XXX" rather than "#if XXX" for
>>>>> symbols that might be undefined.
>>>>
>>>> Or as C++ programmers, not to use the preprocessor at all! You can't
>>>> use #if for a comparison and comparisons often occur in a complex
>>>> expression so not defined = 0 makes sense.
>>>>
>>>
>>> Perhaps I am misunderstanding you, but you certainly /can/ use "#if" for
>>> comparisons:

>>
>> Sorry, I should have written "You can't use #ifdef for a comparison".
>>

>
> But you can use
> #if defined(value) && value == 0


You missed my earlier point that comparisons often occur in a complex
expression, so this isn't convenient.

By way of an example, from stdio.h on my box:

/*
* The following are known to POSIX.1c, but not to ANSI-C or XOPEN.
*/
#if defined(__EXTENSIONS__) || defined(_REENTRANT) || \
(_POSIX_C_SOURCE - 0 >= 199506L)

--
Ian Collins
 
Reply With Quote
 
 
 
 
Öö Tiib
Guest
Posts: n/a
 
      08-13-2013
On Tuesday, 13 August 2013 08:20:54 UTC+3, Juha Nieminen wrote:
> ?? Tiib <(E-Mail Removed)> wrote:
>
> > On Monday, 12 August 2013 14:03:19 UTC+3, Juha Nieminen wrote:
> >> I think that was a horrible idea from the people who first designed
> >> the C preprocessor. But I suppose it's too late to change it now.

> >
> > Why?

>
> What do you mean why? How exactly is it a good thing that unknown
> symbols are replaced with 0 instead of giving an error message?


Some compilers and static analyze tools can be set up to warn.
"Why" in sense "why you suppose that it is too late?". The part you
snipped tried to elaborate how C++ is actually evolving to reduce
preprocessor usage.

I do not like the preprocessor because it is hard to debug it and
because it is prime source of long compiling times. Average C++
compilation unit is hundreds of thousands of lines long after
preprocessing. Mostly pointlessly.

 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      08-13-2013
On Tuesday, 13 August 2013 08:00:56 UTC+1, David Brown wrote:
> On 13/08/13 07:41, Ian Collins wrote:
> > Juha Nieminen wrote:
> >> ?? Tiib <(E-Mail Removed)> wrote:
> >>> On Monday, 12 August 2013 14:03:19 UTC+3, Juha Nieminen wrote:
> >>>> James Kanze <(E-Mail Removed)> wrote:
> >>>>> To be more exact: when evaluating a preprocessor expression,
> >>>>> symbols which are unknown to the preprocessor are replaced with
> >>>>> 0.


> >>>> I think that was a horrible idea from the people who first designed
> >>>> the C preprocessor. But I suppose it's too late to change it now.


> >>> Why?


> >> What do you mean why? How exactly is it a good thing that unknown
> >> symbols are replaced with 0 instead of giving an error message?


> > Lots of system headers rely on this behaviour. Whether this is a good
> > think or not is open for debate, but it does make sense for checks to
> > return false if the value is undefined. I guess checks for __cplusplus
> > being greater than some version in a header shared by C and C++ would be
> > one example.


> I prefer to enable the gcc "-Wundef" warning in all my code - this turns
> pre-processor references to undefined macros into warnings rather than
> 0. gcc disables such warnings for system headers (unless you ask it not
> to), so it doesn't affect them - and it helps catch bugs in your own
> code. It's not hard to use "#ifdef XXX" rather than "#if XXX" for
> symbols that might be undefined.


Or even "#if defined(XXX) && XXX > 0" (although I'm not sure
that the preprocessor short circuits, so you might get the
warning anyway). But I do like the idea of getting a warning.

--
James
 
Reply With Quote
 
woodbrian77@gmail.com
Guest
Posts: n/a
 
      08-13-2013
On Monday, August 12, 2013 10:01:05 AM UTC-5, Öö Tiib wrote:
>
> Why? C++ is hopefully going there. First was that dual meaning of
> 'const' to get rid of #define constants. That 'const' was fortunately
> fixed by 'constexpr'. 'constexpr' also fixed the remaining issues of
> using inlines instead of macros. Now what is missing is some replacement
> to #include (like modules). Also better debugging support (to replace
> those __LINE__ and __FILE__).



addrinfo* getaddrinfo_wrapper (char const*, int, int, int);

#define GETADDRINFO_RES(node, port, flags, socktype) \
auto deleter = [](addrinfo* p) { ::freeaddrinfo(p); }; \
::std::unique_ptr<addrinfo, decltype(deleter)> \
res(getaddrinfo_wrapper(node, port, flags, socktype), deleter);

This may not be what you mean, but was thinking about changing
that macro to be an inline function that returns a unique_ptr,
but don't think I can do that, since deleter wouldn't be in scope.


Brian
Ebenezer Enterprises - John 3:16.
http://webEbenezer.net
 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      08-13-2013
On Tuesday, 13 August 2013 22:26:45 UTC+3, (E-Mail Removed) wrote:
> On Monday, August 12, 2013 10:01:05 AM UTC-5, Öö Tiib wrote:
> >
> > Why? C++ is hopefully going there. First was that dual meaning of
> > 'const' to get rid of #define constants. That 'const' was fortunately
> > fixed by 'constexpr'. 'constexpr' also fixed the remaining issues of
> > using inlines instead of macros. Now what is missing is some replacement
> > to #include (like modules). Also better debugging support (to replace
> > those __LINE__ and __FILE__).

>
>
> addrinfo* getaddrinfo_wrapper (char const*, int, int, int);
>
> #define GETADDRINFO_RES(node, port, flags, socktype) \
> auto deleter = [](addrinfo* p) { ::freeaddrinfo(p); }; \
> ::std::unique_ptr<addrinfo, decltype(deleter)> \
> res(getaddrinfo_wrapper(node, port, flags, socktype), deleter);
>
> This may not be what you mean, but was thinking about changing
> that macro to be an inline function that returns a unique_ptr,
> but don't think I can do that, since deleter wouldn't be in scope.


You mean there is some reason why something like that does not work
better than the macro:

struct addrinfo;

typedef std::unique_ptr< addrinfo, void(*)(addrinfo*) > ResPtr;

inline
ResPtr makeResPtr(char const* node, int port, int flags, int socktype)
{
void freeaddrinfo(addrinfo*);
addrinfo* getaddrinfo_wrapper (char const*, int, int, int);

return ResPtr( getaddrinfo_wrapper(node, port, flags, socktype)
, ::freeaddrinfo);
}

// usage:
// ResPtr res = makeResPtr(node, port, flags, socktype);

What is the reason?
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      08-14-2013
On Wednesday, 14 August 2013 10:03:14 UTC+1, Juha Nieminen wrote:
> Ian Collins <(E-Mail Removed)> wrote:


> > Or as C++ programmers, not to use the preprocessor at all!


> There are certain situations where a preprocessor macro has no good
> substitute in either C or C++. assert() would be a good example
> (at least if you want the file and line number of the assertion itself
> into the message.)


Even without the line number. The expansion of assert changes
depending on whether a macro is defined or not, and can change
several different times in a single translation unit:

#define NDEBUG
#include <assert.h>
// ...
#undef NDEBUG
#include <assert.h>
// critical section, assert slows things down too much...
#define NDEBUG
#include <assert.h>

--
James
 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      08-18-2013
On Monday, 19 August 2013 00:20:11 UTC+3, (E-Mail Removed) wrote:
> On Tue, 13 Aug 2013 06:44:50 -0700 (PDT), Öö Tiib <(E-Mail Removed)>
> >I do not like the preprocessor because it is hard to debug it and
> >because it is prime source of long compiling times. Average C++
> >compilation unit is hundreds of thousands of lines long after
> >preprocessing. Mostly pointlessly.

>
> Although that's not really the fault of preprocessing, rather C++'s
> lack of a proper module concept.


Lack of proper module concept and lack of proper separation of interface
from implementation are because we have #include preprocessor
directive and include files inherited from C already. That helps with the
problem by causing those multimegabyte files. So it feels fault of
preprocessing in a way.
 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      08-19-2013
On Monday, 19 August 2013 06:36:15 UTC+3, (E-Mail Removed) wrote:
> On Sun, 18 Aug 2013 14:46:39 -0700 (PDT), Öö Tiib <(E-Mail Removed)>
> wrote:
>
> >On Monday, 19 August 2013 00:20:11 UTC+3, (E-Mail Removed) wrote:
> >> On Tue, 13 Aug 2013 06:44:50 -0700 (PDT), Öö Tiib <(E-Mail Removed)>
> >> >I do not like the preprocessor because it is hard to debug it and
> >> >because it is prime source of long compiling times. Average C++
> >> >compilation unit is hundreds of thousands of lines long after
> >> >preprocessing. Mostly pointlessly.
> >>
> >> Although that's not really the fault of preprocessing, rather C++'s
> >> lack of a proper module concept.

> >
> >Lack of proper module concept and lack of proper separation of interface
> >from implementation are because we have #include preprocessor
> >directive and include files inherited from C already. That helps with the
> >problem by causing those multimegabyte files. So it feels fault of
> >preprocessing in a way.

>
> I think that's looking at it backwards. We abuse the #include
> facility to provide some semblance of interfaces because there is not
> proper module concept in C++. We may be doing it for historical
> reasons, but that's not #include's fault.


Ok, maybe I somehow look at things backwards. Can you say again what
combination of these claims you suggest:

1) There was no .c and .h file pairs in C before C++ was designed.
2) The .c and .h file pairs of C did not cause that more proper
alternative module support was not designed into C++ language.
3) Lack of module support in C++ caused that we invented abuse of #include
directive and .cpp and .hpp file pairs.
4) Those .cpp and .hpp file pairs were loaned back into C as .c and .h
file pairs.

Since AFAIK those claims are all untrue it feels that I perhaps totally
misunderstand what you are trying to say.
 
Reply With Quote
 
Gerhard Fiedler
Guest
Posts: n/a
 
      08-19-2013
Öö Tiib wrote:

> On Monday, 19 August 2013 06:36:15 UTC+3, (E-Mail Removed) wrote:
>> On Sun, 18 Aug 2013 14:46:39 -0700 (PDT), Öö Tiib <(E-Mail Removed)>
>> wrote:
>>
>>>On Monday, 19 August 2013 00:20:11 UTC+3, (E-Mail Removed) wrote:
>>>> On Tue, 13 Aug 2013 06:44:50 -0700 (PDT), Öö Tiib <(E-Mail Removed)>
>>>> >I do not like the preprocessor because it is hard to debug it and
>>>> >because it is prime source of long compiling times. Average C++
>>>> >compilation unit is hundreds of thousands of lines long after
>>>> >preprocessing. Mostly pointlessly.
>>>>
>>>> Although that's not really the fault of preprocessing, rather C++'s
>>>> lack of a proper module concept.
>>>
>>>Lack of proper module concept and lack of proper separation of interface
>>>from implementation are because we have #include preprocessor
>>>directive and include files inherited from C already. That helps with the
>>>problem by causing those multimegabyte files. So it feels fault of
>>>preprocessing in a way.

>>
>> I think that's looking at it backwards. We abuse the #include
>> facility to provide some semblance of interfaces because there is not
>> proper module concept in C++. We may be doing it for historical
>> reasons, but that's not #include's fault.

>
> Ok, maybe I somehow look at things backwards. Can you say again what
> combination of these claims you suggest:
>
> 1) There was no .c and .h file pairs in C before C++ was designed.
> 2) The .c and .h file pairs of C did not cause that more proper
> alternative module support was not designed into C++ language.
> 3) Lack of module support in C++ caused that we invented abuse of #include
> directive and .cpp and .hpp file pairs.
> 4) Those .cpp and .hpp file pairs were loaned back into C as .c and .h
> file pairs.
>
> Since AFAIK those claims are all untrue it feels that I perhaps totally
> misunderstand what you are trying to say.


(I'm not him, but anyway...) Maybe

5) The existence of a preprocessor with its #include directive does not
in any way prevent the introduction of a proper concept of a 'module'.

?

(FWIW, it may make it seem less necessary, but that's something entirely
different.)

Gerhard
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Conditional compilation in VHDL avishay VHDL 4 08-01-2005 05:57 PM
? ELSE Conditional Comment / Using Conditional Comments Inside Other Tags To Comment Out Attributes Alec S. HTML 10 04-16-2005 02:21 AM
Conditional Compilation Directives in aspx file? Praveen Ramesh ASP .Net 2 04-13-2005 03:28 AM
Conditional Compilation Directives in aspx file? Praveen ASP .Net 0 04-12-2005 02:50 PM
Preprocessor conditional compilation variable not being saved Chris P ASP .Net 0 10-28-2003 08:48 PM



Advertisments