 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trf de> 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
|
|
| |
| |
|
|
|
|
| |
|
|
