 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05.06.10 12:51, Warp wrote:
>> D.5 Standard C library headers [depr.c.headers]
>> 2 Each C header, whose name has the form name.h, behaves as if each name
>> placed in the Standard library namespace by the corresponding cname header
>> is also placed within the namespace scope of the namespace std and is
>> followed by an explicit using declaration (7.3.3)
>
>> LOL, the bad, bad standard uses "using declarations" for whole files. How
>> can those amateurs dare!
>
> Perhaps you don't understand what "compatibility" and "deprecated" mean?
>
> In English those words mean in this context "compilers should implement
> .h versions of standard header files for compatibility with code written
> for pre-standard C++ compilers, but these headers should be considered
> deprecated and might be removed at any time in the future".
Written for "pre-standard C++ compilers" - LOL. Seems you missed that C++ is
not a successor to the ISo C standard. That standard is well defined and
quite actively developed: <http://www.open-std.org/jtc1/sc22/wg14/> . But
hey, what do I know, I don't even speak English.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trf de> wrote:
> On 05.06.10 12:51, Warp wrote:
> >> D.5 Standard C library headers [depr.c.headers]
> >> 2 Each C header, whose name has the form name.h, behaves as if each name
> >> placed in the Standard library namespace by the corresponding cname header
> >> is also placed within the namespace scope of the namespace std and is
> >> followed by an explicit using declaration (7.3.3)
> >
> >> LOL, the bad, bad standard uses "using declarations" for whole files. How
> >> can those amateurs dare!
> >
> > Perhaps you don't understand what "compatibility" and "deprecated" mean?
> >
> > In English those words mean in this context "compilers should implement
> > .h versions of standard header files for compatibility with code written
> > for pre-standard C++ compilers, but these headers should be considered
> > deprecated and might be removed at any time in the future".
> Written for "pre-standard C++ compilers" - LOL. Seems you missed that C++ is
> not a successor to the ISo C standard. That standard is well defined and
> quite actively developed: <http://www.open-std.org/jtc1/sc22/wg14/> . But
> hey, what do I know, I don't even speak English.
I can't believe I have to explain this to you, even though you know this
perfectly well.
C++ was first developed by Stroustrup in 1983. C++ compilers began to
appear, each one implementing Stroustrup's language specification plus a
bunch of their own extensions, mostly in the form of libraries. These
libraries were in no way standardized and there was a wide variety of them.
These included all of the C standard libraries and compiler-specific C++
libraries.
By 1994 one set of libraries, which would later be known as the STL,
became popular and widespread in many compilers due to their versatility.
Back then there was no namespace support in many compilers, and a common
idiom was to have eg. a <vector.h> header file which declared the 'vector'
data container in global namespace. These got into widespread use.
It was not until 1998 (15 years after the language was invented and
compilers started appearing) that the language was standardized. The
standardization committee decided that all standard libraries should
use the 'std' namespace instead of declaring everything in the global
namespace.
Of course there was a minor practical problem then: In 1998 there were
tons and tons of C++ programs written for pre-standard C++ compilers. In
other words they used the <something.h> style of headers and assumed that
the names were in global namespace.
To alleviate this practical problem the standarization committee decided
to declare that compilers could preserve their <something.h> headers and
make them work as previously (iow. they declare everything in the global
namespace), but the new standard headers should be of the form <something>
and declare everything in the 'std' namespace instead.
The support for the old <something.h> style headers was added for
compatibility with existing compilers only, and marked as a deprecated
feature right from the start (in other words, new C++ code should not
assume that these headers will exist forever).
So yes, written for pre-standard C++ compilers. No LOL. There existed
tons of compilers before C++ was standardized, and there was lots and lots
of code written for those compilers.
Now, could you please explain what you meant with "seems you missed that
C++ is not a successor to the ISo C standard. That standard is well defined
and quite actively developed", and how it's relevant to what I wrote?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/06/2010 09:01, clipka wrote:
> But the question has become pretty much academic anyway, given that
> Chris has already announced that he will be addressing the issue himself.
I've made a change that pulls all the 'using namespace std' and 'using
namespace boost' out of the source, in favor of a few more specific
declarations in one header file (appropriately commented as to why):
using std::string;
using std::vector;
using std::list;
using std::runtime_error;
using boost::shared_ptr;
since these are the most often used, scattered in many places throughout
the POV code. all other references to stdlib or boost classes are now
qualified or limited in scope to a single file. I wanted to do something
along these lines for a while anyhow, since I do think it's cleaner than
pulling in all of std (you may notice that in the code I checked in for
e.g. the shellouts the other week I was preferring qualifiers rather than
importing namespaces).
of course this doesn't fix the problem with VS 2010, because some of its
header files refer to std::tr1::shared_ptr, so unless we go to the trouble
of explicitly qualifying shared_ptr everywhere we use it (and then have to
change that if we ever decide to use the tr1 version instead), it's still
not going to compile.
if C++ supported template typedefs we could fix it more cleanly that way,
but currently that's not yet the case. we could alternatively use the
struct rebind workaround, but I'm not sure that's any better than just
appending boost:: everywhere (though at least if we do go tr1 we only
change it in one place).
I'll probably fix it eventually as I'd like to see it work with compilers
that have tr1. do you have any opinion regards the typedef struct
workaround vs explicit scoping option?
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> I've made a change that pulls all the 'using namespace std' and 'using
> namespace boost' out of the source, in favor of a few more specific
> declarations in one header file (appropriately commented as to why):
> using std::string;
> using std::vector;
> using std::list;
> using std::runtime_error;
> using boost::shared_ptr;
That seems like a reasonable solution.
> of course this doesn't fix the problem with VS 2010, because some of its
> header files refer to std::tr1::shared_ptr, so unless we go to the trouble
> of explicitly qualifying shared_ptr everywhere we use it (and then have to
> change that if we ever decide to use the tr1 version instead), it's still
> not going to compile.
I don't see why not. Unless the VS 2010 header files are putting
std::tr1::shared_ptr in the global namespace (which I assume they aren't),
and given that you have removed the "using namespace std;" and "using
namespace boost;" clauses, I don't see how a name collision can happen
anylonger. The "using boost::shared_ptr;" brings only that one to the
global namespace, not the one in "std::".
I do think that what you did should fix the problem. (Of course it should
be tested to make sure.)
> if C++ supported template typedefs we could fix it more cleanly that way,
> but currently that's not yet the case.
One trick sometimes used to get around that problem is to use inheritance
instead:
template<typename T>
class MySharedPtr: public boost::shared_ptr<T>
{
...
};
Of course the downside of this is that you need to (at least with the
current C++ standard) replicate all the necessary constructors in that
derived class, which would call the base equivalent base class constructors.
(Fortunately the copy constructor, assignment operator and destructor don't
need to be replicated.)
Such a derived class is quite safe to use in that it will even survive
slicing.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05.06.10 16:32, Chris Cason wrote:
> On 4/06/2010 09:01, clipka wrote:
>> But the question has become pretty much academic anyway, given that
>> Chris has already announced that he will be addressing the issue himself.
>
> I've made a change that pulls all the 'using namespace std' and 'using
> namespace boost' out of the source, in favor of a few more specific
> declarations in one header file (appropriately commented as to why):
>
> using std::string;
> using std::vector;
> using std::list;
> using std::runtime_error;
> using boost::shared_ptr;
>
> since these are the most often used, scattered in many places throughout
> the POV code. all other references to stdlib or boost classes are now
> qualified or limited in scope to a single file. I wanted to do something
> along these lines for a while anyhow, since I do think it's cleaner than
> pulling in all of std (you may notice that in the code I checked in for
> e.g. the shellouts the other week I was preferring qualifiers rather than
> importing namespaces).
The most important question here now is if you tested on any other platform
yet. Windows headers tend to pull in lots of C headers, in particular math
functions and such, so you may have missed a lot of missing declarations
now, unless you added general using declarations everywhere a math function
is used...
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> The most important question here now is if you tested on any other platform
> yet. Windows headers tend to pull in lots of C headers, in particular math
> functions and such, so you may have missed a lot of missing declarations
> now, unless you added general using declarations everywhere a math function
> is used...
One possibility with that is to #include <math.h> instead of <cmath>.
While <math.h> is deprecated in the current standard, it's nevertheless
still standard, and including it should bring only the contents of <math.h>
to the global namespace instead of everything.
Of course the downside of this is that deprecation means that in the
future it might not work. (I actually haven't checked if C++0x still
defines the .h versions of standard headers as part of the standard in
the same way as C++98 does.)
While not the cleanest possible solution, at least it's an easy one.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/06/2010 00:56, Warp wrote:
> I do think that what you did should fix the problem. (Of course it should
> be tested to make sure.)
No. I installed VS 2010 in a VM. It does not fix it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> On 6/06/2010 00:56, Warp wrote:
> > I do think that what you did should fix the problem. (Of course it should
> > be tested to make sure.)
> No. I installed VS 2010 in a VM. It does not fix it.
I'm curious to know what is happening. What is causing there to still be
a naming collision?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/06/2010 01:35, Warp wrote:
> Chris Cason <del### [at] deletethistoopovrayorg> wrote:
>> On 6/06/2010 00:56, Warp wrote:
>> > I do think that what you did should fix the problem. (Of course it should
>> > be tested to make sure.)
>
>> No. I installed VS 2010 in a VM. It does not fix it.
>
> I'm curious to know what is happening. What is causing there to still be
> a naming collision?
One of the VS header files is pulling in a reference to shared_ptr. I
really don't have the time or inclination to chase it down ATM.
The use of "using namespace std" however had nothing to do with the compile
fail on VS 2010, which is more or less as I expected.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/06/2010 01:08, Thorsten Froehlich wrote:
> The most important question here now is if you tested on any other platform
> yet. Windows headers tend to pull in lots of C headers, in particular math
> functions and such, so you may have missed a lot of missing declarations
> now, unless you added general using declarations everywhere a math function
> is used...
These sort of problems I'll have to look at, if need be I can merge the
code to include std back in if it's too much hassle to fix. I'll have a
poke at the linux version in the next few days. My change is experimental
and I'm not dogmatic about it, if the path of least resistance is that way
I'll revert it.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
