Subject: Re: [ecasound] status update, build errors, ...
From: Kai Vehmanen (email@example.com)
Date: Mon Jul 09 2001 - 08:58:12 EEST
On Mon, 9 Jul 2001, Junichi Uekawa wrote:
>> In the meantime, I may try playing with gcc-3.0 on i386...
> It's interesting. Many errors come up.
> adding some
> using namespace std;
> #include <iostream>
> fixes most of the errors, so far.
Yup, you're bound to get quite a few of them. I've specifically avoided
using the 'namespace' keyword until now, because it's not supported by
many older compilers. Big problem with supporting gcc-3.0 is how to
guarantee that older compilers still work. Redhat's own gcc 2.96 already
caused quite a bit of trouble.
Anyway, I've seen at least "#ifdef _NAMESPACES" used around code utilizing
namespaces. Additionally the STL library headers (which provide vector<>,
map<>, etc) define the __STL_USE_NAMESPACES if namespaces are used.
To be absolutely sure, we could explicit configure-checks for namespace
support. For instace (from libsigc++):
AC_MSG_CHECKING(if C++ compiler supports name spaces)
AC_MSG_WARN([Without namespaces all classes will be global.])
But this check isn't actually enough. The various things to check are:
- does the compiler support namespaces (like above)?
- are the standard headers (like <iostream> wrapped in 'std::' namespace?
- how does <iostream.h> behave; these should _not_ be in 'std::'?
- is the STL-library been configured to use namespaces?
On the other hand, the situation is not much better than before, because
now we actually have a stable standard-compliant compiler - the gcc
3.0. This is much easier than trying to anticipate how a future compiler
version will behave. :)
-- http://www.eca.cx Audio software for Linux!
-- To unsubscribe send message 'unsubscribe' in the body of the message to <firstname.lastname@example.org>.
This archive was generated by hypermail 2b28 : Mon Jul 09 2001 - 09:01:22 EEST