5
.oisyn said:
Nonsense. Naming a header 'stdafx.h' [...]'s nothing unportable about it.
a) (the "mild" form) it might not compile at all
b) (the "evil" form) intended behaviour and actual behaviour might largely vary. Think of #define macros, function overloads, template partial and explicit specializations, et al.
Where is the portability when a) or b) strike?
Quote
In a header, yes. In a sourcefile everybody should decide for himself.
In my opinion, blanket using statements should never exceed function scope. Scope should (imho) be as big as needed, but not bigger.
Quote
All names in de std namespace are defined by the standard.
revision 0:
foo.hh:
#ifndef FOO_HH #define FOO_HH #endifbar.cc:
#include <string>
using namespace std;
#include "foo.hh"
class list {};
int main () {
list frogs;
}
revision 2048:
foo.hh:
#ifndef FOO_HH #define FOO_HH #include <list> #endif
Example consequence (note: bar.cc was never changed anymore!):
main.cc: In function ‘int main()’: main.cc:10: error: reference to ‘list’ is ambiguous main.cc:6: error: candidates are: class list /usr/include/c++/4.3/bits/stl_list.h:416: error: template<class _Tp, class _Alloc> class std::list main.cc:10: error: reference to ‘list’ is ambiguous main.cc:6: error: candidates are: class list /usr/include/c++/4.3/bits/stl_list.h:416: error: template<class _Tp, class _Alloc> class std::list main.cc:10: error: expected `;' before ‘frogs’
Quote
Again, nonsense. According to ISO/IEC 14882:2003, paragraph C.2.2.3/1:
Quote
The macro NULL, defined in any of <clocale>, <cstddef>, <cstdio>, <cstdlib>, <cstring>, <ctime>, or <cwchar>, is an implementation-defined C++ null pointer constant in this International Standard (18.1).
int main () {
int *p;
if (NULL == p) {
}
}
main.cc: In function ‘int main()’: main.cc:3: error: ‘NULL’ was not declared in this scope
I am not sure whether I shall now dive into all my source code files and pull in unrelated #include files just to have NULL defined, or just follow the well established and less redundant convention of using a builtin literal that also happens to be portable.
Quote
Oh, then what is the C++ counterpart of assert()?
Anyways, it is good practice to use the C++ counterparts of the C library where available. E.g., math.h defines cos and cosf, whereas cmath only defines the function name cos with three function overloads, thus reducing redundancy, improving readability of template code, helping to avoid the subtle issues when accidentally using 64bit floating point where only 32bit floating point is intended. There are some more less than irrelevant differences.
cassert and assert.h are the same, but why make an exception to the rule for only the assert macro?
