 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Fredrik Eriksson" <fe79}--at--{yahoo}--dot--{com> wrote:
> Why does the POV-Ray code blindly import whole namespaces anyway? There is
> a reason why 'using namespace' statements are considered poor practice.
> [...]
> Fully qualifying each and every reference to
> 'shared_ptr' (thank you, "Replace in files") of course fixes this
> particular problem.
I have to respectfully disagree - "using" statements, including "using
namespace", is not considered bad practice by everyone. Many experts feel that
"using" statements are in fact good engineering practice.
The beauty of the internet is that you can find as many experts as you want to
agree with any side of an argument.
I would argue that fully qualifying all types is much worse practice. Namespaces
are designed to manage these problems, otherwise you'd just embed all
definitions in a class called "std" instead. Namespaces give you more
sophisticated tools than your editors global find and replace dialog.
Cheers,
Edouard.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 01.06.10 00:00, Edouard wrote:
> 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.
Cool, I was looking for this but could not find it at any logical place (to
me) in the MSDN VC2010 documentation that is online. Do you have a reference
where to find it? Strangely, googling for "D_HAS_CPP0X" returns no results -
yet I thought all VC 2010 docs are online (I still have 2008, so i can't
check offline docs).
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> On 01.06.10 00:00, Edouard wrote:
>> /D_HAS_CPP0X=0
>
> Cool, I was looking for this but could not find it at any logical place
> (to me) in the MSDN VC2010 documentation that is online. Do you have a
> reference where to find it? Strangely, googling for "D_HAS_CPP0X" returns
> no results - yet I thought all VC 2010 docs are online (I still have 2008,
> so i can't check offline docs).
/D is a command-line switch. The macro is called _HAS_CPP0X.
http://www.google.com/search?q=_HAS_CPP0X
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 01.06.10 06:17, Nicolas Alvarez wrote:
> Thorsten Froehlich wrote:
>> On 01.06.10 00:00, Edouard wrote:
>>> /D_HAS_CPP0X=0
>>
>> Cool, I was looking for this but could not find it at any logical place
>> (to me) in the MSDN VC2010 documentation that is online. Do you have a
>> reference where to find it? Strangely, googling for "D_HAS_CPP0X" returns
>> no results - yet I thought all VC 2010 docs are online (I still have 2008,
>> so i can't check offline docs).
>
> /D is a command-line switch. The macro is called _HAS_CPP0X.
>
> http://www.google.com/search?q=_HAS_CPP0X
Ah, I have to admit I never used the command-line define of VC. Thanks for
the pointer!
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Edouard <pov### [at] edouard info> wrote:
> Many experts feel that
> "using" statements are in fact good engineering practice.
Experts of what? At least not in programming C++, that's for sure.
> I would argue that fully qualifying all types is much worse practice.
It would be interesting to hear those arguments.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> On 01.06.10 00:00, Edouard wrote:
> > 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.
> Cool, I was looking for this but could not find it at any logical place (to
> me) in the MSDN VC2010 documentation that is online. Do you have a reference
> where to find it? Strangely, googling for "D_HAS_CPP0X" returns no results -
> yet I thought all VC 2010 docs are online (I still have 2008, so i can't
> check offline docs).
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?
And what happens when the upcoming standard gets ratified and suddenly all
those compilers become standard (and hence you can't blame them anylonger)?
What if some of those compilers stop referring to "CPP0X" or alike, once
again breaking the compilation?
That solution is, simply put, a *kludge* to get around a design problem
which would have a very clear and clean solution.
After all, it's perfectly *ok* for there to exist a class named "shared_ptr"
inside the 'boost' namespace *and* the 'std' namespace. That's exactly what
namespaces exist for. If you pull everything out of those namespaces and
suddenly get naming collisions, the problem is not in the libraries. The
problem is in your code. It's the code which is broken. The libraries are
doing nothing wrong.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
