New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bugfix : c++11 on xcode #2335

Closed
elliotwoods opened this Issue Jul 24, 2013 · 69 comments

Comments

Projects
None yet
@elliotwoods
Contributor

elliotwoods commented Jul 24, 2013

Hey all!

[EDIT]
It seems that we don't have c++11 support right now with on osx.
The issue primarily is that we have to use libc++ with c++11, which does not support legacy tr1 namespace symbols. To fix this bug we need to write a c++11 version which does not use tr1 namespace.

This could either involve:

  1. Writing a win/linux/mac C++11 implementation without tr1
  2. Writing a special implementation for libc++ without tr1 for osx

I think the only difference between 1 and 2 is more testing is required for 1. (i.e. the code should look identical).

[/EDIT]

In ofTypes I edited:

#if (_MSC_VER)
#include <memory>
#else
#include <tr1/memory>
// import smart pointers utils into std
namespace std {
    using std::tr1::shared_ptr;
    using std::tr1::weak_ptr;
    using std::tr1::static_pointer_cast;
    using std::tr1::dynamic_pointer_cast;
    using std::tr1::const_pointer_cast;
    using std::tr1::enable_shared_from_this;
    using std::tr1::__dynamic_cast_tag;
}
#endif

to:

#if (_MSC_VER || true) // <----basically hacked here
#include <memory>
using std::shared_ptr;
#else
#include <tr1/memory>
// import smart pointers utils into std
namespace std {
    using std::tr1::shared_ptr;
    using std::tr1::weak_ptr;
    using std::tr1::static_pointer_cast;
    using std::tr1::dynamic_pointer_cast;
    using std::tr1::const_pointer_cast;
    using std::tr1::enable_shared_from_this;
    using std::tr1::__dynamic_cast_tag;
}
#endif

now i get complaints on __dynamic_cast_tag. And ran out of google results. ideas?

/Volumes/SHARED/openFrameworks/libs/openFrameworks/types/ofTypes.h:169:36: No type named '__dynamic_cast_tag' in namespace 'std'
@bilderbuchi

This comment has been minimized.

Show comment
Hide comment
@bilderbuchi

bilderbuchi Jul 24, 2013

Member

I'd start with this interesring if statement: #if (_MSC_VER || true) ;-) you can never enter the else clause.
also, pinging @LeoColomb about this, I think he was the author of this passage.
edit: wait, what? hmmm

Member

bilderbuchi commented Jul 24, 2013

I'd start with this interesring if statement: #if (_MSC_VER || true) ;-) you can never enter the else clause.
also, pinging @LeoColomb about this, I think he was the author of this passage.
edit: wait, what? hmmm

@elliotwoods

This comment has been minimized.

Show comment
Hide comment
@elliotwoods

elliotwoods Jul 24, 2013

Contributor

:) that's the bit i hacked
basically the VS2012 code seems to be proper C++11, whilst the rest is using tr1
therefore the switch should really be looking for C++11, not vs2012

Contributor

elliotwoods commented Jul 24, 2013

:) that's the bit i hacked
basically the VS2012 code seems to be proper C++11, whilst the rest is using tr1
therefore the switch should really be looking for C++11, not vs2012

@bilderbuchi

This comment has been minimized.

Show comment
Hide comment
@bilderbuchi

bilderbuchi Jul 24, 2013

Member

the switch should really be looking for C++11, not vs2012

on a second look I think I agree. but wouldn't the "proper" hack be to test for C++11 instead of true? :-)
also, @tgfrerer could know what's the proper course here.

Member

bilderbuchi commented Jul 24, 2013

the switch should really be looking for C++11, not vs2012

on a second look I think I agree. but wouldn't the "proper" hack be to test for C++11 instead of true? :-)
also, @tgfrerer could know what's the proper course here.

@bilderbuchi

This comment has been minimized.

Show comment
Hide comment
@bilderbuchi

This comment has been minimized.

Show comment
Hide comment
@bilderbuchi

bilderbuchi Jul 24, 2013

Member

wait, something is iffy. in your "original" version, where's the #if __cplusplus<201103L clause which is in current develop?

Member

bilderbuchi commented Jul 24, 2013

wait, something is iffy. in your "original" version, where's the #if __cplusplus<201103L clause which is in current develop?

@elliotwoods

This comment has been minimized.

Show comment
Hide comment
@elliotwoods

elliotwoods Jul 24, 2013

Contributor

ooh! i thought i was on recent develop since yesterday. i must have missed something. trying now!

Contributor

elliotwoods commented Jul 24, 2013

ooh! i thought i was on recent develop since yesterday. i must have missed something. trying now!

@bilderbuchi

This comment has been minimized.

Show comment
Hide comment
@bilderbuchi

bilderbuchi Jul 24, 2013

Member

OK possibly the problem here is just the tr1/memory include, which I think needs to select for C++11. Probably like this

#if __cplusplus < 201103L
#include <tr1/memory>
#else
#include <memory>
#endif

or so.

Member

bilderbuchi commented Jul 24, 2013

OK possibly the problem here is just the tr1/memory include, which I think needs to select for C++11. Probably like this

#if __cplusplus < 201103L
#include <tr1/memory>
#else
#include <memory>
#endif

or so.

@elliotwoods

This comment has been minimized.

Show comment
Hide comment
@elliotwoods

elliotwoods Jul 24, 2013

Contributor

to notes
__cplusplus < 201103L == true on xcode/libc++ c++11

[EDIT]
This is only true when using stdlibc++ becuase that doesn't have c++11 support. So this statement isn't entirely correct.
[/EDIT]

Contributor

elliotwoods commented Jul 24, 2013

to notes
__cplusplus < 201103L == true on xcode/libc++ c++11

[EDIT]
This is only true when using stdlibc++ becuase that doesn't have c++11 support. So this statement isn't entirely correct.
[/EDIT]

@bilderbuchi

This comment has been minimized.

Show comment
Hide comment
@bilderbuchi

bilderbuchi Jul 24, 2013

Member

what's the actual value of __cplusplus?

Member

bilderbuchi commented Jul 24, 2013

what's the actual value of __cplusplus?

@elliotwoods

This comment has been minimized.

Show comment
Hide comment
@elliotwoods

elliotwoods Jul 24, 2013

Contributor

the new code still doesn't work, also we shouldn't be using tr1 at all

#if __cplusplus<201103L
    using std::tr1::shared_ptr;
    using std::tr1::weak_ptr;
    using std::tr1::enable_shared_from_this;
#endif
    using std::tr1::static_pointer_cast;
    using std::tr1::dynamic_pointer_cast;
    using std::tr1::const_pointer_cast;
    using std::tr1::__dynamic_cast_tag;
}

still doesn't have a c++11 code path

Contributor

elliotwoods commented Jul 24, 2013

the new code still doesn't work, also we shouldn't be using tr1 at all

#if __cplusplus<201103L
    using std::tr1::shared_ptr;
    using std::tr1::weak_ptr;
    using std::tr1::enable_shared_from_this;
#endif
    using std::tr1::static_pointer_cast;
    using std::tr1::dynamic_pointer_cast;
    using std::tr1::const_pointer_cast;
    using std::tr1::__dynamic_cast_tag;
}

still doesn't have a c++11 code path

@bilderbuchi

This comment has been minimized.

Show comment
Hide comment
@bilderbuchi

bilderbuchi Jul 24, 2013

Member

It could be that this worked for now (i.e. with C++11 and stdlibc++) because according to the article I linked above, "Some standard library vendors have maintained the tr1 header files for backwards compatibility. Other vendors (such as libc++, which being c++11 only, has no backwards compatibility to worry about) do not."
So now that you are using libc++ this may have gotten exposed.

Member

bilderbuchi commented Jul 24, 2013

It could be that this worked for now (i.e. with C++11 and stdlibc++) because according to the article I linked above, "Some standard library vendors have maintained the tr1 header files for backwards compatibility. Other vendors (such as libc++, which being c++11 only, has no backwards compatibility to worry about) do not."
So now that you are using libc++ this may have gotten exposed.

@bilderbuchi

This comment has been minimized.

Show comment
Hide comment
@bilderbuchi

bilderbuchi Jul 24, 2013

Member

answers here to __cplusplus

that's not really an answer, though. what do you get when you run the program given in the accepted answer? for kicks, could you add a std::cout << __cplusplus << std::endl;, from here?

Member

bilderbuchi commented Jul 24, 2013

answers here to __cplusplus

that's not really an answer, though. what do you get when you run the program given in the accepted answer? for kicks, could you add a std::cout << __cplusplus << std::endl;, from here?

@elliotwoods

This comment has been minimized.

Show comment
Hide comment
@elliotwoods

elliotwoods Jul 24, 2013

Contributor

I have to setup a separate app (oF wont run in this configuration), and the result is 201103, which tallies with what we're currently using.

Contributor

elliotwoods commented Jul 24, 2013

I have to setup a separate app (oF wont run in this configuration), and the result is 201103, which tallies with what we're currently using.

@elliotwoods

This comment has been minimized.

Show comment
Hide comment
@elliotwoods

elliotwoods Jul 24, 2013

Contributor

to confirm, libc++ is required for using std::function.

Contributor

elliotwoods commented Jul 24, 2013

to confirm, libc++ is required for using std::function.

@bilderbuchi

This comment has been minimized.

Show comment
Hide comment
@bilderbuchi

bilderbuchi Jul 24, 2013

Member

to confirm, libc++ is required for using std::function.

you mean C++11, not libc++, right? std:function is also in stdlibc++. or is this not available on macos?

I'm sorry I can't help better, but without having macos or libc++ available, it's a bit hard to troubleshoot.

Member

bilderbuchi commented Jul 24, 2013

to confirm, libc++ is required for using std::function.

you mean C++11, not libc++, right? std:function is also in stdlibc++. or is this not available on macos?

I'm sorry I can't help better, but without having macos or libc++ available, it's a bit hard to troubleshoot.

@bilderbuchi

This comment has been minimized.

Show comment
Hide comment
@bilderbuchi

bilderbuchi Jul 24, 2013

Member

To summarize my thoughts, I think we have two (independent) issues here:

  1. For some reason, for __cplusplus < 201103L == true on OF xcode/libc++ C++11, while on a standalone program on the same machine __cplusplus=201103 as expected. This throws off our include logic for sure, and we should find out why it's wrong.
  2. saying using std::tr1::static_pointer_cast; etc. in a C++11 environment is strictly incorrect, but apparently OK when using some implementations (i.e. stdlibc++), but not others which don't provide backwards compatibility (i.e. libc++).
Member

bilderbuchi commented Jul 24, 2013

To summarize my thoughts, I think we have two (independent) issues here:

  1. For some reason, for __cplusplus < 201103L == true on OF xcode/libc++ C++11, while on a standalone program on the same machine __cplusplus=201103 as expected. This throws off our include logic for sure, and we should find out why it's wrong.
  2. saying using std::tr1::static_pointer_cast; etc. in a C++11 environment is strictly incorrect, but apparently OK when using some implementations (i.e. stdlibc++), but not others which don't provide backwards compatibility (i.e. libc++).
@elliotwoods

This comment has been minimized.

Show comment
Hide comment
@elliotwoods

elliotwoods Jul 24, 2013

Contributor

Correct re:not available on mac os, sorry to send those emails.
On XCode, libc++ is required for C++11:
image

Contributor

elliotwoods commented Jul 24, 2013

Correct re:not available on mac os, sorry to send those emails.
On XCode, libc++ is required for C++11:
image

@elliotwoods

This comment has been minimized.

Show comment
Hide comment
@elliotwoods

elliotwoods Jul 25, 2013

Contributor

To confirm:

  1. With oF / libc++ / XCode 4 / C++11, __cpluplus == 201103L
  2. For C++11 support on osx, we can't use tr1 namespace as libc++ is the only available library for this version.

I'll edit the bug at the top.

Contributor

elliotwoods commented Jul 25, 2013

To confirm:

  1. With oF / libc++ / XCode 4 / C++11, __cpluplus == 201103L
  2. For C++11 support on osx, we can't use tr1 namespace as libc++ is the only available library for this version.

I'll edit the bug at the top.

@bilderbuchi

This comment has been minimized.

Show comment
Hide comment
@bilderbuchi

bilderbuchi Jul 25, 2013

Member

thanks for the follow up. I'm wondering, with

  1. With oF / libc++ / XCode 4 / C++11, __cpluplus == 201103L

how was this possible:?

to notes
__cplusplus < 201103L == true on xcode/libc++ c++11

was there a configuration change or so between those two observations/comments?

Member

bilderbuchi commented Jul 25, 2013

thanks for the follow up. I'm wondering, with

  1. With oF / libc++ / XCode 4 / C++11, __cpluplus == 201103L

how was this possible:?

to notes
__cplusplus < 201103L == true on xcode/libc++ c++11

was there a configuration change or so between those two observations/comments?

@elliotwoods

This comment has been minimized.

Show comment
Hide comment
@elliotwoods

elliotwoods Jul 25, 2013

Contributor

I've updated the note above. I was getting __cplusplus == 201103L with libc++, and < 201103L with stdlibc++

Contributor

elliotwoods commented Jul 25, 2013

I've updated the note above. I was getting __cplusplus == 201103L with libc++, and < 201103L with stdlibc++

@bilderbuchi

This comment has been minimized.

Show comment
Hide comment
@bilderbuchi

bilderbuchi Jul 25, 2013

Member

I got a saner ifdef logic running nearly running on my machine now, with the exception of the dynamic_cast_tag which does not seem to exist on C++11 anymore.
@tgfrerer, who introduced this in 7712377: what is this about, and how do we make it work on C++11/libc++? (without touching TR1 I guess) A google search primarily points back to OF code ;-) I can't find any reference to it outside of tr/shared_ptr.h.

Member

bilderbuchi commented Jul 25, 2013

I got a saner ifdef logic running nearly running on my machine now, with the exception of the dynamic_cast_tag which does not seem to exist on C++11 anymore.
@tgfrerer, who introduced this in 7712377: what is this about, and how do we make it work on C++11/libc++? (without touching TR1 I guess) A google search primarily points back to OF code ;-) I can't find any reference to it outside of tr/shared_ptr.h.

@elliotwoods

This comment has been minimized.

Show comment
Hide comment
@elliotwoods

elliotwoods Jul 25, 2013

Contributor

Yep, changing the top section to:

#if (_MSC_VER || _LIBCPP_VERSION)
#include <memory>
#else

basically fixes everything except dynamic_tag

Contributor

elliotwoods commented Jul 25, 2013

Yep, changing the top section to:

#if (_MSC_VER || _LIBCPP_VERSION)
#include <memory>
#else

basically fixes everything except dynamic_tag

@bilderbuchi

This comment has been minimized.

Show comment
Hide comment
@bilderbuchi

bilderbuchi Jul 25, 2013

Member

What I got currently works for me on ubuntu/stdlibc++ except the dynamic_cast_tag. If we find out why VS wants different include path in C++98, we might even be able to get rid of that, too.

#if (_MSC_VER)
    #include <memory>
#else
    #if __cplusplus<201103L
        #include <tr1/memory>
        // import smart pointers utils into std
        namespace std {
            using std::tr1::shared_ptr;
            using std::tr1::weak_ptr;
            using std::tr1::enable_shared_from_this;
            using std::tr1::static_pointer_cast;
            using std::tr1::dynamic_pointer_cast;
            using std::tr1::const_pointer_cast;
            using std::tr1::__dynamic_cast_tag;
        }
    #else
        #include <memory>
        //still have to deal with __dynamic_cast_tag here!
    #endif
#endif
Member

bilderbuchi commented Jul 25, 2013

What I got currently works for me on ubuntu/stdlibc++ except the dynamic_cast_tag. If we find out why VS wants different include path in C++98, we might even be able to get rid of that, too.

#if (_MSC_VER)
    #include <memory>
#else
    #if __cplusplus<201103L
        #include <tr1/memory>
        // import smart pointers utils into std
        namespace std {
            using std::tr1::shared_ptr;
            using std::tr1::weak_ptr;
            using std::tr1::enable_shared_from_this;
            using std::tr1::static_pointer_cast;
            using std::tr1::dynamic_pointer_cast;
            using std::tr1::const_pointer_cast;
            using std::tr1::__dynamic_cast_tag;
        }
    #else
        #include <memory>
        //still have to deal with __dynamic_cast_tag here!
    #endif
#endif
@elliotwoods

This comment has been minimized.

Show comment
Hide comment
@elliotwoods

elliotwoods Jul 25, 2013

Contributor

This hack temporarily works:

#if (_MSC_VER)
    template<typename Tp1>
    ofPtr(const ofPtr<Tp1>& __r, std::_Dynamic_tag)
    : std::shared_ptr<T>(__r, std:::_Dynamic_tag()) { }
#elif (!_LIBCPP_VERSION)
    template<typename Tp1>
    ofPtr(const ofPtr<Tp1>& __r, std::__dynamic_cast_tag)
    : std::shared_ptr<T>(__r, std::__dynamic_cast_tag()) { }
#endif

Basically knock out the dynamic_tag bits when using LIBC

I presume there's a different approach to dynamic casting in c++11 in general.

Contributor

elliotwoods commented Jul 25, 2013

This hack temporarily works:

#if (_MSC_VER)
    template<typename Tp1>
    ofPtr(const ofPtr<Tp1>& __r, std::_Dynamic_tag)
    : std::shared_ptr<T>(__r, std:::_Dynamic_tag()) { }
#elif (!_LIBCPP_VERSION)
    template<typename Tp1>
    ofPtr(const ofPtr<Tp1>& __r, std::__dynamic_cast_tag)
    : std::shared_ptr<T>(__r, std::__dynamic_cast_tag()) { }
#endif

Basically knock out the dynamic_tag bits when using LIBC

I presume there's a different approach to dynamic casting in c++11 in general.

@bilderbuchi

This comment has been minimized.

Show comment
Hide comment
@bilderbuchi

bilderbuchi Jul 25, 2013

Member

but are you then not missing this template version/declaration on libc++, cause you get neither the MSC nor the "normal" version?

Member

bilderbuchi commented Jul 25, 2013

but are you then not missing this template version/declaration on libc++, cause you get neither the MSC nor the "normal" version?

@bilderbuchi

This comment has been minimized.

Show comment
Hide comment
@bilderbuchi

bilderbuchi Jul 25, 2013

Member

I'm guessing the C++11 way is via dynamic_pointer_cast http://www.cplusplus.com/reference/memory/dynamic_pointer_cast/

Member

bilderbuchi commented Jul 25, 2013

I'm guessing the C++11 way is via dynamic_pointer_cast http://www.cplusplus.com/reference/memory/dynamic_pointer_cast/

@elliotwoods

This comment has been minimized.

Show comment
Hide comment
@elliotwoods

elliotwoods Jul 25, 2013

Contributor

I'm sorry about the confusion before
This was because i wasn't setting the C++ dialect to C++11 :
image

Now it compiles, but bombs out on linking, with basically the entire standard library under complaint:
https://gist.github.com/elliotwoods/6081901 (clean rebuilds don't help)
Something else is going on here.

My app has the c++11 settings in the screenshot, and it doesn't matter if i compile openFrameworks with or without those flags set, i get the same linker errors (thought it might be a mismatch issue. might still be a mismatch issue with poco or something)

Contributor

elliotwoods commented Jul 25, 2013

I'm sorry about the confusion before
This was because i wasn't setting the C++ dialect to C++11 :
image

Now it compiles, but bombs out on linking, with basically the entire standard library under complaint:
https://gist.github.com/elliotwoods/6081901 (clean rebuilds don't help)
Something else is going on here.

My app has the c++11 settings in the screenshot, and it doesn't matter if i compile openFrameworks with or without those flags set, i get the same linker errors (thought it might be a mismatch issue. might still be a mismatch issue with poco or something)

@LeoColomb

This comment has been minimized.

Show comment
Hide comment
@LeoColomb

LeoColomb Jul 25, 2013

Member

I add my notes, because I have been pinged:

  • On VS2012, __cplusplus == 199711L.
  • On VS2013, it will be __cplusplus == 201103L.

With your last code, it should work with:

#if (__cplusplus<201103L && !(_MSC_VER))
#include <tr1/memory>
  // import smart pointers utils into std
  namespace std {
      using std::tr1::shared_ptr;
      using std::tr1::weak_ptr;
      using std::tr1::enable_shared_from_this;
      using std::tr1::static_pointer_cast;
      using std::tr1::dynamic_pointer_cast;
      using std::tr1::const_pointer_cast;
      using std::tr1::__dynamic_cast_tag;
  }
#else
#include <memory>
  //still have to deal with __dynamic_cast_tag here!
#endif

EDIT: Also, see this question.

Member

LeoColomb commented Jul 25, 2013

I add my notes, because I have been pinged:

  • On VS2012, __cplusplus == 199711L.
  • On VS2013, it will be __cplusplus == 201103L.

With your last code, it should work with:

#if (__cplusplus<201103L && !(_MSC_VER))
#include <tr1/memory>
  // import smart pointers utils into std
  namespace std {
      using std::tr1::shared_ptr;
      using std::tr1::weak_ptr;
      using std::tr1::enable_shared_from_this;
      using std::tr1::static_pointer_cast;
      using std::tr1::dynamic_pointer_cast;
      using std::tr1::const_pointer_cast;
      using std::tr1::__dynamic_cast_tag;
  }
#else
#include <memory>
  //still have to deal with __dynamic_cast_tag here!
#endif

EDIT: Also, see this question.

@tgfrerer

This comment has been minimized.

Show comment
Hide comment
@tgfrerer

tgfrerer Aug 2, 2013

Member

dynamic_pointer_cast allows you to cast an ofPtr from its parent type to one of its derived types, just like dynamic_cast (which is the preferred c++ style of dynamic pointer casting) does for raw pointers.

dyamic_cast_tag was an internal flag that some c++11 implementations used to signal that the shared ptr was going to be re-cast, and this is where it gets ugly, since some compilers/implementations used this flags, some didn't, and ofPtr, being essentially a façade around shared_ptr had to take all this into account.

in the short term, i'd suggest taking out the dynamic_pointer_cast functionality from ofPtr, since it does more bad than good, there real-life use-cases are rare and far-between, and it's proved being a maintainability nightmare.

in the long term, i'd suggest deprecating ofPtr in favour of shared_ptr and unique_ptr, since that will also give us more compatibility towards other libraries.

Member

tgfrerer commented Aug 2, 2013

dynamic_pointer_cast allows you to cast an ofPtr from its parent type to one of its derived types, just like dynamic_cast (which is the preferred c++ style of dynamic pointer casting) does for raw pointers.

dyamic_cast_tag was an internal flag that some c++11 implementations used to signal that the shared ptr was going to be re-cast, and this is where it gets ugly, since some compilers/implementations used this flags, some didn't, and ofPtr, being essentially a façade around shared_ptr had to take all this into account.

in the short term, i'd suggest taking out the dynamic_pointer_cast functionality from ofPtr, since it does more bad than good, there real-life use-cases are rare and far-between, and it's proved being a maintainability nightmare.

in the long term, i'd suggest deprecating ofPtr in favour of shared_ptr and unique_ptr, since that will also give us more compatibility towards other libraries.

@bilderbuchi

This comment has been minimized.

Show comment
Hide comment
@bilderbuchi

bilderbuchi Aug 5, 2013

Member

thanks for clearing this up @tgfrerer!
So, to make your short-term fix happen, we can just rip out https://github.com/openframeworks/openFrameworks/blob/develop/libs/openFrameworks/types/ofTypes.h#L186-L194 and https://github.com/openframeworks/openFrameworks/blob/develop/libs/openFrameworks/types/ofTypes.h#L205-L216, correct? Will this break project or have other negative repercussions we should note in the release notes etc?

Member

bilderbuchi commented Aug 5, 2013

thanks for clearing this up @tgfrerer!
So, to make your short-term fix happen, we can just rip out https://github.com/openframeworks/openFrameworks/blob/develop/libs/openFrameworks/types/ofTypes.h#L186-L194 and https://github.com/openframeworks/openFrameworks/blob/develop/libs/openFrameworks/types/ofTypes.h#L205-L216, correct? Will this break project or have other negative repercussions we should note in the release notes etc?

@ghost ghost assigned bilderbuchi Aug 5, 2013

@elliotwoods

This comment has been minimized.

Show comment
Hide comment
@elliotwoods

elliotwoods Aug 5, 2013

Contributor

To confirm, would this disallow casting an ofPtr of a class to/from a
parent type from/to a child type?

Contributor

elliotwoods commented Aug 5, 2013

To confirm, would this disallow casting an ofPtr of a class to/from a
parent type from/to a child type?

@tgfrerer

This comment has been minimized.

Show comment
Hide comment
@tgfrerer

tgfrerer Aug 5, 2013

Member

it would.

but then, you could always use a hack - grabbing the raw pointer from within ofPtr and re-casting that using raw pointer cast methods.

the preferred method for dynamic casting shared pointers would be to use shared_ptr instead of ofPtr in these cases, ofPtr doesn't really give you that much (apart from cross-compiler headaches) in more advanced use-cases, and with the advent of c++11 it will be much easier and future-proof to stick with the standard unique_ptr and shared_ptr.

Member

tgfrerer commented Aug 5, 2013

it would.

but then, you could always use a hack - grabbing the raw pointer from within ofPtr and re-casting that using raw pointer cast methods.

the preferred method for dynamic casting shared pointers would be to use shared_ptr instead of ofPtr in these cases, ofPtr doesn't really give you that much (apart from cross-compiler headaches) in more advanced use-cases, and with the advent of c++11 it will be much easier and future-proof to stick with the standard unique_ptr and shared_ptr.

@elliotwoods

This comment has been minimized.

Show comment
Hide comment
@elliotwoods

elliotwoods Aug 5, 2013

Contributor

ok understood.
can we therefore rewrite ofPtr for c++11 to wrap shared_ptr?

Contributor

elliotwoods commented Aug 5, 2013

ok understood.
can we therefore rewrite ofPtr for c++11 to wrap shared_ptr?

@tgfrerer

This comment has been minimized.

Show comment
Hide comment
@tgfrerer

tgfrerer Aug 5, 2013

Member

ofPtr already wraps shared_ptr =) but it's this wrapping - or better put: the façade design pattern - that causes the complications.

i think ofPtr was introduced to have a compiler and c++ version independent wrapper around shared_ptr. But now that shared_ptr has become part of the standard, why not use the real thing?

Member

tgfrerer commented Aug 5, 2013

ofPtr already wraps shared_ptr =) but it's this wrapping - or better put: the façade design pattern - that causes the complications.

i think ofPtr was introduced to have a compiler and c++ version independent wrapper around shared_ptr. But now that shared_ptr has become part of the standard, why not use the real thing?

@arturoc

This comment has been minimized.

Show comment
Hide comment
@arturoc

arturoc Aug 5, 2013

Member

it was even just to make it more of'ish :) i'm totally ok with removing
it once we have compatibility with c++11 and use the standard. meanwhile
can we perhaps deactivate the dynamic casting hack for vs on c++11 so
people can still use c++11 on that platform

i guess an ifdef around that code will do

On 08/05/2013 03:50 PM, Tim Gfrerer wrote:

ofPtr already wraps shared_ptr =) but it's this wrapping - or better
put: the façade design pattern - that causes the complications.

i think ofPtr was introduced to have a compiler and c++ version
independent wrapper around shared_ptr. But now that shared_ptr has
become part of the standard, why not use the real thing?


Reply to this email directly or view it on GitHub
#2335 (comment).

Member

arturoc commented Aug 5, 2013

it was even just to make it more of'ish :) i'm totally ok with removing
it once we have compatibility with c++11 and use the standard. meanwhile
can we perhaps deactivate the dynamic casting hack for vs on c++11 so
people can still use c++11 on that platform

i guess an ifdef around that code will do

On 08/05/2013 03:50 PM, Tim Gfrerer wrote:

ofPtr already wraps shared_ptr =) but it's this wrapping - or better
put: the façade design pattern - that causes the complications.

i think ofPtr was introduced to have a compiler and c++ version
independent wrapper around shared_ptr. But now that shared_ptr has
become part of the standard, why not use the real thing?


Reply to this email directly or view it on GitHub
#2335 (comment).

@tgfrerer

This comment has been minimized.

Show comment
Hide comment
@tgfrerer

tgfrerer Aug 5, 2013

Member

=) let's do it.

Member

tgfrerer commented Aug 5, 2013

=) let's do it.

@elliotwoods

This comment has been minimized.

Show comment
Hide comment
@elliotwoods

elliotwoods Aug 5, 2013

Contributor

C++11 works fine with VS and oF right now. Xcode is issue here

Contributor

elliotwoods commented Aug 5, 2013

C++11 works fine with VS and oF right now. Xcode is issue here

@arturoc

This comment has been minimized.

Show comment
Hide comment
@arturoc

arturoc Aug 5, 2013

Member

oh, ok, osx then :)

On 08/05/2013 04:01 PM, Elliot Woods wrote:

C++11 works fine with VS and oF right now. Xcode is issue here

Typed by touchscreen

On 5 Aug 2013, at 14:59, arturo notifications@github.com wrote:

it was even just to make it more of'ish :) i'm totally ok with removing
it once we have compatibility with c++11 and use the standard. meanwhile
can we perhaps deactivate the dynamic casting hack for vs on c++11 so
people can still use c++11 on that platform

i guess an ifdef around that code will do

On 08/05/2013 03:50 PM, Tim Gfrerer wrote:

ofPtr already wraps shared_ptr =) but it's this wrapping - or better
put: the façade design pattern - that causes the complications.

i think ofPtr was introduced to have a compiler and c++ version
independent wrapper around shared_ptr. But now that shared_ptr has
become part of the standard, why not use the real thing?


Reply to this email directly or view it on GitHub
<
https://github.com/openframeworks/openFrameworks/issues/2335#issuecomment-22107100>.


Reply to this email directly or view it on
GitHubhttps://github.com/openframeworks/openFrameworks/issues/2335#issuecomment-22107615

.


Reply to this email directly or view it on GitHub
#2335 (comment).

Member

arturoc commented Aug 5, 2013

oh, ok, osx then :)

On 08/05/2013 04:01 PM, Elliot Woods wrote:

C++11 works fine with VS and oF right now. Xcode is issue here

Typed by touchscreen

On 5 Aug 2013, at 14:59, arturo notifications@github.com wrote:

it was even just to make it more of'ish :) i'm totally ok with removing
it once we have compatibility with c++11 and use the standard. meanwhile
can we perhaps deactivate the dynamic casting hack for vs on c++11 so
people can still use c++11 on that platform

i guess an ifdef around that code will do

On 08/05/2013 03:50 PM, Tim Gfrerer wrote:

ofPtr already wraps shared_ptr =) but it's this wrapping - or better
put: the façade design pattern - that causes the complications.

i think ofPtr was introduced to have a compiler and c++ version
independent wrapper around shared_ptr. But now that shared_ptr has
become part of the standard, why not use the real thing?


Reply to this email directly or view it on GitHub
<
https://github.com/openframeworks/openFrameworks/issues/2335#issuecomment-22107100>.


Reply to this email directly or view it on
GitHubhttps://github.com/openframeworks/openFrameworks/issues/2335#issuecomment-22107615

.


Reply to this email directly or view it on GitHub
#2335 (comment).

@rezaali

This comment has been minimized.

Show comment
Hide comment
@rezaali

rezaali Sep 8, 2013

Contributor

any updates on this issue?

Contributor

rezaali commented Sep 8, 2013

any updates on this issue?

@bakercp

This comment has been minimized.

Show comment
Hide comment
@bakercp

bakercp Sep 8, 2013

Member

+1 to get this moving. Even if we aren't going to immediately remove ofPtr it would be really nice to get some preprocessor help to get the core / projects to compile c++11 running in the core easily.

Member

bakercp commented Sep 8, 2013

+1 to get this moving. Even if we aren't going to immediately remove ofPtr it would be really nice to get some preprocessor help to get the core / projects to compile c++11 running in the core easily.

@nervoussystem

This comment has been minimized.

Show comment
Hide comment
@nervoussystem

nervoussystem Sep 12, 2013

+1 Had the same issue with gcc in linux trying to use c++11 features not included in tr1 (like thread which is a super clean way to multithread functions). Got it working by eliminating dynamic_cast_tag, but it would be convenient to have a preprocessor flag to allow c++11 to work. I'll also second removing ofPtr in favor of shared_ptr. Using std library just seems better when possible.

nervoussystem commented Sep 12, 2013

+1 Had the same issue with gcc in linux trying to use c++11 features not included in tr1 (like thread which is a super clean way to multithread functions). Got it working by eliminating dynamic_cast_tag, but it would be convenient to have a preprocessor flag to allow c++11 to work. I'll also second removing ofPtr in favor of shared_ptr. Using std library just seems better when possible.

@elliotwoods

This comment has been minimized.

Show comment
Hide comment
@elliotwoods

elliotwoods Sep 12, 2013

Contributor

could we just typedef ofPtr to shared_ptr?

On 12 September 2013 10:48, Jesse Louis-Rosenberg
notifications@github.comwrote:

+1 Had the same issue with gcc in linux trying to use c++11 features not
included in tr1 (like thread which is a super clean way to multithread
functions). Got it working by eliminating dynamic_cast_tag, but it would be
convenient to have a preprocessor flag to allow c++11 to work. I'll also
second removing ofPtr in favor of shared_ptr. Using std library just seems
better when possible.


Reply to this email directly or view it on GitHubhttps://github.com/openframeworks/openFrameworks/issues/2335#issuecomment-24289787
.

Elliot Woods
elliot elliot@kimchiandchips.com@KimchiAndChips.comhttp://www.kimchiandchips.com/

Contributor

elliotwoods commented Sep 12, 2013

could we just typedef ofPtr to shared_ptr?

On 12 September 2013 10:48, Jesse Louis-Rosenberg
notifications@github.comwrote:

+1 Had the same issue with gcc in linux trying to use c++11 features not
included in tr1 (like thread which is a super clean way to multithread
functions). Got it working by eliminating dynamic_cast_tag, but it would be
convenient to have a preprocessor flag to allow c++11 to work. I'll also
second removing ofPtr in favor of shared_ptr. Using std library just seems
better when possible.


Reply to this email directly or view it on GitHubhttps://github.com/openframeworks/openFrameworks/issues/2335#issuecomment-24289787
.

Elliot Woods
elliot elliot@kimchiandchips.com@KimchiAndChips.comhttp://www.kimchiandchips.com/

@tgfrerer

This comment has been minimized.

Show comment
Hide comment
@tgfrerer

tgfrerer Sep 12, 2013

Member

It's hard (if not impossible) to typedef a template.

The next idea would be to use a preprocessor macro to substitute any mentions of ofPtr with shared_ptr, but this also is not un-tricky.

That said, if there was common interest in getting c++11 to run, how about we get together and make a branch (and ultimately a PR) where we concentrate our efforts (and findings)?

Member

tgfrerer commented Sep 12, 2013

It's hard (if not impossible) to typedef a template.

The next idea would be to use a preprocessor macro to substitute any mentions of ofPtr with shared_ptr, but this also is not un-tricky.

That said, if there was common interest in getting c++11 to run, how about we get together and make a branch (and ultimately a PR) where we concentrate our efforts (and findings)?

@bilderbuchi

This comment has been minimized.

Show comment
Hide comment
@bilderbuchi

bilderbuchi Sep 12, 2013

Member

forgive my ignorance, but something like this is not an option?
Also, might as well wrap ofPtr in a deprecation macro at the same time, if we want to phase it out anyway.

Member

bilderbuchi commented Sep 12, 2013

forgive my ignorance, but something like this is not an option?
Also, might as well wrap ofPtr in a deprecation macro at the same time, if we want to phase it out anyway.

@elliotwoods

This comment has been minimized.

Show comment
Hide comment
@elliotwoods

elliotwoods Sep 12, 2013

Contributor

can somebody explain why we made ofPtr in the first place? it seems that there is a a little bit of confusion as to why it exists
it looks prettier than shared_ptr, which I think is the only reason i use it.

Contributor

elliotwoods commented Sep 12, 2013

can somebody explain why we made ofPtr in the first place? it seems that there is a a little bit of confusion as to why it exists
it looks prettier than shared_ptr, which I think is the only reason i use it.

@elliotwoods

This comment has been minimized.

Show comment
Hide comment
@elliotwoods

elliotwoods Sep 12, 2013

Contributor

On that Stack Overflow post:

The catch is that nobody supports it yet. GCC has a patch available, but it probably won't make it into mainline until 4.7.

that was in 2011 (it's a C++0x feature)

I presume that compilers in the C++11 regime will be fine with it, if so, we could switch to template alias for C++11 compilers, and stick with existing tr1 implementation for previous?

Contributor

elliotwoods commented Sep 12, 2013

On that Stack Overflow post:

The catch is that nobody supports it yet. GCC has a patch available, but it probably won't make it into mainline until 4.7.

that was in 2011 (it's a C++0x feature)

I presume that compilers in the C++11 regime will be fine with it, if so, we could switch to template alias for C++11 compilers, and stick with existing tr1 implementation for previous?

@tgfrerer

This comment has been minimized.

Show comment
Hide comment
@tgfrerer

tgfrerer Sep 12, 2013

Member

@elliotwoods as @arturoc explains earlier, it was made to make shared pointers more "oF-ish": #2335 (comment)

@bilderbuchi The key would be to make things simpler, and more standards-compliant, which is why I'm strongly in favour of ditching ofPtr. I fear the stackoverflow method adds another layer of "wrapping paper," which we don't really need.

The current problem with ofPtr imho is that it's a cross compiler maintenance headache waiting to happen, and not compatible with standards-compliant APIs that use shared_ptr. In short: it is complicated code where it doesn't need to be.

Member

tgfrerer commented Sep 12, 2013

@elliotwoods as @arturoc explains earlier, it was made to make shared pointers more "oF-ish": #2335 (comment)

@bilderbuchi The key would be to make things simpler, and more standards-compliant, which is why I'm strongly in favour of ditching ofPtr. I fear the stackoverflow method adds another layer of "wrapping paper," which we don't really need.

The current problem with ofPtr imho is that it's a cross compiler maintenance headache waiting to happen, and not compatible with standards-compliant APIs that use shared_ptr. In short: it is complicated code where it doesn't need to be.

@elliotwoods

This comment has been minimized.

Show comment
Hide comment
@elliotwoods

elliotwoods Sep 12, 2013

Contributor

cheers @tgfrerer

what i've learned from this thread:

Don't use ofPtr it's bad for business

Contributor

elliotwoods commented Sep 12, 2013

cheers @tgfrerer

what i've learned from this thread:

Don't use ofPtr it's bad for business

@bilderbuchi

This comment has been minimized.

Show comment
Hide comment
@bilderbuchi

bilderbuchi Sep 12, 2013

Member

The key would be to make things simpler, and more standards-compliant, which is why I'm strongly in favour of ditching ofPtr.

sure, me too, but to ease user transitions we normally try to deprecate first before we fully remove, and for that we'd need (optimally) a typedef. ;-)

maintenance headache waiting to happen

what do you mean, "waiting"? This issue discussion is the best proof that the headache is already happening... :P

Member

bilderbuchi commented Sep 12, 2013

The key would be to make things simpler, and more standards-compliant, which is why I'm strongly in favour of ditching ofPtr.

sure, me too, but to ease user transitions we normally try to deprecate first before we fully remove, and for that we'd need (optimally) a typedef. ;-)

maintenance headache waiting to happen

what do you mean, "waiting"? This issue discussion is the best proof that the headache is already happening... :P

@tgfrerer

This comment has been minimized.

Show comment
Hide comment
@tgfrerer

tgfrerer Sep 19, 2013

Member

Just to keep you posted on progress - I got openFrameworks to compile + link on XCode with libc++ and std=c++11 i.e. "full, modern, clang-based c++11", with glorious move semantics, lambdas etc.

The downside is that I had to recompile POCO (1.4) and Freeimage (3.15.3), since these libraries seem to call into regions of the STL implementation where clang and GNU differ in signatures.

I made notes of all the steps necessary to compile.

  • Poco was relatively trivial, since it comes with it's own makefile recipe to build with libc++/clang
  • Freeimage needed a bit of tweaking, if only for a couple of bugs that needed fixing (a couple of signed chars are assigned values > 128 for example) to make clang compile.

I'd like to make this accessible to others and wonder how it could feed in to the openFrameworks "c++11 roadmap", maybe @kylemcdonald @arturoc could you remind me of what's planned and how best to contribute?

I've only so far had a chance to compile the core & run a basic image loading example (all fine, no leaks or other 'surprises'), and will throw some more tests at it tomorrow, I think.

I also wonder if there is a way to compile these two libraries so that they are compatible with either standard library on OS X.

I'd love to see a transition to c++11 in the close or distant future, as it makes c++ easier to read & learn for beginners and more expressive and powerful for regulars.

If you haven't yet, and are interested in c++11, watch: http://channel9.msdn.com/Events/GoingNative/2013/Opening-Keynote-Bjarne-Stroustrup for a table firework of well-aimed superhydrophobic humour with a Swedish twang.

Member

tgfrerer commented Sep 19, 2013

Just to keep you posted on progress - I got openFrameworks to compile + link on XCode with libc++ and std=c++11 i.e. "full, modern, clang-based c++11", with glorious move semantics, lambdas etc.

The downside is that I had to recompile POCO (1.4) and Freeimage (3.15.3), since these libraries seem to call into regions of the STL implementation where clang and GNU differ in signatures.

I made notes of all the steps necessary to compile.

  • Poco was relatively trivial, since it comes with it's own makefile recipe to build with libc++/clang
  • Freeimage needed a bit of tweaking, if only for a couple of bugs that needed fixing (a couple of signed chars are assigned values > 128 for example) to make clang compile.

I'd like to make this accessible to others and wonder how it could feed in to the openFrameworks "c++11 roadmap", maybe @kylemcdonald @arturoc could you remind me of what's planned and how best to contribute?

I've only so far had a chance to compile the core & run a basic image loading example (all fine, no leaks or other 'surprises'), and will throw some more tests at it tomorrow, I think.

I also wonder if there is a way to compile these two libraries so that they are compatible with either standard library on OS X.

I'd love to see a transition to c++11 in the close or distant future, as it makes c++ easier to read & learn for beginners and more expressive and powerful for regulars.

If you haven't yet, and are interested in c++11, watch: http://channel9.msdn.com/Events/GoingNative/2013/Opening-Keynote-Bjarne-Stroustrup for a table firework of well-aimed superhydrophobic humour with a Swedish twang.

@LeoColomb LeoColomb referenced this issue Sep 19, 2013

Merged

Feature Visual Studio 2013 - WIP #2571

4 of 7 tasks complete
@bakercp

This comment has been minimized.

Show comment
Hide comment
@bakercp

bakercp Sep 19, 2013

Member

This is great. I'd say start a public branch, or (as we are doing with arm

Member

bakercp commented Sep 19, 2013

This is great. I'd say start a public branch, or (as we are doing with arm

@bakercp bakercp closed this Sep 19, 2013

@elliotwoods

This comment has been minimized.

Show comment
Hide comment
@elliotwoods

elliotwoods Sep 20, 2013

Contributor

@tgfrerer - any way to get a copy for testing and personal use?

i don:t think we should close this issue since it is not yet solved
@bakercp - did you intend to close?

Contributor

elliotwoods commented Sep 20, 2013

@tgfrerer - any way to get a copy for testing and personal use?

i don:t think we should close this issue since it is not yet solved
@bakercp - did you intend to close?

@bakercp bakercp reopened this Sep 20, 2013

@bakercp

This comment has been minimized.

Show comment
Hide comment
@bakercp

bakercp Sep 20, 2013

Member

Sorry. Close was an accident! I'm extremely excited about C++11 ... :)

Looks like my last message was half-a-message too.

What I was saying is that for some of this kind of larger stuff it can be useful to create an organization and get more people involved in the commit / merge process. We did this w/ RPI and it worked well and more people take ownership when they can commit.

We just started another collection point for arm work over here that is more generic.

https://github.com/openframeworks-arm/

Anyway, just an idea if it c++11 is going to require updated libraries, etc etc. Like RPi, it's easy to pull in the work into the core from other orgs as it matures.

Member

bakercp commented Sep 20, 2013

Sorry. Close was an accident! I'm extremely excited about C++11 ... :)

Looks like my last message was half-a-message too.

What I was saying is that for some of this kind of larger stuff it can be useful to create an organization and get more people involved in the commit / merge process. We did this w/ RPI and it worked well and more people take ownership when they can commit.

We just started another collection point for arm work over here that is more generic.

https://github.com/openframeworks-arm/

Anyway, just an idea if it c++11 is going to require updated libraries, etc etc. Like RPi, it's easy to pull in the work into the core from other orgs as it matures.

@tgfrerer

This comment has been minimized.

Show comment
Hide comment
@tgfrerer

tgfrerer Sep 20, 2013

Member

Sweet! I've opened an org as this seems the least messy way to get libraries to recompile - plus, we can share our recompilation war-stories on the organisation wiki!

https://github.com/organizations/openFrameworks-cpp11

The current version on there should work, and I've also managed to "port" the project generator.

I've also opened a wiki page on there, about where to get & how to compile the libraries, which we might eventually want to feed into the "official" libraries compilation wiki.

https://github.com/openFrameworks-cpp11/openFrameworks/wiki/compiling-libraries-for-libc,-clang,-c--11

At the moment I'm trying to figure out where to find the correct source code versions for the libraries - is this documented somewhere?

Member

tgfrerer commented Sep 20, 2013

Sweet! I've opened an org as this seems the least messy way to get libraries to recompile - plus, we can share our recompilation war-stories on the organisation wiki!

https://github.com/organizations/openFrameworks-cpp11

The current version on there should work, and I've also managed to "port" the project generator.

I've also opened a wiki page on there, about where to get & how to compile the libraries, which we might eventually want to feed into the "official" libraries compilation wiki.

https://github.com/openFrameworks-cpp11/openFrameworks/wiki/compiling-libraries-for-libc,-clang,-c--11

At the moment I'm trying to figure out where to find the correct source code versions for the libraries - is this documented somewhere?

@rraallvv

This comment has been minimized.

Show comment
Hide comment
@rraallvv

rraallvv Jan 5, 2014

Is this fixed in the trunk?

rraallvv commented Jan 5, 2014

Is this fixed in the trunk?

@bilderbuchi

This comment has been minimized.

Show comment
Hide comment
@bilderbuchi

bilderbuchi Jan 5, 2014

Member

Not afaik, this is still ongoing, see the comment above yours.

Member

bilderbuchi commented Jan 5, 2014

Not afaik, this is still ongoing, see the comment above yours.

@bakercp

This comment has been minimized.

Show comment
Hide comment
@bakercp

bakercp Jan 18, 2014

Member

related #2764

Member

bakercp commented Jan 18, 2014

related #2764

@oblitum

This comment has been minimized.

Show comment
Hide comment
@oblitum

oblitum May 2, 2014

Just installed OF and sadly I'm hit by this ;_; Even if I use Ubuntu, I like to use clang and libc++ here, and it works fine for everything except this. I have an awesome code completion too, with YouCompleteMe and libclang on VIM, but also, I can't get proper completion because completion is through clang and libc++ for me, and this ofTypes.h file is an issue, it can't compile and prevents me from having proper completion too.

oblitum commented May 2, 2014

Just installed OF and sadly I'm hit by this ;_; Even if I use Ubuntu, I like to use clang and libc++ here, and it works fine for everything except this. I have an awesome code completion too, with YouCompleteMe and libclang on VIM, but also, I can't get proper completion because completion is through clang and libc++ for me, and this ofTypes.h file is an issue, it can't compile and prevents me from having proper completion too.

@oblitum

This comment has been minimized.

Show comment
Hide comment
@oblitum

oblitum May 2, 2014

my opinion: I'm all for c++11 and beyond and elimination of duplicated data-structures (extra smart pointers et. al.).

oblitum commented May 2, 2014

my opinion: I'm all for c++11 and beyond and elimination of duplicated data-structures (extra smart pointers et. al.).

@oblitum

This comment has been minimized.

Show comment
Hide comment
@oblitum

oblitum May 2, 2014

I have just sticked to stdlibc++ for now ... =/

oblitum commented May 2, 2014

I have just sticked to stdlibc++ for now ... =/

@minusplusminus

This comment has been minimized.

Show comment
Hide comment

minusplusminus commented May 2, 2014

:(

@MattijsKneppers

This comment has been minimized.

Show comment
Hide comment
@MattijsKneppers

MattijsKneppers May 30, 2014

Contributor

hey all, I was getting all excited about using lambda functions in a new project. But reading this it seems I should forget that for now.. :p Big +1 to fixing this!

Contributor

MattijsKneppers commented May 30, 2014

hey all, I was getting all excited about using lambda functions in a new project. But reading this it seems I should forget that for now.. :p Big +1 to fixing this!

@elliotwoods

This comment has been minimized.

Show comment
Hide comment
@elliotwoods

elliotwoods May 31, 2014

Contributor

Well to confirm
This is fixed by @tgfrerer above. Tested here and using as my main Dev environment (using same branch on windows and mac).

Now we just need to merge it at the right time.

The right time is basically a 'lay period' because merging this breaks some addons (libs need recompile) but is inevitable for the future.

I think we should make the jump and move forwards, but that's because I use lambada a lot.

I can see why keeping backwards comparability and forgoeing modern language features is attractive to many.

Essentially when we merge this, we're basically going to break a lot of things. So either:

  1. Find really smart ways of this not breaking some things
  2. Find the right time to bite the bullet
  3. Delay for a while, exasperating the problem for later but avoiding the problem for now
  4. Some magic c++11 version of stdlibc++ exists for XCode (sounds like trouble, but we might not be the only people in this boat)

Ideally we would have known this in advance somehow. No chance to get somebody from apple on board with this?

Contributor

elliotwoods commented May 31, 2014

Well to confirm
This is fixed by @tgfrerer above. Tested here and using as my main Dev environment (using same branch on windows and mac).

Now we just need to merge it at the right time.

The right time is basically a 'lay period' because merging this breaks some addons (libs need recompile) but is inevitable for the future.

I think we should make the jump and move forwards, but that's because I use lambada a lot.

I can see why keeping backwards comparability and forgoeing modern language features is attractive to many.

Essentially when we merge this, we're basically going to break a lot of things. So either:

  1. Find really smart ways of this not breaking some things
  2. Find the right time to bite the bullet
  3. Delay for a while, exasperating the problem for later but avoiding the problem for now
  4. Some magic c++11 version of stdlibc++ exists for XCode (sounds like trouble, but we might not be the only people in this boat)

Ideally we would have known this in advance somehow. No chance to get somebody from apple on board with this?

@elliotwoods

This comment has been minimized.

Show comment
Hide comment
@elliotwoods

elliotwoods May 31, 2014

Contributor

here's my suggestion.
please let's discuss this

Let's do for osx:

  • 32bit / stdlibc++ / c++98
  • 64bit / libc++ / c++11

the reason for this is switching to 64bit or switching to c++11 breaks lots of addons and core libs. so let's only do this once before we fragment the code base that we have out there.

Contributor

elliotwoods commented May 31, 2014

here's my suggestion.
please let's discuss this

Let's do for osx:

  • 32bit / stdlibc++ / c++98
  • 64bit / libc++ / c++11

the reason for this is switching to 64bit or switching to c++11 breaks lots of addons and core libs. so let's only do this once before we fragment the code base that we have out there.

@kylemcdonald kylemcdonald added this to the 0.9.0 milestone Jun 1, 2014

@kylemcdonald

This comment has been minimized.

Show comment
Hide comment
@kylemcdonald

kylemcdonald Jun 1, 2014

Contributor

i think we're all in agreement elliot, just milestoned this for 0.9.0

Contributor

kylemcdonald commented Jun 1, 2014

i think we're all in agreement elliot, just milestoned this for 0.9.0

@elliotwoods

This comment has been minimized.

Show comment
Hide comment
@elliotwoods

elliotwoods Jun 2, 2014

Contributor

thanks for bringing this up in the irc meeting.

Contributor

elliotwoods commented Jun 2, 2014

thanks for bringing this up in the irc meeting.

@kylemcdonald

This comment has been minimized.

Show comment
Hide comment
@kylemcdonald

kylemcdonald Sep 6, 2014

Contributor

closing this in favor of #3039 which has a clearer checklist.

Contributor

kylemcdonald commented Sep 6, 2014

closing this in favor of #3039 which has a clearer checklist.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment