$include_dir="/home/hyper-archives/boost/include";
include("$include_dir/msg-header.inc")
?>
- Next message: Stewart, Robert: "Re: [boost] [lockfree review] rfc: naming and interface"
- Previous message: John Maddock: "Re: [boost] [C++0x] Emulate C++0x char16_t, char32_t, std::u16string, and std::u32string"
- In reply to: Antony Polukhin: "Re: [boost] [C++0x] Emulate C++0x char16_t, char32_t, std::u16string, and std::u32string"
- Next in thread: Artyom Beilis: "Re: [boost] [C++0x] Emulate C++0x char16_t, char32_t, std::u16string, and std::u32string"
> It is a bad approach, and will produce a lot of future workarounds. We
> can still remember wchar_t as a typedef for some compilers and a
> BOOST_NO_INTRINSIC_WCHAR_T macro for that defect.
>
> However some emulation for char16_t, char32_t types is required, but
> it must not be a typedef!
Then what's the alternative? IMO there just isn't one, given that char16_t
must be a literal type even on non-C++0x comilers.
John.
- Next message: Stewart, Robert: "Re: [boost] [lockfree review] rfc: naming and interface"
- Previous message: John Maddock: "Re: [boost] [C++0x] Emulate C++0x char16_t, char32_t, std::u16string, and std::u32string"
- In reply to: Antony Polukhin: "Re: [boost] [C++0x] Emulate C++0x char16_t, char32_t, std::u16string, and std::u32string"
- Next in thread: Artyom Beilis: "Re: [boost] [C++0x] Emulate C++0x char16_t, char32_t, std::u16string, and std::u32string"
$include_dir="/home/hyper-archives/boost/include";
include("$include_dir/msg-footer.inc");
?>