 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> 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.
Seconded - I run VMWare on my Mac, so, in this case, I downloaded VS 2010
express and fired it up that way. Really works well.
I hadn't, however, seen the latest happenings with Virtual PC - thanks for the
info.
Cheers,
Edouard.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 03.06.10 00:39, Edouard wrote:
> I'd suggest upgrading to the latest boost (1.43.0), and using the it's tr1
> implementation (and namespace)
That actually *is* a good idea indeed.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 03 Jun 2010 05:10:00 +0200, Chris Cason
<del### [at] deletethistoopovrayorg> wrote:
> 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).
It was never my intention to be insulting. That you choose to see things
that way is unfortunate, but not my doing.
> Hint: obliquely insulting developers who give their time for free isn't a
> good way to get things done.
Taking offence when none was intended is not very productive either.
It is abundantly clear that in addition to what anyone feels about the
technical issues under discussion, the very way I construct sentences is
being construed as a personal attack. Consequently, I will refrain from
further attempts at participation.
--
FE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Edouard <pov### [at] edouardinfo> wrote:
> 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;
That would be incorrect. Using a 'struct' instead of a 'namespace' means
that you have to declare all the elements inside the one and same block.
You cannot divide the declarations into separate files, each one declaring
elements inside the same 'std' struct.
Hence the standard library would be impossible to declare as a struct,
unless you want *everything* to be in one single header file. Given how much
template code there is in the C++ standard library, this one header file
would probably be several megabytes in size and take a significant amount
of time to parse.
> 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).
No. The whole point of namespaces is to add scoping and help remove names
from the global namespace. 'using' (with respect to namespaces) is just a
convenience feature which is more or less irrelevant. It doesn't really add
anything to the language. It could well be left out and little would change
in terms of functionality and usability. (Heck, IMO it would be a big-ass
*improvement* if it was removed from the standard.)
> 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.
And what, in your opinion, is the "proper" way of using namespaces?
A "using namespace" statement more or less makes the whole namespace
feature moot. If you are using that statement, you might just as well not
use any namespace to begin with. What's the point? I cannot comprehend how
declaring something in a named namespace and then immediately popping it to
the global namespace would be the "proper" way of using namespaces. That's
not using namespaces at all.
And as I have commented in another post, namespace prefixes actually make
the code *easier* to read and understand, not harder. It makes the code
significantly less ambiguous, and the prefix syntax is a clear visual clue
that something in a different scope is being used, and thus you don't have
to guess where that name might be defined and what its scope might be.
Popping a single name with eg. "using std::something;" is slightly better
because at least you are kind-of documenting that "when you see 'something'
in the code below, it's actually 'something' from the std::namespace". Doing
it like that also lessens the danger of naming collisions (because you are
popping the name out of one specific namespace). However, "using namespace
std;" is just nonsensical.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Edouard <pov### [at] edouardinfo> wrote:
> 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.
You are assuming that "shared_ptr" is the only thing that is being used
without a scope qualifier in the source code, and hence it's simply enough
to choose between either "using namespace std;" or "using namespace boost;"
to get the program to compile.
If you change those two lines, you are going to break a lot more than
some "shared_ptr" uses. Thus you either have to keep those lines, or you
have to go through hunderds of lines of code and add namespace prefixes.
Your argument did not, in fact, deal with whether it's a good idea to
use namespace prefixes or not. It dealt with abstraction. What you are
saying is "shared_ptr might refer to either the one in boost or the one
in the standard library, and it's thus bad to say explicitly at each
usage location which one it's using".
The solution to such a problem is not to play with namespaces, but to
abstract away the type. Using the name "shared_ptr" may be a bad idea
because it's actually not abstracting away much, and it has the danger
of suffering from name collisions.
In one post in this thread Thorsten suggested abstracting the smart
pointer away with a typedef. That's actually a good idea, and I concede that
that is a much better solution than the other things he suggested, or what
you are suggesting.
(Of course that doesn't mean that the "using namespace" statements are
any more of a good idea. IMO they should be removed regardless of whether
"shared_ptr" is abstracted away or not.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> On 03.06.10 00:39, Edouard wrote:
> > I'd suggest upgrading to the latest boost (1.43.0), and using the it's tr1
> > implementation (and namespace)
> That actually *is* a good idea indeed.
I don't really understand why it would be a good idea. Are you going to
either use a 'tr1::' namespace prefix (which will not compile with many
older compilers, and might not work with future compilers) or a "using
namespace tr1;" which would add yet a *third* instance of 'shared_ptr'
to mess up things even more?
I thought that one of the main principles with POV-Ray is that it should
be very portable and that one can compile it with all kinds of compilers
in all kinds of systems. The 'tr1' namespace is implemented in only a
handful of compilers.
If you use 'boost::shared_ptr' (even if typedeffed), that's going to
compile with all compilers, if the boost library is available, and it's
not going to break even with newer compilers and C++ standards.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> > 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.
I honestly cannot understand what is deemed so problematic here.
After all, the solution to the problem presented in the original post is
quite simple: Use a fully qualified shared_ptr (iow. "boost::shared_ptr").
Even if both boost and std have the same "shared_ptr", it doesn't matter:
If you fully qualify it, it will be unambiguous. You don't need compiler-
specific settings or outright dropping support for a compiler which
implements things in the new C++ standard, and blaming such compilers for
"breaking boost".
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> 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).
I think you're missing the point too. Just because he has commit access
doesn't mean he can go against what other team members want.
If he commits such a change, will you or Thorsten complain and/or revert it?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Your argument did not, in fact, deal with whether it's a good idea to
> use namespace prefixes or not. It dealt with abstraction. What you are
> saying is "shared_ptr might refer to either the one in boost or the one
> in the standard library, and it's thus bad to say explicitly at each
> usage location which one it's using".
>
> The solution to such a problem is not to play with namespaces, but to
> abstract away the type. Using the name "shared_ptr" may be a bad idea
> because it's actually not abstracting away much, and it has the danger
> of suffering from name collisions.
So, addressing the question of namespaces prefixes in general:
I've seen quite a lot of code in my time that looks like this:
std::vector< std::string > v1 = someFunction();
std::vector< std::string > v2;
std::transform( v1.begin(), v1.end, v2.begin(), std::bind1st( std::not_equal_to<
std::string >( "" ) ) );
for( std::vector< std::string >::iterator i = v2.begin(); i != v2.end(); ++i )
std::cout << *i << std::endl;
and I have trouble with it in terms of readability. There are namespace
qualifiers everywhere, and they don't convey any useful information to me. If I
see a "vector< string >" in some code, I make the assumption that it's a
std::vector and a std::string. Qualifying it seems rather pointless - esp when
you see it repeated on many subsequent lines. I don't look at the code above and
go "oh, and they are talking about a std::vector< std::string > on the second
line too - that's really useful to know. It would be very ambiguous otherwise".
Programming a medium to large sized project involves establishing a vocabulary
for that project. If you are working on project with others it allows you to
agree on common terms, and default meanings. You use typedefs and templates to
do this. I'm arguing that you should also do the same with common terms like
cout, vector and string. You are saying, for said project, "when I talk about a
vector, I mean std::vector".
There are probably projects where a different set of common terms could be
chosen - some engineering project where vector means
"fancy_numeric_library::vector", and not "std::vector". That's fine, as that is
the vocabulary for that project.
Having established the default terms in your project, you can use them
efficiently and tersely. And when you need to refer to some other similarly
named class, variable or concept, you can do some with explicit
qualification, as you are now referring to the exception and not the rule.
In my own code I use namespace directives to establish these common terms, and
use explicit qualification when I want to convey useful information - uncommonly
used library classes can benefit from qualification for example.
Another way I use explicit qualification to convey information is global
variables - in general globals should be avoided, but having some is useful, esp
when referring to program wide information. Program options is a common example.
I use a "namespace global { ... }" with those items, and in most code I
explicitly qualify their usage:
if( global::use_bitmap_caching == true ) { ... }
Of course I have some startup code that only deals with those globals, so I
either put all that code into a single cpp file and using a "using namespace
global", or (on other occasions) I put the "using" statement into the individual
functions. Function level using statements are very powerful and I find they
greatly aid both maintainability and readability.
Again, the thing I'm always aiming to do is convey useful information with
namespaces.
> In one post in this thread Thorsten suggested abstracting the smart
> pointer away with a typedef. That's actually a good idea, and I concede that
> that is a much better solution than the other things he suggested, or what
> you are suggesting.
I'm not so much for that, as shared_ptr already has well established and
understood semantics for C++ programmers. And the versions we are choosing
between in this case all have exactly the same semantics. I'm not sure a
pov_shared_ptr type is any clearer than a plain shared_ptr. To my mind, this is
a library management issue, not a functional one.
But its not bad either. This whole discussion isn't black and white - there is
no right or wrong. There are simply a set of choices, each of which can be
graded on multiple sets of criteria. Some choices may aid readability, but harm
maintainability for example. The community can then discuss the implications and
arrive at (hopefully, but not always, a) consensus decision about which choice
seems to have the most positive aspects versus negative ones.
> (Of course that doesn't mean that the "using namespace" statements are
> any more of a good idea. IMO they should be removed regardless of whether
> "shared_ptr" is abstracted away or not.)
I got that, yes. Hopefully you can see that I've got some reasons, whether or
not you agree with them, for my position as well.
Cheers,
Edouard.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 04.06.2010 00:07, schrieb Nicolas Alvarez:
> If he commits such a change, will you or Thorsten complain and/or revert it?
Let me put it this way: Justifying a rollback of someone's changes
requires much stronger arguments than making the change in the first place.
At any rate it would be Chris Cason who would have the last word on such
an issue, not me nor Thorsten.
But the question has become pretty much academic anyway, given that
Chris has already announced that he will be addressing the issue himself.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
