- Boost - lists.boost.org

[type_traits] is_enum on scoped enums doesn't works as expected
by Vicente J. Botet Escriba 25 Aug '11

25 Aug '11

Hi, The following file fails to compile under clang 2.9 c++0x #include <boost/static_assert.hpp> #include <boost/type_traits/is_enum.hpp> enum E {E_a,E_b,E_c}; BOOST_STATIC_ASSERT((boost::is_enum<E>::value)); enum class EC {a,b,c}; BOOST_STATIC_ASSERT((boost::is_enum<EC>::value)); //#include <type_traits> The command line and error is "/Users/viboes/clang/clang+llvm-2.9/bin/clang++" -x c++ -std=c++0x -O0 -g -Wextra -Wno-long-long -pedantic -O0 -fno-inline -Wall -pedantic -g -DBOOST_ALL_NO_LIB=1 -DBOOST_CONVERSION_DOUBLE_CP -DBOOST_ENABLE_WARNINGS -I"." -I"../../.." -c -o "../../../bin.v2/libs/enums/test/is_enum_pass.test/clang-darwin-2.9x/debug/is_enum_pass.o" "enum_class/is_enum_pass.cpp" enum_class/is_enum_pass.cpp:7:1: error: static_assert failed "(boost::is_enum<EC>::value)" BOOST_STATIC_ASSERT((boost::is_enum<EC>::value)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from enum_class/is_enum_pass.cpp:1: Am I missing something evident? Is this a known bug of is_enum? BTW, I have tried to use directly the type_traits standard file and my build configuration is unable to find it. enum_class/is_enum_pass.cpp:9:10: fatal error: 'type_traits' file not found #include <type_traits> Which is the default library when buildding with Boost.Build (bjam) and clang 2.9 c++0x? Best, Vicente

6 11

Re: [boost] Query for interest in including a shim class converting between char*, wchar_t*, string, wstring
by Zhi Tan 25 Aug '11

25 Aug '11

> > From: Yakov Galka <ybungalobill(a)gmail.com> > > On Thu, Aug 25, 2011 at 12:11, Tan, Tom (Shanghai) <TTan(a)husky.ca> wrote: > > > As a C++ programmer, often times there's a need to widen or narrow a > > string to match some 3rd APIs. After writing similar code again and > > again, I decided to have a wrapper to simplify this trivial but frequent > > work, hence the TR and TR2 class. Features include: > > > > If something fails to compile, there must be a reason. Just shutting up the > compiler doesn't make your code correct. What you're doing is like > reinterpret_casting an int to float... > no reinterpret_casting is involved here. it's just a wrapping of one of basic_string's standard constructors. template<class InputIterator> string (InputIterator begin, InputIterator end) template<class InputIterator> wstring (InputIterator begin, InputIterator end) and this usage is a distorted usage. > [...] > > - Many Boost libraries (e.g. Boost.Test) that output plain > > English (ASCII) message literals can be easily extended to support both > > wide-char version with this class. > > > > They don't have to support wide-char. Many programmers are not interested > in > any wide-char support at all. See > > http://programmers.stackexchange.com/questions/102205/should-utf-16-be-cons… > As explicitly stated below, it does not have anything to to with any encoding/decoding of UNICODE and the like. It only does widening and narrowing of *plain ACSII Engish text*, where the operation does not change the meaning and readability of the literals. I can understand how some people can live without wide-char all life by living in a culture where wide-char is not needed(e.g. English speaking countries), or in a tech culture where UTF8 is used(Linux). But I happen to live in a culture(Chinese language) where 16-byte wide-chars are a matter of fact and easier to use. The default on Windows(UTF16) is implemented on wide-char too. I believe there are many out there like me facing cases where *widening *the English text is only need and correct enough. While the scope is very specific, the need is real. Think of std::exception class exception {public: exception () throw(); exception (const exception&) throw(); exception& operator= (const exception&) throw(); virtual ~exception() throw(); virtual const char* what() const throw(); } exception::what() only returns narrow chars, many exception-derived classes only provide simple English message too, where widening is necessary my wide-char app. The same goes to Boost Informational Macros <http://www.boost.org/doc/libs/1_47_0/libs/config/doc/html/boost_config/boos…>, and compiler predefined macros. Do not mistake it as a solution to endcodings or locale, rather, it's a solution between char* and wchar_t*, when you know the operation is safe, which is usually the case of writing libraries, where messages are in short and plain ASCII English literals. > - The 2 classes do not involve any encoding/decoding. > > > > tr.hpp: > > > * N.B. it doe not do any code conversion like: MBCS <--> UNICODE > > > > This is just wrong. Your code is useless as it doesn't solve any real > problem. This is not going to be accepted to boost, especially since it > misguides programmers to write Unicode incorrect and *broken* code. Yes, > you > may find this library useful, and, say, half of non-expert programmers will > find this library useful. The sad thing is that most of them just don't > understand what Unicode is or what's text at all. > see above. This is NOT a code conversion solution, rather, a wrapping of standard C++ solution for a real need. > > Btw, you're not the first to propose some kind of tools for 'Unicode > support'. I can count at least 4 other proposals trying to solve different > aspects by different means. None of them was accepted to boost yet. > > -- > Yakov > > >

1 0

Re: [boost] Query for interest in including a shim class converting between char*, wchar_t*, string, wstring
by Zhi Tan 25 Aug '11

25 Aug '11

> > Date: Thu, 25 Aug 2011 11:24:59 +0200 > From: Sebastian Redl <sebastian.redl(a)getdesigned.at> > > On 25.08.2011 11:11, Tan, Tom (Shanghai) wrote: > > - The name TR is inspired from QT' tr() macro. > > > Qt's tr() stands for "translate" because that thing is the entry point > for Qt's localization/message catalog system. In other words, you use > tr() only for user-visible string that should get translated. That makes > it a poor inspiration for something that is concerned with encoding > conversion. > > Sebastian > I am aware this is not translation, but I like the shortness of tr(). One of the things I am expecting from the community is a proper naming. Vicente Botet renamed it to be adaptive_string, but it seems too long for me to type. Wile I am typing, it occurs to me as() might be a better name.

1 0

Query for interest in including a shim class converting between char*, wchar_t, string, wstring
by Tan, Tom (Shanghai) 25 Aug '11

25 Aug '11

As a C++ programmer, often times there's a need to widen or narrow a string to match some 3rd APIs. After writing similar code again and again, I decided to have a wrapper to simplify this trivial but frequent work, hence the TR and TR2 class. Features include: - Each class serves as a shim between wide-char and marrow-char string types. It accepts a std::basic_string type or C-style literal, returns a std::basic_string type or streamming to std::basic_ostream according to the context(e.g. type on the left side of '=' operator): - 2 classes o Non-template class TR: convenient and intuitive interface, e.g. std::string s = TR(L"hello"); std::wstring s = TR("hello"); o template class TR2<SourceRange>: more verbose but faster e.g. std::string s = TR2<const wchar_t*>(L"hello"); std::wstring s = TR2<const char*>("hello"); - Many Boost libraries (e.g. Boost.Test) that output plain English (ASCII) message literals can be easily extended to support both wide-char version with this class. - The 2 classes do not involve any encoding/decoding. - The name TR is inspired from QT' tr() macro. If there's enough interest, I am ready to improve the code, including renaming, style cleaning, documenting and compiler testing etc, for a final inclusion. And I also would like to have a mentor to guide me through as I've never submitted any code to boost before. This class started as some test code snippet for boost.chrono while exchanging ideas with Vicente J. Botet Escriba. One major improvement since then is that the conversion is bi-directional now..

3 2

[type traits] Extension to operator detection -> choose your preferred naming
by Brent Spillner 25 Aug '11

25 Aug '11

On 8/24/2011 07:23 Frederic Bron wrote: > Please give your preference between A, B and C before Sept. 5th. Of these three choices, I think C is easiest to live with. However, if you're going to have has_unary_plus I think the symmetry of has_unary_minus is preferable to has_negate, and I continue to believe that an additional has_operator<Tag, TypeA, TypeB> (or can_call_operator<>) should be provided for use in more generic code (e.g. forwarding ETs from a higher level without caring exactly which operators are involved.) Brent

1 0

[Conversion] Practical applications
by Phil Endecott 25 Aug '11

25 Aug '11

Dear Vicente & others, Would anyone like to share any practical or motivating applications for the proposed Boost.Conversion library? It seems to me that there are practical applications for particular types of conversion, e.g. T-to-string and string-to-T, and numeric casts, and serialisation. Apart from that, I am having trouble seeing practical reasons for generic conversion. A motivating case would be if a generic algorithm required conversion, but in the cases that I can think of either (a) the generic algorithm takes a functor, so the caller can pass the currently-required conversion as part of a lambda expression, or (b) you might need to select one of several possible conversions between a pair of types, which this library can't do, or (c) the algorithms are std:: ones which won't work with this library anyway. Example: struct person { string firstname; string surname; }; vector<person> people; // sorted by firstname // Try to find everyone with firstname "John": std::equal_range(people.begin(),people.end(),"John"); That doesn't work. Making it work has always struck me as more difficult than it should be. Can this library make it easier? If not, what similar problems can it help with? Regards, Phil.

6 12

[gsoc] Final evaluations
by Andrew Sutton 25 Aug '11

25 Aug '11

Mentors, Please don't forget to submit your final evaluations. You must submit the evaluation before August 26. Thanks, Andrew

1 0

Re: [boost] [Containers] Marshalling deques
by Brian Wood 24 Aug '11

24 Aug '11

Ion Gazta?aga: El 24/08/2011 20:06, Brian Wood escribi?: >> >> If I could get the number of elements in the first chunk and the >> size of the chunks, that would be sufficient. (I believe the size >> of the chunks is constant within a deque instance.) > > Not necessarily, but I think all implementations do that. The question > is whether we should have a standard-friendly and implementation > agnostic interface or an interface just for boost::deque implementation. How about both? First a boost::deque implementation and then if someone is inclined to delve into this further a more general implementation that might replace the earlier implementation. Since this wasn't addressed by C++11, I'm not sure how long it will take to get attention. If the interface we come up with has weaknesses, someone else will figure out how to improve upon it. Regards, Brian Wood Ebenezer Enterprises http://webEbenezer.net

1 0

[interest] underlying type library
by Julian Gonggrijp 24 Aug '11

24 Aug '11

Dear Boost developers, std::swap is commonly implemented by copying the arguments. For non-POD types this can be very inefficient. Two solutions are available. The first option, which is commonly employed, is to manually override std::swap for every non-POD type, making use of the implementation details of the type. The other option is to provide a library which makes it possible to implement the swap algorithm once, in a way that is efficient for any type (POD or non-POD), and which works even if a type isn't copyable. The latter is what I'll be proposing here. Back in March, Vicente Botet posted a link to the highly inspiring 'Notes on Programming' by Alexander Stepanov [1]. Lectures 4 and 5 cover the (hypothetical) move_raw algorithm and the (hypothetical) UNDERLYING_TYPE type function, as well as their relevance to the swap algorithm. I'll try to reproduce the essential points of this discussion below. move_raw(s, t) moves the value of s to t. t is guaranteed to be left in a valid state but s isn't. In particular, the destruction of s might corrupt t because they point to the same additional resources. Another move operation into s, say, move_raw(r, s) will however restore s into a new valid state. UNDERLYING_TYPE(T) represents a type which is (conceptually speaking) a POD-type with the same member data (and hence the same alignment) as T. The underlying type can be used to allocate space for a T object and to temporarily store the state of a T object. Using move_raw and UNDERLYING_TYPE, a swap algorithm can be implemented which works and is efficient for any type: template <class T> void swap (T& x, T& y) { UNDERLYING_TYPE(T) temp; move_raw (x, temp); move_raw (y, x); move_raw (temp, y); } The benefits of an underlying type library go far beyond the swap algorithm. For a start, any algorithm which moves values around without an inherent need to copy them could use the same mechanism as the swap algorithm above. Apart from that, it can help to simulate rvalue references and move semantics in pre-C++11 compilers in an efficient way. Concluding, a library which provides these tools has an immense potential for improving efficiency and convenience anywhere C++ is used. After reading the lecture notes, I came up with an idea on how to realise such a library in a fully generic way. Alexander Stepanov and Sean Parent have been so kind to review my idea. The idea seemed feasible and they encouraged me to submit something to Boost. In the meanwhile I have successfully managed to implement my idea, so here I am. :-) Apart from its fundamental nature in general, my library might bear special relevance to Boost.Swap and Boost.Move. Is your interest piqued? Kind regards, -Julian [1] http://www.stepanovpapers.com/notes.pdf

16 72

[proto] Problems with operator <<
by John Maddock 24 Aug '11

24 Aug '11

Folks, I'm having no end of problems with operator<< and proto. In the beginning, operator << was overloaded for stream output and everything worked OK, then I added the left shift operator<< to the list of protoized operators in the grammar and everything broke. The strange thing is that: std::cout << a+b; correctly finds my stream out overload: template <class Exp> inline std::ostream& operator << (std::ostream& os, const big_number_exp<Exp>& r) But std::cout << a; no longer calls: template <class Backend> inline std::ostream& operator << (std::ostream& os, const big_number<Backend>& r) But calls the proto << operator instead. I'm at a complete loss to explain this, both of my overloads are in the same namespace as their respective types, and as far as I can see both should be preferred to the proto versions. Before I start tearing my hair out, anyone any ideas? Thanks, John.

2 1