Am 01.06.2010 20:22, schrieb Warp:

>    Experts of what? At least not in programming C++, that's for sure.

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!

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 01.06.2010 20:22, schrieb Warp:

> >    Experts of what? At least not in programming C++, that's for sure.

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

  People say "it would reduce readability/maintainability", "many experts
advocate the usage of 'using' statements". Could some rational arguments
explaining these claims be given?

-- 
                                                          - Warp

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Keep cool. If that's really something you're genuinely worried about, 
> then you should stop talking and start helping.

  Removing the 'using namespace' statements and adding the namespace
prefixes is mechanical work that could be done relatively easily
(especially if the compiler tells you where you have to put them), even
if it would take some time with a program of the size of POV-Ray.

  The problem is that some people involved in the project oppose this
idea. Hence such work might not be accepted.

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

  I have explained with rational arguments why removing the 'using namespace'
commands and using the namespace prefixes would be a good idea for all
kinds of reasons. I have seen no rational arguments against this suggestion,
only baseless claims (along the lines of "it would reduce maintainability",
with zero reasons or arguments why this would be so).

  Instead, Thorsten has suggested using really ugly kludges to get around
the problem, such as making POV-Ray not compile at all if the C++ version
is too new, or to use compiler-specific precompiler macros to turn off
the conflicting features. This, ironically, from the same person who argues
pro maintainability.

  Since nobody has presented any rational arguments why the 'using namespace'
statements should be kept, I see no logical reasons to keep them. But of
course stubborness and resistance to change (and perhaps pride) are stopping
this from being done, and instead some ugly compiler-specific kludges are
suggested instead.

  And your answer to this is "shut your cake-hole". Right.

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

  Please suggest how I could "get my hands dirty" in this case. Thorsten
is actively opposing the proper solution, so it's not like I could just go
and do it. At least not until he changes his mind.

-- 
                                                          - Warp

Post a reply to this message

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