 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] trf de> 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
|
|
| |
| |
|
|
|
|
| |
|
|
