Am 01.06.2010 21:46, schrieb Warp:

>> In case you don't notice: You're currently treading on the feet of many
>> who are contributing to POV-Ray. Please, by all means, switch to a less
>> destructive mode or - beg your pardon - STFU. You're addressing people,
>> not programming robots!
>
>    Maybe if someone would finally produce some rational arguments why the
> current usage of 'using namespace' should be kept and the problems kludged
> around with some compiler-specific precompiler macros.

Are you even marginally aware that those people don't report to you? 
They're not your slaves, nor is it /your/ software they're writing - 
it's /their/ software, which they happen to love to produce, and they 
are producing it just the way they happen to do. If they decide to 
kludge around it, they will kludge around it as long as they like.

If you don't think they're doing it right, then take it, join it, or 
leave it.

If you think your postings are of much help, then no - obviously they're 
not. They might, in case you start treating those people with more respect.

(Yes, I am aware that some time ago you did contribute to POV-Ray. But 
as far as I can see, you're more into criticism and utter disrespect 
these days. And I don't even mean lack of respect for the work they do, 
but even lack of the basic respect for them as persons.)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> (Yes, I am aware that some time ago you did contribute to POV-Ray. But 
> as far as I can see, you're more into criticism and utter disrespect 
> these days. And I don't even mean lack of respect for the work they do, 
> but even lack of the basic respect for them as persons.)

  This is going to sound really smug, but given that one developer outright
refuses to give any arguments or reasoning whatsoever about his opposition
to what I'm saying, and that another is only engaging in a meta-discussion
about my writing style, I can only conclude that there are no rational reasons
or arguments against what I'm saying.

  Thus you can either keep ranting about my writing style and how I "insult"
people, or you can alternatively start some actual constructive conversation
about the problem at hand and how it should be solved.

  At least I suggested a solution to the problem. What have you suggested?
That I shut the fuck up. That's what. How is that constructive, and how does
it help in solving the problem?

-- 
                                                          - Warp

Post a reply to this message

clipka wrote:
> Am 01.06.2010 20:29, schrieb Warp:
>>    I'm curious to know what is your solution to all the other compilers
>>    which
>> are implementing features of the upcoming C++ standard. Will you find
>> such preprocessor macros in all of them and add them to the project? Are
>> you going to keep blaming the compilers for implementing the new
>> standard?
> 
> Keep cool. If that's really something you're genuinely worried about,
> then you should stop talking and start helping. If you're just curious
> about it, you might get some answers if you changed to a more neutral
> mode. But if you're just into accusing others of doing the things wrong
> that they do, please stop your ranting and - pardon my french - shut
> your cake-hole.
> 
> If people don't do things the way /you/ want them to be done, then it's
> /you/ who's making a mistake - by just standing at the side and giving
> smart advice instead of getting your hands dirty yourself.

The point is: If he stops complaining and goes get his hands dirty and sends 
you a patch adding the needed std:: namespace prefixes... will you accept it 
and apply it?

Post a reply to this message

Am 02.06.2010 20:55, schrieb Nicolas Alvarez:

> The point is: If he stops complaining and goes get his hands dirty and sends
> you a patch adding the needed std:: namespace prefixes... will you accept it
> and apply it?

Warp used to have an account for the POV-Ray code repository to directly 
submit changes, so your question is actually missing the point, unless 
that account was revoked for some reason (and even then it would 
ultimately be up to Chris Cason to accept or reject such a patch).

Post a reply to this message

"Fredrik Eriksson" <fe79}--at--{yahoo}--dot--{com> wrote:

> 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.

The point of namespaces is to give you tools to *manage* namespaces. If all you
wanted was a way of naming things differently, then C++, pre-namespace, already
gave you ways of doing that.

one example being:

struct std { class cout { ... }; class endl { ... }  };
std::cout << blah() << std::endl;

Namespaces are more than just another scoping qualifier. The whole point of
namespaces is that they give you access to the using statement (with differing
levels granularity, and with aliasing). If all you use namespaces for is to add
an additional scoping qualifier, that you then use in full everywhere in your
code, than you're not really using them properly.

Cheers,
Edouard.

Post a reply to this message

I'll have a look to see if I can tighten the namespace usage up a bit. As a
rule I tend to try to avoid "using std" if I can, but there's some places
where we use a namespace so much that typing in the prefix each time makes
the code less readable by cluttering it. At the least I might be able to
only import specific portions. The other option is to typedef stuff we use
a lot (std::string would be a prime candidate for this).

As for not compiling in VS 2010 - while I will fix it via the define
mentioned in this thread, I will point out that breaking boost is poor
practice by microsoft, as it's a very popular library. I haven't looked at
the VS2010 header files but if it's true that they are importing the
namespace that their implementation of shared_ptr is in by default (without
a specific directive from the project file), then that's hardly our fault.
They can't go and claim they didn't know there would be other folks using
shared_ptr ... at a minimum, their project conversion wizard should have
asked about this when bringing in pre-VS2010 projects.

-- Chris

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:

> > I would argue that fully qualifying all types is much worse practice.
>
>   It would be interesting to hear those arguments.

Well lets take the example in front of us - we've got new compiler and library
releases coming down the pipe from various vendors, and we've got a new standard
that is being rolled out by those vendors at different times.

(As an aside, this has been the case for the last 20 years I've been programming
C++; standard tracking by vendors is pretty varied, and upgrading to a new C++
compiler often causes issues in existing codebases - POV is pretty lucky in that
it was all in C for most of it's lifetime, and so you've avoiding a lot of that
pain. Having a large C++ codebase is an exercise in long-term pragmatism when it
comes to these issues.)

So we've chosen boost to give us some useful functionality - a very good choice
BTW - and now boost's success has caused it's most useful low level features to
be included in the new C++ standard. That's good. But in the meantime you've got
a code management task of some vendor/compiler/version/platform/library
combinations having std::shared_ptr, and some having boost::shared_ptr.

What do you do?

Well you can do a global search and replace to make all shared_ptr's into
std::shared_ptr's, but that isn't going to work since most compilers don't have
a std::shared_ptr yet. Or you could globally change them all to
boost::shared_ptr's, which means you're not using the new code that those new
compilers have. It's better to rely on the vendors version of libraries. And
you'd have to wait an awfully long time before you have the situation where
no-one would want to compile POV with a compiler that doesn't support the new
standard.

Or you can leave them as bare shared_ptr's and instead having "using" statements
to intelligently chose (based on compiler and version) whether a particular
compilation of POV uses the version in std or the version in boost. Yes, the
existing "using namespace boost; using namespace std;" causes a problem, but the
solution is to change those two lines, not hundreds of other lines in the file.

I'd suggest upgrading to the latest boost (1.43.0), and using the it's tr1
implementation (and namespace) over the "global" versions in boost. That will
give you a bit more fine grained control over managing the transition from boost
to the standard.

Also, as I suggested earlier, even that work can be carefully managed by relying
on vendor-specific switches to disable using the new standard until these issues
can be carefully considered, implemented and tested.

Cheers,
Edouard.

Post a reply to this message

On Thu, 03 Jun 2010 00:22:26 +0200, Chris Cason  
<del### [at] deletethistoopovrayorg> wrote:
> I'll have a look to see if I can tighten the namespace usage up a bit.  
> As a
> rule I tend to try to avoid "using std" if I can, but there's some places
> where we use a namespace so much that typing in the prefix each time  
> makes
> the code less readable by cluttering it. At the least I might be able to
> only import specific portions.

Importing specific symbols (and in some cases even whole namespaces) can  
sometimes be useful, but care should be taken to limit the scope at which  
the import takes place. Doing it in a header file is generally  
inadvisable; you never know what other symbols might be visible in  
whatever files include the header.

Another issue with importing whole namespaces that has not yet been  
touched upon in this thread is that doing so prohibits you from (re)using  
any name that is visible in that namespace. In other words, you can get  
collisions with your own type/variable names, not just with those in  
another namespace you are also importing (as in this particular case). The  
likelihood of a name collision depends on the size of the imported  
namespace and the size of the scope into which it is imported.



> As for not compiling in VS 2010 - while I will fix it via the define
> mentioned in this thread, I will point out that breaking boost is poor
> practice by microsoft, as it's a very popular library.

They are *not* breaking Boost; the types are in separate namespaces and  
can coexist just fine. The problem only arises when someone imports both  
types into the current namespace (in this case implicitly by importing  
both namespaces in their entirety) and then tries to use the unqualified  
typename.



> I haven't looked at the VS2010 header files but if it's true that they
> are importing the namespace that their implementation of shared_ptr is
> in by default (without a specific directive from the project file), then
> that's hardly our fault.

Why does it have to be anyone's fault? Microsoft made the decision that  
they thought would benefit their customers most. The only question now is  
whether you care enough about compatibility with VC++ 2010 to make the  
changes necessary to ensure such compatibility.

Note that the issue would have surfaced eventually anyway, even if  
Microsoft had chosen differently. In all likelihood, the new C++ standard  
will become final in about a year or so (it is already at Final Committee  
Draft, which essentially means feature freeze). Compiler vendors will  
continue to implement C++0x features, and eventually they will stop being  
optional. In fact, Visual C++ may well be the most predictable of the  
bunch; it is very unlikely that Microsoft would add new features in a  
minor version upgrade, so what they have now is probably going to be all  
they have for at least a year or two (this may actually have been a  
significant factor in their decision).

If the official stance of the POV-team is that compilers with C++0x  
features enabled are not (yet) supported, then that is fine. At least it  
would be consistent. It might not be what I personally would have chosen,  
but it is not for me to make that call.



> They can't go and claim they didn't know there would be other folks using
> shared_ptr ... at a minimum, their project conversion wizard should have
> asked about this when bringing in pre-VS2010 projects.

I disagree. Boost is *expected* to clash with the standard library; one of  
the main goals of Boost is to get libraries into the standard. This is  
exactly the kind of situation that namespaces are intended for.



-- 
FE

Post a reply to this message

On 3/06/2010 09:40, Fredrik Eriksson wrote:
> The only question now is whether you care enough about compatibility
> VC++ 2010 to make the changes necessary to ensure such compatibility.

No, that is not the question. It's not the question because I already
answered it in the message you are replying to (and in fact you even quoted
my response). I clearly stated I would fix it; yet you chose to be
insulting in response ('whether we care enough' is clearly not intended to
be polite).

Hint: obliquely insulting developers who give their time for free isn't a
good way to get things done.

> If the official stance of the POV-team is that compilers with C++0x  
> features enabled are not (yet) supported, then that is fine. At least it  

Our official stance is that we support what our source code pages say we
support. You can read into that what you wish.

> would be consistent. It might not be what I personally would have
> chosen, but it is not for me to make that call.

VS 2010 was only officially released a month or two ago; not everyone has
the luxury of having the latest release toolsets. If you wish to purchase a
copy of Visual Studio 10 Pro for us to use then I'd be happy to add
"official support" for it and thus C++0x.

If you are not willing to do so then it seems rather arrogant for you to be
taking the attitude you have in your previous posts. Put simply, if you're
not willing to provide us the tools to achieve the result you wish, then I
suggest you don't talk down to us in the manner you have.

NB for the record, I'm not interested in installing the free express
edition of VS 2010 and thus running with two versions of VS installed. I'm
happy enough using VS 2008 pro; POV-Ray isn't the only project I code on
(it may surprise you to know I have a day job which pays the bills around
here - POV-Ray certainly doesn't) and I need the full version's features.

I have no reason to upgrade at the moment as none of my paying clients
requires me to have VS 2010.

-- Chris

Post a reply to this message

Chris Cason wrote:
> NB for the record, I'm not interested in installing the free express
> edition of VS 2010 and thus running with two versions of VS installed. 

VMs are great for this sort of thing.  MS even has a free VM that 
(obviously) works really well with Windows.  Which is not to imply any 
obligation on your part to use a VM, but if your job ever requires you to 
use different programs that only run under incompatible OSes, it works out OK.

-- 
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