 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] yahoo com
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
|
|
| |
| |
|
|
|
|
| |
|
|
