I just tried to compile beta 37 with Visual C++ 2010. I got it working  
eventually, but there is at least one major problem that needs to be  
fixed. The code uses 'shared_ptr' without a namespace qualifier, and  
instead imports the entire 'boost' namespace. However, because the code  
also imports the entire 'std' namespace there is a conflict between the  
'shared_ptr' from Boost and the one in the standard library (one of the  
C++0x features in VC2010). Fully qualifying each and every reference to  
'shared_ptr' (thank you, "Replace in files") of course fixes this  
particular problem.

Linux users may run into the same problem if/when they upgrade to a newer  
version of libstdc++. A similar conflict can be expected for  
'boost::thread' as well.

Why does the POV-Ray code blindly import whole namespaces anyway? There is  
a reason why 'using namespace' statements are considered poor practice.



-- 
  Fredrik Eriksson
  fe7### [at] yahoocom

Post a reply to this message

On 29.05.10 20:06, Fredrik Eriksson wrote:
> I just tried to compile beta 37 with Visual C++ 2010. I got it working
> eventually, but there is at least one major problem that needs to be
> fixed. The code uses 'shared_ptr' without a namespace qualifier, and
> instead imports the entire 'boost' namespace. However, because the code
> also imports the entire 'std' namespace there is a conflict between the
> 'shared_ptr' from Boost and the one in the standard library (one of the
> C++0x features in VC2010). Fully qualifying each and every reference to
> 'shared_ptr' (thank you, "Replace in files") of course fixes this
> particular problem.

Then you should file a bug report with Microsoft because their library (and 
probably the compiler as well) enables non-standard behavior by default. 
Supporting draft standard features by default is extremely poor practice, or 
more precisely, a serious product defect. But it is of course typical M$ 
behavior to pull such stunts and forget an off-switch, so you may have to 
dig for it or patch your system library by hand <sigh>

> Linux users may run into the same problem if/when they upgrade to a
> newer version of libstdc++. A similar conflict can be expected for
> 'boost::thread' as well.

Before release POV-Ray will have to abandon boost::thread anyway, because it 
has too many limitations over existing C threading APIs (lack of access to 
the stack size in particular).

> Why does the POV-Ray code blindly import whole namespaces anyway? There
> is a reason why 'using namespace' statements are considered poor practice.

POV-Ray's usage of C++ is fully ISO standard compliant. If and when there 
will be an approved new version of the ISO C++ standard, POV-Ray source code 
will be made compatible. It is pretty pointless to chase a draft standard 
with any production source code, that would be miserable practice, as is 
demanding such compatibility.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Then you should file a bug report with Microsoft because their library (and 
> probably the compiler as well) enables non-standard behavior by default. 
> Supporting draft standard features by default is extremely poor practice, or 
> more precisely, a serious product defect. But it is of course typical M$ 
> behavior to pull such stunts and forget an off-switch, so you may have to 
> dig for it or patch your system library by hand <sigh>

  I'm curious to know what your excuse will be when the C++0x standard is
ratified and POV-Ray will stop compiling on *standard* compilers.

> > Why does the POV-Ray code blindly import whole namespaces anyway? There
> > is a reason why 'using namespace' statements are considered poor practice.

> POV-Ray's usage of C++ is fully ISO standard compliant.

  "Standard compliant" and "good practice" are two different things.

  A program where every single variable is global to the entire program and
named like var00001, var00002, var00003... would be "standard compliant",
but that doesn't mean it has good design.

  Avoiding "using namespace std;" is a good practice because it avoids
precisely the kind of problems as presented here.

> If and when there 
> will be an approved new version of the ISO C++ standard, POV-Ray source code 
> will be made compatible. It is pretty pointless to chase a draft standard 
> with any production source code, that would be miserable practice, as is 
> demanding such compatibility.

  Exactly what would be the problem in avoiding "using namespace std;" and
using the 'std::' prefixes? It's not like POV-Ray needs to be compilable in
20-years-old compilers anylonger (it requiring boost and all).

-- 
                                                          - Warp

Post a reply to this message

On 30.05.10 06:41, Warp wrote:
> Thorsten Froehlich<tho### [at] trfde>  wrote:
>> Then you should file a bug report with Microsoft because their library (and
>> probably the compiler as well) enables non-standard behavior by default.
>> Supporting draft standard features by default is extremely poor practice, or
>> more precisely, a serious product defect. But it is of course typical M$
>> behavior to pull such stunts and forget an off-switch, so you may have to
>> dig for it or patch your system library by hand<sigh>
>
>    I'm curious to know what your excuse will be when the C++0x standard is
> ratified and POV-Ray will stop compiling on *standard* compilers.

POV-Ray will continue to compile on all compilers that are ISO C++ 1998 and 
2003 standard compliant. Academically designing for an unknown future 
standard would mean no program would ever be written as standards can change 
everything over time, and _do_ even *drop* features!

>> POV-Ray's usage of C++ is fully ISO standard compliant.
>
>    "Standard compliant" and "good practice" are two different things.

No, good practice is a superset of standard compliant.

>    Avoiding "using namespace std;" is a good practice because it avoids
> precisely the kind of problems as presented here.

No, even a fine grain use of namespace std will not solve the problem. You 
end up having to fully qualify all names, which could not be more pointless 
- it completely defeats the purpose of namespaces being meant as a 
simplification, not a complication, for the programmer.

>    Exactly what would be the problem in avoiding "using namespace std;" and
> using the 'std::' prefixes? It's not like POV-Ray needs to be compilable in
> 20-years-old compilers anylonger (it requiring boost and all).

Formally the current standard-compliant way of accessing the std smart 
pointers is by accessing namespace std::tr1. The std qualifiers just add a 
lot of completely useless clutter to the code, seriously deteriorating 
maintainability. As nice as an academic code quality is, it is irrelevant in 
practice.

     Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> >    I'm curious to know what your excuse will be when the C++0x standard is
> > ratified and POV-Ray will stop compiling on *standard* compilers.

> POV-Ray will continue to compile on all compilers that are ISO C++ 1998 and 
> 2003 standard compliant. Academically designing for an unknown future 
> standard would mean no program would ever be written as standards can change 
> everything over time, and _do_ even *drop* features!

  You are seriously claiming that using 'std::' prefixes in order to make
the code more compatible with future standards is a bad idea?

> >    Avoiding "using namespace std;" is a good practice because it avoids
> > precisely the kind of problems as presented here.

> No

  WTF, man? "Avoiding 'use namespace std;' is a good practice." "No."

  Are you serious? It seems that you are. Your argumentation, however,
doesn't make the least bit of sense:

> even a fine grain use of namespace std will not solve the problem.

  I don't even understand what that means.

> You end up having to fully qualify all names

  And that's bad because...?

> which could not be more pointless 
> - it completely defeats the purpose of namespaces being meant as a 
> simplification, not a complication, for the programmer.

  No, the purpose of namespaces are to avoid name collisions, and 'using
namespace std;' completely defeats their purpose.

  Could you please explain in which way using 'std::' prefixes is a
complication?

> >    Exactly what would be the problem in avoiding "using namespace std;" and
> > using the 'std::' prefixes? It's not like POV-Ray needs to be compilable in
> > 20-years-old compilers anylonger (it requiring boost and all).

> Formally the current standard-compliant way of accessing the std smart 
> pointers is by accessing namespace std::tr1.

  There are no std smart pointers (other than auto_ptr). 'std::tr1' is not
standard.

  If you want to use boost smart pointers, then use boost smart pointers,
not some smart pointers which have been dumped to the global namespace,
causing potential name collisions (as happened here).

> The std qualifiers just add a 
> lot of completely useless clutter to the code, seriously deteriorating 
> maintainability.

  You are arguing purely for the sake of argument, and clearly don't know
what you are talking about. You clearly have the mindset of the typical
C hacker / beginner C++ programmer that the 'std::' prefixes are "ugly"
and "useless clutter", when in fact they are the exact opposite: They make
the code easier to understand and they are useful precisely because they
lessen the danger of name collisions (which is exactly what happened in
this case).

  Could you *please* explain to me *in detail* how using 'std::' prefixes
"seriously deteriorates maintainability"?

  I can argue why 'std::' prefixes make code easier to understand. For
example, assume a line of code like this:

    if ( equal(a, b, c) ) { ... }

  What can you tell me about that line of code? That's right: Nothing at all.
This could be anything. Without seeing the rest of the code it's impossible
to tell what exactly it's doing.

  However, consider this line of code instead:

    if ( std::equal(a, b, c) ) { ... }

  What can you tell me about that line of code? Quite a lot. The 'std::'
prefix makes a whole world of a difference. Now you know that it's using
the 'equal()' function of the standard library, and hence you know that
'a' and 'b' are iterators defining a range, and 'c' is an iterator specifying
the beginning of another range. You also know what the conditional will do
(run through the first range and compare all the elements to the second
range).

  That's quite a lot of information that a simple 'std::' is conveying. More
importantly, the 'std::' prefix is making the line a lot more unambiguous
because you know you don't have to look where the definition of 'equal()'
might be, as you know it's a standard function. Hence the code is much
easier to understand more quickly and with less work.

  So, again, could you please explain how using 'std::' prefixes deteriorates
maintainability?

-- 
                                                          - Warp

Post a reply to this message

On 30.05.10 16:44, Warp wrote:
>    So, again, could you please explain how using 'std::' prefixes deteriorates
> maintainability?

Why should I waste my time? ;-)

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> On 30.05.10 16:44, Warp wrote:
> >    So, again, could you please explain how using 'std::' prefixes deteriorates
> > maintainability?

> Why should I waste my time? ;-)

  In other words, you don't have any actual rational arguments.

-- 
                                                          - Warp

Post a reply to this message

Thorsten Froehlich wrote:

> Supporting draft standard features by default is extremely poor 
> practice, or more precisely, a serious product defect.

this is certainly true. However, as far as I understand VS 2010
includes only that subset of C++0x which is deemed to be stable
and which will likely be present in other future C++ compilers.
Despite all reasoning to the contrary, MS folks are not
completely stupid. They will have picked carefully.

One of the purposes of drafts and beta versions is to give
developers time to prepare for changes so an incompatibility won't
hit them out of the blue. It would be rather unwise to knowingly
release 3.7 with such an incompatibility.

I'm not arguing against using namespace statements here, but at
least the known almost certainly soon-to-be name conflicts should
use fully qualified names even if the assessement is based on a
draft. Otherwise you get "academic code quality" ;)

Post a reply to this message

On 30.05.10 19:51, Christian Froeschlin wrote:
> this is certainly true. However, as far as I understand VS 2010
> includes only that subset of C++0x which is deemed to be stable
> and which will likely be present in other future C++ compilers.
> Despite all reasoning to the contrary, MS folks are not
> completely stupid. They will have picked carefully.

If this only was true :-(  For a long time, the M$ person on the ISO C++ 
committee tried to force the "concept" feature into the standard, 
subsequently leading to the two year delay when this unfinished idea had to 
be pulled because national bodies would not have such a broken incomplete 
idea in an international standard.

For what I see with other vendors, they simply pick the low hanging fruit 
concerning C++ 2011 features - namely, they introduce library changes.

> One of the purposes of drafts and beta versions is to give
> developers time to prepare for changes so an incompatibility won't
> hit them out of the blue. It would be rather unwise to knowingly
> release 3.7 with such an incompatibility.

There is no such incompatibility. It is as simple as turning the features 
off in the compiler. In fact, this is not much different to any other 
previous C standard update. As you might now, a lot of C compilers also 
support disabling C99 features.

> I'm not arguing against using namespace statements here, but at
> least the known almost certainly soon-to-be name conflicts should
> use fully qualified names even if the assessement is based on a
> draft. Otherwise you get "academic code quality" ;)

As said, there is no problem as long as new experimental compiler features 
are not enabled. There are actually C++ macros that return the version that 
is being compiled against. I would argue that it might be a good idea to 
check this version and refuse to preprocess if the required version is not set.

The more interesting question is the following though: Why does the problem 
appear at all? The answer is equally simple: Some header file pulls in the 
non-standard shared pointer class.

I would provide you with details, but the MSDn support pages are not the 
most Safari on Mac friendly (besides being even messier than before). You 
can find the starting link around here: 
<http://msdn.microsoft.com/en-us/library/ct1as7hw(v=VS.100).aspx>

	Thorsten

Post a reply to this message

On 30.05.10 19:29, Warp wrote:
> Thorsten Froehlich<tho### [at] trfde>  wrote:
>> On 30.05.10 16:44, Warp wrote:
>>>     So, again, could you please explain how using 'std::' prefixes deteriorates
>>> maintainability?
>
>> Why should I waste my time? ;-)
>
>    In other words, you don't have any actual rational arguments.

ROFL, no, it is because after over 12 years I know from a lot of experience 
that arguing with you over *anything* is a waste of time because you 
interpret every comma according to some weird interpretation and then 
construct conflicts where none exist, twist words, and generally like to 
start flame wars. Hence it is a waste of time because the flame wars you 
start lead to no meaningful result.

	Thorsten

Post a reply to this message

Christian Froeschlin <chr### [at] chrfrde> wrote:
> Thorsten Froehlich wrote:

> > Supporting draft standard features by default is extremely poor 
> > practice, or more precisely, a serious product defect.

> this is certainly true. However, as far as I understand VS 2010
> includes only that subset of C++0x which is deemed to be stable
> and which will likely be present in other future C++ compilers.
> Despite all reasoning to the contrary, MS folks are not
> completely stupid. They will have picked carefully.

  It is theoretically possible that the C++ standarization committee will
change the name 'shared_ptr' to something else for the precise reason that
the same name is used in a very popular library (ie. boost), in order to
avoid precisely this kind of naming conflicts. (This isn't completely
unprecedent. AFAIK part of the reason why std::unordered_set and
std::unordered_map are named like that instead of hash_set and hash_map
is precisely to avoid naming conflicts with boost.)

  However, even if the standardization committee would indeed end up
changing the name of 'shared_ptr' to something else, it would still be
a bad idea to use both "using namespace std;" and "using namespace boost;"
and assume that no conflicts will ever happen. After all, the namespaces
exist for the precise reason to avoid the conflicts. Getting rid of the
namespaces make their whole purpose moot, and can end up causing problems.

-- 
                                                          - Warp

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> On 30.05.10 19:29, Warp wrote:
> > Thorsten Froehlich<tho### [at] trfde>  wrote:
> >> On 30.05.10 16:44, Warp wrote:
> >>>     So, again, could you please explain how using 'std::' prefixes deteriorates
> >>> maintainability?
> >
> >> Why should I waste my time? ;-)
> >
> >    In other words, you don't have any actual rational arguments.

> ROFL, no, it is because after over 12 years I know from a lot of experience 
> that arguing with you over *anything* is a waste of time because you 
> interpret every comma according to some weird interpretation and then 
> construct conflicts where none exist, twist words, and generally like to 
> start flame wars. Hence it is a waste of time because the flame wars you 
> start lead to no meaningful result.

  And likewise I know that when you get cornered, you start avoiding the
actual subject by starting a meta-discussion about the "reasons" why you
won't present any more arguments to defend your position. It's not the
first time you have accused me if misinterpreting what you have written
and completely failed to specify exactly how I was mistinterpreting and
what is it that you really meant, even when I specifically asked for a
clarification.

  There is no possible misinterpretation in this thread. You clearly and
unambiguously defend the "using namespace std;" command, and even go so
far as to claim that using it somehow improves maintainability, while I
completely disagree and claim that it's the exact opposite: That abusing
that command decreases maintainability, readability and only introduces
problems (like in this case).

  If you accuse me of misinterpreting what you are saying, then please
explain more clearly what is it that you are saying.

-- 
                                                          - Warp

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> On 30.05.10 19:51, Christian Froeschlin wrote:
> > this is certainly true. However, as far as I understand VS 2010
> > includes only that subset of C++0x which is deemed to be stable
> > and which will likely be present in other future C++ compilers.
> > Despite all reasoning to the contrary, MS folks are not
> > completely stupid. They will have picked carefully.

> If this only was true :-(  For a long time, the M$ person on the ISO C++ 
> committee tried to force the "concept" feature into the standard, 
> subsequently leading to the two year delay when this unfinished idea had to 
> be pulled because national bodies would not have such a broken incomplete 
> idea in an international standard.

  I didn't know Bjarne Stroustrup worked for Microsoft (given that he has
been one of the most influential proponents of the concepts feature).

> > I'm not arguing against using namespace statements here, but at
> > least the known almost certainly soon-to-be name conflicts should
> > use fully qualified names even if the assessement is based on a
> > draft. Otherwise you get "academic code quality" ;)

> As said, there is no problem as long as new experimental compiler features 
> are not enabled. There are actually C++ macros that return the version that 
> is being compiled against. I would argue that it might be a good idea to 
> check this version and refuse to preprocess if the required version is not set.

  You are seriously suggesting that instead of removing "using namespace std;"
and "using namespace boost;", the code should use some non-standard macro
checks and refuse to compile if they do not have a certain value?

  Have you gone completely mad? I knew that you are stubborn and have a strong
resistance to change (any change), but this is going too far.

> The more interesting question is the following though: Why does the problem 
> appear at all? The answer is equally simple: Some header file pulls in the 
> non-standard shared pointer class.

  No, the answer is: "using namespace std;" and "using namespace boost;"
dump everything inside those namespaces to the *global* namespace, causing
potential name collisions.

  The solution is simple: Don't dump everything to the global namespace.

-- 
                                                          - Warp

Post a reply to this message

On 30.05.10 20:40, Warp wrote:
>> As said, there is no problem as long as new experimental compiler features
>> are not enabled. There are actually C++ macros that return the version that
>> is being compiled against. I would argue that it might be a good idea to
>> check this version and refuse to preprocess if the required version is not set.
>
>    You are seriously suggesting that instead of removing "using namespace std;"
> and "using namespace boost;", the code should use some non-standard macro
> checks and refuse to compile if they do not have a certain value?
>
>    Have you gone completely mad?

See, I don't have to get mad and jump up and down after I misinterpreted 
some statement because of lack of background knowledge. I just have to know 
that "__cplusplus" is a standard macro defined for exactly the purpose I 
stated :-)

     Thorsten


PS: This incident beggs the rhetoric question if I did not just a few 
minutes ago predict that you start arguments over misinterpretations exactly 
like the one above...

Post a reply to this message

Warp wrote:
>   However, even if the standardization committee would indeed end up
> changing the name of 'shared_ptr' to something else,

It would seem that if there's a conflict now, and the names are changed by 
the committee to avoid a conflict, then the next generation of compilers 
will be using the name from the wrong namespace, and you'll either not get a 
compile-time error at all but only wrong execution, or you'll get compile 
errors that make no sense in context, because anyone looking at the compile 
error will be looking at the definition in the wrong library and wondering 
why you're passing the wrong types of arguments.

-- 
Darren New, San Diego CA, USA (PST)
    Ada - the programming language trying to avoid
    you literally shooting yourself in the foot.

Post a reply to this message

Am 30.05.2010 06:41, schrieb Warp:

>    I'm curious to know what your excuse will be when the C++0x standard is
> ratified and POV-Ray will stop compiling on *standard* compilers.

There will be no such thing as C++0x, by the way.

Not that the proposals won't be turned into a new C++ specification, but 
it won't be going by the name "C++0x".

Post a reply to this message

Am 30.05.2010 16:44, schrieb Warp:

>    That's quite a lot of information that a simple 'std::' is conveying. More
> importantly, the 'std::' prefix is making the line a lot more unambiguous
> because you know you don't have to look where the definition of 'equal()'
> might be, as you know it's a standard function. Hence the code is much
> easier to understand more quickly and with less work.

I dare to disagree: I think it may make code more readable in some way, 
but at the same time make it less readable in some other way.

Readable != Readable. It depends whether you want to analyze in-depth 
how code /exactly/ does things, or whether you want to get a general 
overview of what the code does. Making consequent use of namespace 
prefixes helps for the former, but I guess it won't do too much good (if 
at all) for the latter, as for that purpose it just adds more 
information to digest when browsing the code; to a casual browser, it 
isn't important whether the smart_ptr is a std::smart_ptr or a 
boost::smart_ptr.

Warp, I think you're oversimplifying, as you often do (though you're not 
alone in that).

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> On 30.05.10 20:40, Warp wrote:
> >> As said, there is no problem as long as new experimental compiler features
> >> are not enabled. There are actually C++ macros that return the version that
> >> is being compiled against. I would argue that it might be a good idea to
> >> check this version and refuse to preprocess if the required version is not set.
> >
> >    You are seriously suggesting that instead of removing "using namespace std;"
> > and "using namespace boost;", the code should use some non-standard macro
> > checks and refuse to compile if they do not have a certain value?
> >
> >    Have you gone completely mad?

> See, I don't have to get mad and jump up and down after I misinterpreted 
> some statement because of lack of background knowledge. I just have to know 
> that "__cplusplus" is a standard macro defined for exactly the purpose I 
> stated :-)

>      Thorsten


> PS: This incident beggs the rhetoric question if I did not just a few 
> minutes ago predict that you start arguments over misinterpretations exactly 
> like the one above...

  You still keep accusing me of misinterpreting you, yet you fail to
specify exactly how I'm misinterpreting.

  You suggested making POV-Ray refuse to let itself being compiled by using
precompiler checks if the C++ standard version happens to be newer than the
current one. And the *sole* reason for this is that the source code uses
"using namespace std;" and "using namespace boost;" which potentially causes
name collisions.

  That suggestion is just crazy. Naturally the correct solution is to remove
the name collisions by *not* dumping everything to the global namespace.
Every C++ programmer who is even fairly competent knows this.

-- 
                                                          - Warp

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 30.05.2010 16:44, schrieb Warp:

> >    That's quite a lot of information that a simple 'std::' is conveying. More
> > importantly, the 'std::' prefix is making the line a lot more unambiguous
> > because you know you don't have to look where the definition of 'equal()'
> > might be, as you know it's a standard function. Hence the code is much
> > easier to understand more quickly and with less work.

> I dare to disagree: I think it may make code more readable in some way, 
> but at the same time make it less readable in some other way.

  I honestly cannot understand exactly what is it in 'std::' that would
make code "less readable". Exactly how does it make the code less readable?
Is someone going to get confused because there are some 'std::' prefixes
before some names? Exactly what kind of confusion does this cause? (As I
already said, the prefixes *remove* confusion and ambiguousity rather than
adding them, and that's pretty easy to demonstrate, as I did.)

  I have seen people opposing the usage of the 'std::' prefix for years,
and so far I have seen zero rational reasons for that.

> Readable != Readable. It depends whether you want to analyze in-depth 
> how code /exactly/ does things, or whether you want to get a general 
> overview of what the code does.

  But that's the whole point: The 'std::' prefixes make it a *lot* easier
to get a quick understanding of what a piece of code is doing. It makes it
both visually and contextually clear and unambiguous when a standard function
or type is used, and hence no time needs to be spent in figuring out what
exactly a name is referring to.

  You make it sound like omitting the 'std::' prefixes would actually help
in "getting a general overview of what the code does", or in other words,
using them would make it more difficult to understand the code at a glance.
Exactly what do you base this on?

  The 'std::' prefixes are both a clear visual clue which helps seeing
quickly that something in the standard library is being used, and they
also provide more in-depth information if you know what that function or
type does, without having to start guessing whether it's something from
the standard library or from somewhere else.

> Making consequent use of namespace 
> prefixes helps for the former, but I guess it won't do too much good (if 
> at all) for the latter, as for that purpose it just adds more 
> information to digest when browsing the code; to a casual browser, it 
> isn't important whether the smart_ptr is a std::smart_ptr or a 
> boost::smart_ptr.

  So in your own words, the *worst* case scenario is that the 'std::'
prefixes don't add anything informative to the casual viewer. Which would
mean that they aren't actually harmful at all.

  So given its benefit, and given that there are no disadvantages, why
would one want to omit them?

> Warp, I think you're oversimplifying, as you often do (though you're not 
> alone in that).

  Oversimplifying what exactly?

-- 
                                                          - Warp

Post a reply to this message

Am 30.05.2010 21:49, schrieb Warp:

>    That suggestion is just crazy. Naturally the correct solution is to remove
> the name collisions by *not* dumping everything to the global namespace.
> Every C++ programmer who is even fairly competent knows this.

(If you're such a good C++ programmer, then I guess you're welcome to 
(once again) get your hands dirty with helping and improving the 
oh-so-bad codebase of POV-Ray... but of course the critic's position is 
a far easier one than the - If I may say so - artist's.)


My personal opinion in this dispute, if I may point the perspective back 
to the technical side, is that since the boost project has always (or at 
least so it appears to me) aimed at setting new standards and embraced 
the adoption of their concepts into future C++ standards, it would be 
prudent to /expect/ that identifiers currently in the boost:: namespace 
/may/ make their way into the std:: namespace sooner or later, 
/possibly/ without being renamed by the standardization body.

I think a reasonable way to achieve this would be to drop the "using 
namespace boost;" and replace it with either explicit namespace 
prefixes, or - which I'd personally favor - individual "using 
boost::whatever" statements to pull only the identifiers into global 
namespace that are actually used.

I personally reject both the notion that the current POV-Ray code is 
"bad" and therefore /must/ be changed, nor the contrary position that 
only MS Visial C++ 2010 is "bad" by implementing a non-finalized 
standard, and therefore the POV-Ray code /must not/ be changed.

Fact is, as of today, the POV-Ray code /can/ be changed to be perfectly 
compatible with all of (a) the current C++ standard, (b) Microsoft's 
VC++ 2010 implementation and (c) whatever the future C++ standard may be 
- so I'd say this trouble report would be a good occasion to just go 
ahead and make it so.

(... engage Warp drives, Mr. Data...)

Post a reply to this message

Am 30.05.2010 22:03, schrieb Warp:

>    Oversimplifying what exactly?

That, exactly.

Post a reply to this message

On Sun, 30 May 2010 22:39:26 +0200, clipka <ano### [at] anonymousorg> wrote:
>
> I think a reasonable way to achieve this would be to drop the "using  
> namespace boost;" and replace it with either explicit namespace  
> prefixes, or - which I'd personally favor - individual "using  
> boost::whatever" statements to pull only the identifiers into global  
> namespace that are actually used.

Unfortunately, doing the latter is not enough. You can/will still get  
collisions as long as you continue to use "using namespace std;". At the  
very least, you would need to adopt the same practice for entities in the  
'std' namespace as well.

The point of namespaces is to prevent name collisions in code that uses  
several libraries (in this specific case, Boost and the standard library).  
Importing whole namespaces destroys that benefit, particularly when done  
at namespace scope.



> Fact is, as of today, the POV-Ray code /can/ be changed to be perfectly  
> compatible with all of (a) the current C++ standard, (b) Microsoft's  
> VC++ 2010 implementation and (c) whatever the future C++ standard may be  
> - so I'd say this trouble report would be a good occasion to just go  
> ahead and make it so.

One problem with just going ahead and making it so is that such a change  
may encounter resistance, as evidenced by this very thread.



-- 
FE

Post a reply to this message

Am 30.05.2010 23:21, schrieb Fredrik Eriksson:
>> Fact is, as of today, the POV-Ray code /can/ be changed to be
>> perfectly compatible with all of (a) the current C++ standard, (b)
>> Microsoft's VC++ 2010 implementation and (c) whatever the future C++
>> standard may be - so I'd say this trouble report would be a good
>> occasion to just go ahead and make it so.
>
> One problem with just going ahead and making it so is that such a change
> may encounter resistance, as evidenced by this very thread.

Often such resistance initially arises from people feeling personally 
attacked - e.g. a trouble reporter failing to keep neutral, or a 
developer misunderstanding the trouble report, making the developer 
interpret the reporter's posting as saying "you did a bad job there"; 
often, a typically reaction will then be born out of a "you can't blame 
me, it was their fault" -attitude, trying to find a culprit rather than 
a solution. (*)

In such cases, it is essential to get back to the technical level - and 
not get irritated by the resistance initially encountered.

Plus, it is also vitally important that the person proposing a solution 
is willing to pay some price for it. For instance, invest a fair deal of 
patience. Or actively helping to implement it.


(* BTW, that's a mode I can get into as well at times; no intention to 
put any blame on anybody here.)

Post a reply to this message

On Sun, 30 May 2010 23:51:38 +0200, clipka <ano### [at] anonymousorg> wrote:
>
> Plus, it is also vitally important that the person proposing a solution  
> is willing to pay some price for it. For instance, invest a fair deal of  
> patience. Or actively helping to implement it.

I would certainly be willing to put in the effort required to "fix" this  
issue. However, considering the various opinions presented in this thread,  
I think it would be unwise to "just go ahead and make it so" until there  
is some consensus as to which solution is to be preferred. Unfortunately,  
there is as far as I know no coding style guide for POV-Ray, so personal  
opinions (sometimes strongly held) are bound to come into play.



-- 
FE

Post a reply to this message

Am 31.05.2010 00:08, schrieb Fredrik Eriksson:
> On Sun, 30 May 2010 23:51:38 +0200, clipka <ano### [at] anonymousorg> wrote:
>>
>> Plus, it is also vitally important that the person proposing a
>> solution is willing to pay some price for it. For instance, invest a
>> fair deal of patience. Or actively helping to implement it.
>
> I would certainly be willing to put in the effort required to "fix" this
> issue. However, considering the various opinions presented in this
> thread, I think it would be unwise to "just go ahead and make it so"
> until there is some consensus as to which solution is to be preferred.
> Unfortunately, there is as far as I know no coding style guide for
> POV-Ray, so personal opinions (sometimes strongly held) are bound to
> come into play.

Don't worry - that sentence of mine wasn't really addressed to you in 
particular. I was just musing about how initial resistance can be 
overcome by whoever would pick up the glove of trying to move towards a 
particular solution.

After all, you just reported the issue and hinted at the underlying 
problem - that puts you into different shoes than other people who have 
been involved in this discussion and expressed their opinion of how 
things should be done instead.

Post a reply to this message

On Mon, 31 May 2010 13:29:22 +0200, clipka <ano### [at] anonymousorg> wrote:
>
> Don't worry - that sentence of mine wasn't really addressed to you in  
> particular.

I know, but since I have both the will and the means to do it (and I also  
seem to be the only one actually affected so far), my offer still stands.

What would be the appropriate way to get such changes integrated into the  
official code tree?



> After all, you just reported the issue and hinted at the underlying  
> problem - that puts you into different shoes than other people who have  
> been involved in this discussion and expressed their opinion of how  
> things should be done instead.

Oh, I have opinions, make no mistake. I hinted at mine in the original  
post, but I did not consider it worthwhile to get involved in the ensuing  
name-calling and dick-waving.



-- 
FE

Post a reply to this message

On 30.05.10 23:21, Fredrik Eriksson wrote:
>> Fact is, as of today, the POV-Ray code /can/ be changed to be
>> perfectly compatible with all of (a) the current C++ standard, (b)
>> Microsoft's VC++ 2010 implementation and (c) whatever the future C++
>> standard may be - so I'd say this trouble report would be a good
>> occasion to just go ahead and make it so.
>
> One problem with just going ahead and making it so is that such a change
> may encounter resistance, as evidenced by this very thread.

That is what you get when you post with an attitude in the first place.

	Thorsten

Post a reply to this message

On 30.05.10 22:39, clipka wrote:
> I think a reasonable way to achieve this would be to drop the "using
> namespace boost;" and replace it with either explicit namespace
> prefixes, or - which I'd personally favor - individual "using
> boost::whatever" statements to pull only the identifiers into global
> namespace that are actually used.

I think first we should look at where it is actually used. In most cases a 
typedef would be preferable to a general plain find and replace.

	Thorsten

Post a reply to this message

On 31.05.10 18:41, Thorsten Froehlich wrote:
> On 30.05.10 22:39, clipka wrote:
>> I think a reasonable way to achieve this would be to drop the "using
>> namespace boost;" and replace it with either explicit namespace
>> prefixes, or - which I'd personally favor - individual "using
>> boost::whatever" statements to pull only the identifiers into global
>> namespace that are actually used.
>
> I think first we should look at where it is actually used. In most cases
> a typedef would be preferable to a general plain find and replace.

Another thing to consider is that it may actually be that boost already 
provides or will provide the the functionality to move boost stuff out of 
the way in favor of platform specific implementation if it can detect their 
presence. Unfortunetly, these boost features are not always documented as 
well as they could be, so some digging in the boost mailing lists might be 
required.

	Thorsten

Post a reply to this message

"Fredrik Eriksson" <fe79}--at--{yahoo}--dot--{com> wrote:
> I just tried to compile beta 37 with Visual C++ 2010. I got it working
> eventually, but there is at least one major problem that needs to be
> fixed. The code uses 'shared_ptr' without a namespace qualifier, and
> instead imports the entire 'boost' namespace. However, because the code
> also imports the entire 'std' namespace there is a conflict between the
> 'shared_ptr' from Boost and the one in the standard library (one of the
> C++0x features in VC2010).

I was going to post a big post addressing all the things raised in this thread,
but, for now, I'll just address the "it doesn't compile under VC2010" item.

The problem is you have two implementations of the same thing - one from Boost,
and one from TR1, and the TR1 version has been enabled by default for the
standard includes in VS2010.

For now, you could try putting the following switch in the "C++ Command Line"
additional options field:

/D_HAS_CPP0X=0

That should suppress the TR1 features in the Microsoft headers, as it seems it's
not quite the time to move away from the Boost implementation of those features
just yet.

Cheers,
Edouard.

Post a reply to this message

"Fredrik Eriksson" <fe79}--at--{yahoo}--dot--{com> wrote:

> Why does the POV-Ray code blindly import whole namespaces anyway? There is
> a reason why 'using namespace' statements are considered poor practice.
> [...]
> Fully qualifying each and every reference to
> 'shared_ptr' (thank you, "Replace in files") of course fixes this
> particular problem.

I have to respectfully disagree - "using" statements, including "using
namespace", is not considered bad practice by everyone. Many experts feel that
"using" statements are in fact good engineering practice.

The beauty of the internet is that you can find as many experts as you want to
agree with any side of an argument.

I would argue that fully qualifying all types is much worse practice. Namespaces
are designed to manage these problems, otherwise you'd just embed all
definitions in a class called "std" instead. Namespaces give you more
sophisticated tools than your editors global find and replace dialog.

Cheers,
Edouard.

Post a reply to this message

On 01.06.10 00:00, Edouard wrote:
> For now, you could try putting the following switch in the "C++ Command Line"
> additional options field:
>
> /D_HAS_CPP0X=0
>
> That should suppress the TR1 features in the Microsoft headers, as it seems it's
> not quite the time to move away from the Boost implementation of those features
> just yet.

Cool, I was looking for this but could not find it at any logical place (to 
me) in the MSDN VC2010 documentation that is online. Do you have a reference 
where to find it? Strangely, googling for "D_HAS_CPP0X" returns no results - 
yet I thought all VC 2010 docs are online (I still have 2008, so i can't 
check offline docs).

	Thorsten

Post a reply to this message

Thorsten Froehlich wrote:
> On 01.06.10 00:00, Edouard wrote:
>> /D_HAS_CPP0X=0
> 
> Cool, I was looking for this but could not find it at any logical place
> (to me) in the MSDN VC2010 documentation that is online. Do you have a
> reference where to find it? Strangely, googling for "D_HAS_CPP0X" returns
> no results - yet I thought all VC 2010 docs are online (I still have 2008,
> so i can't check offline docs).

/D is a command-line switch. The macro is called _HAS_CPP0X.

http://www.google.com/search?q=_HAS_CPP0X

Post a reply to this message

On 01.06.10 06:17, Nicolas Alvarez wrote:
> Thorsten Froehlich wrote:
>> On 01.06.10 00:00, Edouard wrote:
>>> /D_HAS_CPP0X=0
>>
>> Cool, I was looking for this but could not find it at any logical place
>> (to me) in the MSDN VC2010 documentation that is online. Do you have a
>> reference where to find it? Strangely, googling for "D_HAS_CPP0X" returns
>> no results - yet I thought all VC 2010 docs are online (I still have 2008,
>> so i can't check offline docs).
>
> /D is a command-line switch. The macro is called _HAS_CPP0X.
>
> http://www.google.com/search?q=_HAS_CPP0X

Ah, I have to admit I never used the command-line define of VC. Thanks for 
the pointer!

	Thorsten

Post a reply to this message

Edouard <pov### [at] edouardinfo> wrote:
> Many experts feel that
> "using" statements are in fact good engineering practice.

  Experts of what? At least not in programming C++, that's for sure.

> I would argue that fully qualifying all types is much worse practice.

  It would be interesting to hear those arguments.

-- 
                                                          - Warp

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> On 01.06.10 00:00, Edouard wrote:
> > For now, you could try putting the following switch in the "C++ Command Line"
> > additional options field:
> >
> > /D_HAS_CPP0X=0
> >
> > That should suppress the TR1 features in the Microsoft headers, as it seems it's
> > not quite the time to move away from the Boost implementation of those features
> > just yet.

> Cool, I was looking for this but could not find it at any logical place (to 
> me) in the MSDN VC2010 documentation that is online. Do you have a reference 
> where to find it? Strangely, googling for "D_HAS_CPP0X" returns no results - 
> yet I thought all VC 2010 docs are online (I still have 2008, so i can't 
> check offline docs).

  I'm curious to know what is your solution to all the other compilers which
are implementing features of the upcoming C++ standard. Will you find such
preprocessor macros in all of them and add them to the project? Are you going
to keep blaming the compilers for implementing the new standard?

  And what happens when the upcoming standard gets ratified and suddenly all
those compilers become standard (and hence you can't blame them anylonger)?
What if some of those compilers stop referring to "CPP0X" or alike, once
again breaking the compilation?

  That solution is, simply put, a *kludge* to get around a design problem
which would have a very clear and clean solution.

  After all, it's perfectly *ok* for there to exist a class named "shared_ptr"
inside the 'boost' namespace *and* the 'std' namespace. That's exactly what
namespaces exist for. If you pull everything out of those namespaces and
suddenly get naming collisions, the problem is not in the libraries. The
problem is in your code. It's the code which is broken. The libraries are
doing nothing wrong.

-- 
                                                          - Warp

Post a reply to this message

Am 01.06.2010 20:29, schrieb Warp:

>    I'm curious to know what is your solution to all the other compilers which
> are implementing features of the upcoming C++ standard. Will you find such
> preprocessor macros in all of them and add them to the project? Are you going
> to keep blaming the compilers for implementing the new standard?

Keep cool. If that's really something you're genuinely worried about, 
then you should stop talking and start helping. If you're just curious 
about it, you might get some answers if you changed to a more neutral 
mode. But if you're just into accusing others of doing the things wrong 
that they do, please stop your ranting and - pardon my french - shut 
your cake-hole.

If people don't do things the way /you/ want them to be done, then it's 
/you/ who's making a mistake - by just standing at the side and giving 
smart advice instead of getting your hands dirty yourself.

Post a reply to this message

Am 01.06.2010 20:22, schrieb Warp:

>    Experts of what? At least not in programming C++, that's for sure.

In case you don't notice: You're currently treading on the feet of many 
who are contributing to POV-Ray. Please, by all means, switch to a less 
destructive mode or - beg your pardon - STFU. You're addressing people, 
not programming robots!

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 01.06.2010 20:22, schrieb Warp:

> >    Experts of what? At least not in programming C++, that's for sure.

> In case you don't notice: You're currently treading on the feet of many 
> who are contributing to POV-Ray. Please, by all means, switch to a less 
> destructive mode or - beg your pardon - STFU. You're addressing people, 
> not programming robots!

  Maybe if someone would finally produce some rational arguments why the
current usage of 'using namespace' should be kept and the problems kludged
around with some compiler-specific precompiler macros.

  People say "it would reduce readability/maintainability", "many experts
advocate the usage of 'using' statements". Could some rational arguments
explaining these claims be given?

-- 
                                                          - Warp

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Keep cool. If that's really something you're genuinely worried about, 
> then you should stop talking and start helping.

  Removing the 'using namespace' statements and adding the namespace
prefixes is mechanical work that could be done relatively easily
(especially if the compiler tells you where you have to put them), even
if it would take some time with a program of the size of POV-Ray.

  The problem is that some people involved in the project oppose this
idea. Hence such work might not be accepted.

> If you're just curious 
> about it, you might get some answers if you changed to a more neutral 
> mode. But if you're just into accusing others of doing the things wrong 
> that they do, please stop your ranting and - pardon my french - shut 
> your cake-hole.

  I have explained with rational arguments why removing the 'using namespace'
commands and using the namespace prefixes would be a good idea for all
kinds of reasons. I have seen no rational arguments against this suggestion,
only baseless claims (along the lines of "it would reduce maintainability",
with zero reasons or arguments why this would be so).

  Instead, Thorsten has suggested using really ugly kludges to get around
the problem, such as making POV-Ray not compile at all if the C++ version
is too new, or to use compiler-specific precompiler macros to turn off
the conflicting features. This, ironically, from the same person who argues
pro maintainability.

  Since nobody has presented any rational arguments why the 'using namespace'
statements should be kept, I see no logical reasons to keep them. But of
course stubborness and resistance to change (and perhaps pride) are stopping
this from being done, and instead some ugly compiler-specific kludges are
suggested instead.

  And your answer to this is "shut your cake-hole". Right.

> If people don't do things the way /you/ want them to be done, then it's 
> /you/ who's making a mistake - by just standing at the side and giving 
> smart advice instead of getting your hands dirty yourself.

  Please suggest how I could "get my hands dirty" in this case. Thorsten
is actively opposing the proper solution, so it's not like I could just go
and do it. At least not until he changes his mind.

-- 
                                                          - Warp

Post a reply to this message

Am 01.06.2010 21:46, schrieb Warp:

>> In case you don't notice: You're currently treading on the feet of many
>> who are contributing to POV-Ray. Please, by all means, switch to a less
>> destructive mode or - beg your pardon - STFU. You're addressing people,
>> not programming robots!
>
>    Maybe if someone would finally produce some rational arguments why the
> current usage of 'using namespace' should be kept and the problems kludged
> around with some compiler-specific precompiler macros.

Are you even marginally aware that those people don't report to you? 
They're not your slaves, nor is it /your/ software they're writing - 
it's /their/ software, which they happen to love to produce, and they 
are producing it just the way they happen to do. If they decide to 
kludge around it, they will kludge around it as long as they like.

If you don't think they're doing it right, then take it, join it, or 
leave it.

If you think your postings are of much help, then no - obviously they're 
not. They might, in case you start treating those people with more respect.

(Yes, I am aware that some time ago you did contribute to POV-Ray. But 
as far as I can see, you're more into criticism and utter disrespect 
these days. And I don't even mean lack of respect for the work they do, 
but even lack of the basic respect for them as persons.)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> (Yes, I am aware that some time ago you did contribute to POV-Ray. But 
> as far as I can see, you're more into criticism and utter disrespect 
> these days. And I don't even mean lack of respect for the work they do, 
> but even lack of the basic respect for them as persons.)

  This is going to sound really smug, but given that one developer outright
refuses to give any arguments or reasoning whatsoever about his opposition
to what I'm saying, and that another is only engaging in a meta-discussion
about my writing style, I can only conclude that there are no rational reasons
or arguments against what I'm saying.

  Thus you can either keep ranting about my writing style and how I "insult"
people, or you can alternatively start some actual constructive conversation
about the problem at hand and how it should be solved.

  At least I suggested a solution to the problem. What have you suggested?
That I shut the fuck up. That's what. How is that constructive, and how does
it help in solving the problem?

-- 
                                                          - Warp

Post a reply to this message

clipka wrote:
> Am 01.06.2010 20:29, schrieb Warp:
>>    I'm curious to know what is your solution to all the other compilers
>>    which
>> are implementing features of the upcoming C++ standard. Will you find
>> such preprocessor macros in all of them and add them to the project? Are
>> you going to keep blaming the compilers for implementing the new
>> standard?
> 
> Keep cool. If that's really something you're genuinely worried about,
> then you should stop talking and start helping. If you're just curious
> about it, you might get some answers if you changed to a more neutral
> mode. But if you're just into accusing others of doing the things wrong
> that they do, please stop your ranting and - pardon my french - shut
> your cake-hole.
> 
> If people don't do things the way /you/ want them to be done, then it's
> /you/ who's making a mistake - by just standing at the side and giving
> smart advice instead of getting your hands dirty yourself.

The point is: If he stops complaining and goes get his hands dirty and sends 
you a patch adding the needed std:: namespace prefixes... will you accept it 
and apply it?

Post a reply to this message

Am 02.06.2010 20:55, schrieb Nicolas Alvarez:

> The point is: If he stops complaining and goes get his hands dirty and sends
> you a patch adding the needed std:: namespace prefixes... will you accept it
> and apply it?

Warp used to have an account for the POV-Ray code repository to directly 
submit changes, so your question is actually missing the point, unless 
that account was revoked for some reason (and even then it would 
ultimately be up to Chris Cason to accept or reject such a patch).

Post a reply to this message

"Fredrik Eriksson" <fe79}--at--{yahoo}--dot--{com> wrote:

> The point of namespaces is to prevent name collisions in code that uses
> several libraries (in this specific case, Boost and the standard library).
> Importing whole namespaces destroys that benefit, particularly when done
> at namespace scope.

The point of namespaces is to give you tools to *manage* namespaces. If all you
wanted was a way of naming things differently, then C++, pre-namespace, already
gave you ways of doing that.

one example being:

struct std { class cout { ... }; class endl { ... }  };
std::cout << blah() << std::endl;

Namespaces are more than just another scoping qualifier. The whole point of
namespaces is that they give you access to the using statement (with differing
levels granularity, and with aliasing). If all you use namespaces for is to add
an additional scoping qualifier, that you then use in full everywhere in your
code, than you're not really using them properly.

Cheers,
Edouard.

Post a reply to this message

I'll have a look to see if I can tighten the namespace usage up a bit. As a
rule I tend to try to avoid "using std" if I can, but there's some places
where we use a namespace so much that typing in the prefix each time makes
the code less readable by cluttering it. At the least I might be able to
only import specific portions. The other option is to typedef stuff we use
a lot (std::string would be a prime candidate for this).

As for not compiling in VS 2010 - while I will fix it via the define
mentioned in this thread, I will point out that breaking boost is poor
practice by microsoft, as it's a very popular library. I haven't looked at
the VS2010 header files but if it's true that they are importing the
namespace that their implementation of shared_ptr is in by default (without
a specific directive from the project file), then that's hardly our fault.
They can't go and claim they didn't know there would be other folks using
shared_ptr ... at a minimum, their project conversion wizard should have
asked about this when bringing in pre-VS2010 projects.

-- Chris

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:

> > I would argue that fully qualifying all types is much worse practice.
>
>   It would be interesting to hear those arguments.

Well lets take the example in front of us - we've got new compiler and library
releases coming down the pipe from various vendors, and we've got a new standard
that is being rolled out by those vendors at different times.

(As an aside, this has been the case for the last 20 years I've been programming
C++; standard tracking by vendors is pretty varied, and upgrading to a new C++
compiler often causes issues in existing codebases - POV is pretty lucky in that
it was all in C for most of it's lifetime, and so you've avoiding a lot of that
pain. Having a large C++ codebase is an exercise in long-term pragmatism when it
comes to these issues.)

So we've chosen boost to give us some useful functionality - a very good choice
BTW - and now boost's success has caused it's most useful low level features to
be included in the new C++ standard. That's good. But in the meantime you've got
a code management task of some vendor/compiler/version/platform/library
combinations having std::shared_ptr, and some having boost::shared_ptr.

What do you do?

Well you can do a global search and replace to make all shared_ptr's into
std::shared_ptr's, but that isn't going to work since most compilers don't have
a std::shared_ptr yet. Or you could globally change them all to
boost::shared_ptr's, which means you're not using the new code that those new
compilers have. It's better to rely on the vendors version of libraries. And
you'd have to wait an awfully long time before you have the situation where
no-one would want to compile POV with a compiler that doesn't support the new
standard.

Or you can leave them as bare shared_ptr's and instead having "using" statements
to intelligently chose (based on compiler and version) whether a particular
compilation of POV uses the version in std or the version in boost. Yes, the
existing "using namespace boost; using namespace std;" causes a problem, but the
solution is to change those two lines, not hundreds of other lines in the file.

I'd suggest upgrading to the latest boost (1.43.0), and using the it's tr1
implementation (and namespace) over the "global" versions in boost. That will
give you a bit more fine grained control over managing the transition from boost
to the standard.

Also, as I suggested earlier, even that work can be carefully managed by relying
on vendor-specific switches to disable using the new standard until these issues
can be carefully considered, implemented and tested.

Cheers,
Edouard.

Post a reply to this message

On Thu, 03 Jun 2010 00:22:26 +0200, Chris Cason  
<del### [at] deletethistoopovrayorg> wrote:
> I'll have a look to see if I can tighten the namespace usage up a bit.  
> As a
> rule I tend to try to avoid "using std" if I can, but there's some places
> where we use a namespace so much that typing in the prefix each time  
> makes
> the code less readable by cluttering it. At the least I might be able to
> only import specific portions.

Importing specific symbols (and in some cases even whole namespaces) can  
sometimes be useful, but care should be taken to limit the scope at which  
the import takes place. Doing it in a header file is generally  
inadvisable; you never know what other symbols might be visible in  
whatever files include the header.

Another issue with importing whole namespaces that has not yet been  
touched upon in this thread is that doing so prohibits you from (re)using  
any name that is visible in that namespace. In other words, you can get  
collisions with your own type/variable names, not just with those in  
another namespace you are also importing (as in this particular case). The  
likelihood of a name collision depends on the size of the imported  
namespace and the size of the scope into which it is imported.



> As for not compiling in VS 2010 - while I will fix it via the define
> mentioned in this thread, I will point out that breaking boost is poor
> practice by microsoft, as it's a very popular library.

They are *not* breaking Boost; the types are in separate namespaces and  
can coexist just fine. The problem only arises when someone imports both  
types into the current namespace (in this case implicitly by importing  
both namespaces in their entirety) and then tries to use the unqualified  
typename.



> I haven't looked at the VS2010 header files but if it's true that they
> are importing the namespace that their implementation of shared_ptr is
> in by default (without a specific directive from the project file), then
> that's hardly our fault.

Why does it have to be anyone's fault? Microsoft made the decision that  
they thought would benefit their customers most. The only question now is  
whether you care enough about compatibility with VC++ 2010 to make the  
changes necessary to ensure such compatibility.

Note that the issue would have surfaced eventually anyway, even if  
Microsoft had chosen differently. In all likelihood, the new C++ standard  
will become final in about a year or so (it is already at Final Committee  
Draft, which essentially means feature freeze). Compiler vendors will  
continue to implement C++0x features, and eventually they will stop being  
optional. In fact, Visual C++ may well be the most predictable of the  
bunch; it is very unlikely that Microsoft would add new features in a  
minor version upgrade, so what they have now is probably going to be all  
they have for at least a year or two (this may actually have been a  
significant factor in their decision).

If the official stance of the POV-team is that compilers with C++0x  
features enabled are not (yet) supported, then that is fine. At least it  
would be consistent. It might not be what I personally would have chosen,  
but it is not for me to make that call.



> They can't go and claim they didn't know there would be other folks using
> shared_ptr ... at a minimum, their project conversion wizard should have
> asked about this when bringing in pre-VS2010 projects.

I disagree. Boost is *expected* to clash with the standard library; one of  
the main goals of Boost is to get libraries into the standard. This is  
exactly the kind of situation that namespaces are intended for.



-- 
FE

Post a reply to this message

On 3/06/2010 09:40, Fredrik Eriksson wrote:
> The only question now is whether you care enough about compatibility
> VC++ 2010 to make the changes necessary to ensure such compatibility.

No, that is not the question. It's not the question because I already
answered it in the message you are replying to (and in fact you even quoted
my response). I clearly stated I would fix it; yet you chose to be
insulting in response ('whether we care enough' is clearly not intended to
be polite).

Hint: obliquely insulting developers who give their time for free isn't a
good way to get things done.

> If the official stance of the POV-team is that compilers with C++0x  
> features enabled are not (yet) supported, then that is fine. At least it  

Our official stance is that we support what our source code pages say we
support. You can read into that what you wish.

> would be consistent. It might not be what I personally would have
> chosen, but it is not for me to make that call.

VS 2010 was only officially released a month or two ago; not everyone has
the luxury of having the latest release toolsets. If you wish to purchase a
copy of Visual Studio 10 Pro for us to use then I'd be happy to add
"official support" for it and thus C++0x.

If you are not willing to do so then it seems rather arrogant for you to be
taking the attitude you have in your previous posts. Put simply, if you're
not willing to provide us the tools to achieve the result you wish, then I
suggest you don't talk down to us in the manner you have.

NB for the record, I'm not interested in installing the free express
edition of VS 2010 and thus running with two versions of VS installed. I'm
happy enough using VS 2008 pro; POV-Ray isn't the only project I code on
(it may surprise you to know I have a day job which pays the bills around
here - POV-Ray certainly doesn't) and I need the full version's features.

I have no reason to upgrade at the moment as none of my paying clients
requires me to have VS 2010.

-- Chris

Post a reply to this message

Chris Cason wrote:
> NB for the record, I'm not interested in installing the free express
> edition of VS 2010 and thus running with two versions of VS installed. 

VMs are great for this sort of thing.  MS even has a free VM that 
(obviously) works really well with Windows.  Which is not to imply any 
obligation on your part to use a VM, but if your job ever requires you to 
use different programs that only run under incompatible OSes, it works out OK.

-- 
Darren New, San Diego CA, USA (PST)
    Ada - the programming language trying to avoid
    you literally shooting yourself in the foot.

Post a reply to this message