 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian Froeschlin <chr### [at] chrfr de> 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
|
|
| |
| |
|
|
|
|
| |
|
|
