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