Topic: Why <cassert> ?


Author: "Al Stevens" <alstevens@midifitz.com>
Date: 1999/02/07
Raw View
>This phenomenon is yet another reason not to use macros in C++.

Or another reason not to use namespaces. :-)
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1999/02/07
Raw View
John D. Hickin<hickin@Hydro.CAM.ORG> wrote:
>My first feeling is that the <cfoo> headers are essentially the C
><foo.h> headers with one difference: the std namespace wrapper.
>
>Now <cassert> imports a macro (at least I assume that's all it does)
>which can't be in the standard namespace.
>
>Now assert may map onto a function call but if so, will that function be
>in std?

The reasons <cassert> is there in addition to <assert.h> are:
1. Symmetry with other header names;
2. The contents of <cassert> might actually be different from <assert.h>;
3. <assert.h> may be deprecated someday.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1999/02/07
Raw View
In article <BMHu2.13841$bM1.13270@newscene.newscene.com>, Al Stevens
<alstevens@midifitz.com> writes
>>This phenomenon is yet another reason not to use macros in C++.
>
>Or another reason not to use namespaces. :-)

Except there are few good reasons for using macros and IMO quite a lot
of excellent reasons for using namespaces (those who use advanced
template mechanisms will know just how valuable namespaces are in
controlling the context of a template and its instantiations.


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1999/02/09
Raw View
Al Stevens<alstevens@midifitz.com> wrote:
>>This phenomenon is yet another reason not to use macros in C++.
>
>Or another reason not to use namespaces. :-)

Methinks I hear a Troll honking under the bridge...

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: "John D. Hickin" <hickin@Hydro.CAM.ORG>
Date: 1999/02/05
Raw View
My first feeling is that the <cfoo> headers are essentially the C
<foo.h> headers with one difference: the std namespace wrapper.

Now <cassert> imports a macro (at least I assume that's all it does)
which can't be in the standard namespace.

Now assert may map onto a function call but if so, will that function be
in std?
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: clamage@Eng.Sun.COM (Steve Clamage)
Date: 1999/02/05
Raw View
"John D. Hickin" <hickin@Hydro.CAM.ORG> writes:

>My first feeling is that the <cfoo> headers are essentially the C
><foo.h> headers with one difference: the std namespace wrapper.

Not exactly. In both header forms, the names of types, objects, and
 functions specified by the standard are declared in namespace std.
 In the <foo.h> form, but not in the <cfoo> form, those names are
 also declared in the global namespace, as if by a using-declaration.

Here's a fragment of an example implementation:

<cstdio>
========
namespace std {
    struct FILE { ... };
    extern "C" int fprintf(FILE*, const char*, ... );
    ...
}


<stdio.h>
=========
#include <cstdio>
using std::FILE;
using std::fprintf;
...


Real implementations have to cope with other problems, and will
ordinarily be much more complicated. For example, a single
<stdio.h> file might be required to work with K&R C compilers,
Standard C compilers, ARM-style C++ compilers, and Standard
C++ compilers. It also might need to conform to other standards,
such as POSIX or XOPEN, that require still more declarations to
be present.

>Now <cassert> imports a macro (at least I assume that's all it does)
>which can't be in the standard namespace.

More correctly, namespaces are not relevant for macros. Macro
definition and expansion takes place during a translation
phase that occurs prior to recognition of any C++ keywords.
It doesn't matter whether any macro is defined in a namespace.
Whether you prefix any invocation with a namespace name does
not affect which macro is expanded.

Example:

namespace N {
#define macro_a A
#define double(x) (2*(x))
}
#define macro_b B

macro_a      ===> resolves to A
N::macro_a   ===> resolves to N::A
macro_b      ===> resolves to B
N::macro_b   ===> resolves to N::B
double(z)    ===> resolves to (2*(z))
N::double(z) ===> resolves to N::(2*(z)), a syntax error

This phenomenon is yet another reason not to use macros in C++.

>Now assert may map onto a function call but if so, will that function be
>in std?

It doesn't matter, and no program having defined behavior can tell.
That is, the function must have a name reserved to the implementation,
and so it doesn't matter what namespace it is in. Nothing in your
program can validly use the same name, so you can't have a name
collision. The implementation must arrange for the macro to expand
to something that calls the function correctly.

Here's an example that can be used for both <assert.h> and <cassert>:

extern "C" void __assert(const char *, const char *, int);
#undef  assert
#ifdef  NDEBUG
#define assert(X) ((void)0)
#else
#define assert(X) ((void)((X) || (__assert(#X, __FILE__, __LINE__), 0)))

But function __assert could have been put into namespace std,
and the macro assert modified to call std::__assert.  For that
matter, __assert could be put into namespace std and a using-
declaration added for it.  And of course, function __assert could
have some other name, or could have C++ linkage. The <assert.h> and
<cassert> headers could use different sets of choices.

Take any combination of those implementation choices. None of them
has any effect on how you use the <assert.h> or <cassert> headers,
or on how you use the assert macro.

--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]