Why is it allowed for implementations to have such a -Dmacro=value option
that influences conditional inclusion? I mean, if i have the following
source file

#ifdef MACRO
#error "Plain Wrong"
#endif

int main() { }

Then i would expect the Standard to require an implementation to correctly
translate this program. But if the compiler is executed with "-DMACRO", then
would the implementation not become nonconforming?

In other words, are implementations allowed to predefine macros with names
residing in the user namespace if they want?


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On May 24, 3:34 am, "Johannes Schaub (litb)" <schaub-johan...@web.de>
wrote:
> Why is it allowed for implementations to have such a -Dmacro=value option
> that influences conditional inclusion?

It's a capability that's somewhere between useful and essential,
though as
you indicate, it's a typical C feature that you can use to shoot your
feet off
if you want to.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On May 24, 4:34 am, "Johannes Schaub (litb)" <schaub-johan...@web.de>
wrote:
> Why is it allowed for implementations to have such a -Dmacro=value option
> that influences conditional inclusion?

Because it would be silly (not to mention impractical) to forbid an
implementation to have explicit ways of modifying its behavior, even
if that makes it non-conformant?

An implementation may not predefine macros with names other than those
in the reserved implementation namespace (leading double underscore or
underscore + upper case letter). But if you pass -Dwhatever to your
compiler, that's your problem. It's like passing -std=g++0x to GCC.

Sebastian


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On May 26, 6:54 pm, CornedBee <wasti.r...@gmx.net> wrote:
> On May 24, 4:34 am, "Johannes Schaub (litb)" <schaub-johan...@web.de>
> wrote:
>
> > Why is it allowed for implementations to have such a -Dmacro=value
option
> > that influences conditional inclusion?
>
> Because it would be silly (not to mention impractical) to forbid an
> implementation to have explicit ways of modifying its behavior, even
> if that makes it non-conformant?

Actually, does it make it non-conformant? The unit in the standard is
"translation unit" not "file". Why can't an implementation define
translation unit as a file prepended by #defines defined by whatever
is specified using -D (plus inclusions, but that's not the issue
here)?


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jun 2, 3:06 pm, Christopher Dearlove
<chris.dearl...@baesystems.com> wrote:
> On May 26, 6:54 pm, CornedBee <wasti.r...@gmx.net> wrote:
>
> > On May 24, 4:34 am, "Johannes Schaub (litb)" <schaub-johan...@web.de>
> > wrote:
>
> > > Why is it allowed for implementations to have such a -Dmacro=value
> option
> > > that influences conditional inclusion?
>
> > Because it would be silly (not to mention impractical) to forbid an
> > implementation to have explicit ways of modifying its behavior, even
> > if that makes it non-conformant?
>
> Actually, does it make it non-conformant? The unit in the standard is
> "translation unit" not "file". Why can't an implementation define
> translation unit as a file prepended by #defines defined by whatever
> is specified using -D (plus inclusions, but that's not the issue
> here)?

"Translation unit" is defined in 2.1/1 as "A source file together with
all the headers (17.6.1.2) and source files included (16.2) via the
preprocessing directive #include, less any source lines skipped by any
of the conditional inclusion (16.1) preprocessing directives."

Although the implementation could loosely construct a file from
command-line options, it is not allowed to access that file because it
can't prepend #include to the source file, nor a series of #defines.

I think Johannes is right, but the problem is only of aesthetics
within the standard.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jun 3, 9:53 pm, David Krauss <pot...@gmail.com> wrote:
> On Jun 2, 3:06 pm, Christopher Dearlove
> > Actually, does it make it non-conformant? The unit in the standard is
> > "translation unit" not "file". Why can't an implementation define
> > translation unit as a file prepended by #defines defined by whatever
> > is specified using -D (plus inclusions, but that's not the issue
> > here)?
>
> "Translation unit" is defined in 2.1/1 as "A source file together with
> all the headers (17.6.1.2) and source files included (16.2) via the
> preprocessing directive #include, less any source lines skipped by any
> of the conditional inclusion (16.1) preprocessing directives."
>
> Although the implementation could loosely construct a file from
> command-line options, it is not allowed to access that file because it
> can't prepend #include to the source file, nor a series of #defines.

If the implementation could construct such a file I don't see why it
wouldn't be allowed to access it. But calling it a source file (rather
than the thing usually so described) would be standards lawyering
beyond the point of reason, I would agree.

> I think Johannes is right, but the problem is only of aesthetics
> within the standard.

Yes. Has there ever been a C++ compiler that didn't have some
sort of concept like this (also taking into account all those extra
#defines that aren't even accessible witrh -D most compilers provide)?
Not recognising this is a bit, purist maybe?


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jun 3, 3:53 pm, David Krauss <pot...@gmail.com> wrote:
> On Jun 2, 3:06 pm, Christopher Dearlove
>
> <chris.dearl...@baesystems.com> wrote:

> > Actually, does it make it non-conformant? The unit in the standard is
> > "translation unit" not "file". Why can't an implementation define
> > translation unit as a file prepended by #defines defined by whatever
> > is specified using -D (plus inclusions, but that's not the issue
> > here)?
>
> "Translation unit" is defined in 2.1/1 as "A source file together with
> all the headers (17.6.1.2) and source files included (16.2) via the
> preprocessing directive #include, less any source lines skipped by any
> of the conditional inclusion (16.1) preprocessing directives."
>
> Although the implementation could loosely construct a file from
> command-line options, it is not allowed to access that file because it
> can't prepend #include to the source file, nor a series of #defines.

But the implementation is already allowed to directly construct
#include <stddef.h> and #include <cstddef> without reference to a
physical file.  [Indeed any standard header, but #include <stddef.h>
and #include <cstddef> are both easy, and important for cross-
compilation.]
* Phase 4 of translation guarantees the results of #include <stddef.h>
are a self-contained translation unit, suitable for translation by
phases 1-4 (in particular phase 1).
* [cpp.include] p2 does not restrict the implementation-defined places
to search for #include <stddef.h> to a physical filesystem.  Any
reasonable emulation of a filesystem, with results suitable for phase
1 of translation, works.

The POSIX standards have required the -D command line option to work
this way for some time for C90 or C99 (depending on the version of the
standard), so the OP's question also is asking whether POSIX 4-6 are
directly requiring a C compilier to be non-conformant.

Off-hand, I would think (from the current state of things) that any
such problem would have been noticed and debated in the mid-1990's if
not earlier, and the results of any such debate would have had
consensus "not a direct contradiction in standards".  I haven't
actually checked for such a debate, but if it does exist the results
should immediately generalize to the extant C++ standards (C++98, C+
+03, C++0X).


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]