 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] anonymous org> 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
|
|
| |
| |
|
|
|
|
| |
|
|
