December 2013 - Boost - lists.preview.boost.org

[type_traits] is_empty fails on final classes.
by yuri kilochek 22 Dec '13

22 Dec '13

Hi. It seems boost::is_empty uses Empty Base Optimisation to detect whether a class type is stateless or not. This predictably fails on final types, as they cannot be inherited from: #include <iostream> #include <boost/type_traits.hpp> class Test final {}; int main() { std::cout << boost::is_empty<Test>::value; return 0; } Fails on gcc 4.8.1 with In file included from /usr/local/include/boost/type_traits.hpp:54:0, from main.cpp:2: /usr/local/include/boost/type_traits/is_empty.hpp: In instantiation of 'struct boost::detail::empty_helper_t1<Test>': /usr/local/include/boost/type_traits/is_empty.hpp:79:5: required from 'const bool boost::detail::empty_helper<Test, true>::value' /usr/local/include/boost/type_traits/is_empty.hpp:88:5: required from 'const bool boost::detail::is_empty_impl<Test>::value' /usr/local/include/boost/type_traits/is_empty.hpp:220:1: required from 'struct boost::is_empty<Test>' main.cpp:7:39: required from here /usr/local/include/boost/type_traits/is_empty.hpp:52:8: error: cannot derive from 'final' base 'Test' in derived type 'boost::detail::empty_helper_t1<Test>' struct empty_helper_t1 : public T ^ Yet std::is_empty works just fine (al least in gcc), and appears to be implemented via an intrinsic: template<typename _Tp> struct is_empty : public integral_constant<bool, __is_empty(_Tp)> {}; Now, is it at all possible to implement conforming is_empty without resorting to compiler magic that are intrinsics?

3 3

[git] How the blazes are you supposed to update all the submodules?
by John Maddock 22 Dec '13

22 Dec '13

OK.... so I do a Git pull at the top level (note: using TortoiseGit), and I see lots of messages in the log indicating which libraries have updates, and judging by the time taken they seem to be downloaded (?), but I don't actually see any changes in the libraries themselves. BTW I have every library set explicitly to either "develop" or "master". If I do a "git pull" on an individual library then the changes do come through OK. So what's the right way to do this? I assume it's not a "submodule update" as that seems to leave everything in a detached head state which I take it is a bad idea? I'm also seeing a lot of negative comments about Git submodules on the web, for example: http://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldn…, seems like there's a lot of potential to shoot yourself in the foot/head/chest here? Thanks, John.

16 33

Storing an adjacency list
by Nouf M. 22 Dec '13

22 Dec '13

Hi, I have a very large graph data (150000 node and 450000 edges) in two text files... first one: contains the vertices and their weights. second one: contains the edges and their weights. I need to retrieve a small subgraph from this big graph data...it's easier to do that if the graph is stored in an adjacency list format... I managed to write some code that reads from the files and creates a graph in an adjacency list format... Now, I would like to store the graph (the one in the adjacency list format) for next uses because it takes long time to convert my graph text files into the adjacency list format... I couldn't figure out how to do it... I saw the section about graph I/O in the BGL documentation: Graphviz, Max-flow, and GraphML but I don't think they will do what I need... I looked also on Serialization, I'm not sure about it... will serialization work well to store very large graphs and then retrieve then very fast ... Is this possible? Best regards, Nouf

1 0

[ASIO] example clarification (how to)
by Gaetano Mendola 21 Dec '13

21 Dec '13

In the asio chat example http://www.boost.org/doc/libs/1_55_0/doc/html/boost_asio/example/cpp11/chat… the class chat_server implements the async_accept handler with a lambda without use the shared_from_this pattern, isn't an error destroy the class while the handler is running? Maybe is not a problem looking at how is used inside the main but without having knowledge on how is it going to be used which can be the best way to destroy the chat_server (or similar code) safely? Is something like the following correct? chat_server::~chat_server() { //Call dispatching a cancel operation //in order to be sure to not chain another async_accept acceptor_.get_service().dispatch( [this](){ acceptor_.cancel(); }); } here I'm supposing a single thread is running io_service.run() otherwise the strand has to be used. Regards Gaetano Mendola --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com

1 0

[github] Admin access for move/container/interprocess/intrusive
by Ion Gaztañaga 21 Dec '13

21 Dec '13

Hi, Following indications explained in [https://svn.boost.org/trac/boost/wiki/ModAdmin] I requested admin access to Move, Container, Interprocess & Intrusive several days ago. The issue is still open, so have I missed something? Thanks to all working on this, Ion

1 0

[git][testing] regression testing?
by Joaquín Mª López Muñoz 21 Dec '13

21 Dec '13

There's been some unanswered questions around this. I understand that regression tests, which are critical to ensure clean develop->master merges, will be eventually updated to work against git rather than the abandoned SVN, but I can't find any info on the progress of this. FWIW, I see some authors are going ahead and merging their libs anyway, which will bring breakages etc if changes are not properly validated through regression testing. Any indication on how this is progressing much appreciated. Best, Joaquín M López Muñoz Telefónica Digital ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx

2 1

sidenote about guis (Re: [git] How the blazes are you supposed to update all the submodules?)
by Mateusz Loskot 20 Dec '13

20 Dec '13

(Please, adjust subject line for changed topic!) On 20 December 2013 11:15, Klaim - Joël Lamotte <mjklaim(a)gmail.com> wrote: > These days I only use SourceTree for both git and hg. It's cross platform, It's not cross platform, but Windows and Mac only https://answers.atlassian.com/questions/149631/sourcetree-for-linux?page=1#… A note on my own experience: 0. First, I aim to be comfy with git command, if not, then I will never understand git really. 1. Then, I use SourceTree where I can to complement git command (branches visualisation, etc.) 2. I use Qt Creator with its Git plugin which is nothing more than git command proxy, hence equivalent to git command. BTW, I'd like to do a bit of propaganda about Boost.Build support for Qt Creator: https://github.com/mloskot/qt-creator-plugin-boostbuild Best regards, -- Mateusz Łoskot, http://mateusz.loskot.net

4 5

[typeof] Non-static data member
by Bjorn Reese 20 Dec '13

20 Dec '13

Consider the following example: void foo(int value) {} struct alpha { int value; typedef BOOST_TYPEOF(foo(value)) return_type; }; This example compiles just fine with g++, but with clang++ it only works if compiled with -std=c++11, otherwise it gives the error message below. I believe that clang is correct (this diagnostics was added in clang 3.1 [1].) https://llvm.org/viewvc/llvm-project?view=revision&revision=154073 Is this a bug in Boost.Typeof or is it expected behavior? Is there a workaround for it? The error message is: /home/breese/src/treediff/treediff/main.cpp:17:30: error: invalid use of non-static data member 'value' typedef BOOST_TYPEOF(foo(value)) return_type; ^~~~~ /usr/local/include/boost/typeof/native.hpp:41:76: note: expanded from macro 'BOOST_TYPEOF' #define BOOST_TYPEOF(expr) BOOST_TYPEOF_KEYWORD(boost::type_of::ensure_obj(expr)) ^ 1 error generated.

1 1

Re: [boost] [Locale] translate() couples key and output character widths
by Artyom Beilis 20 Dec '13

20 Dec '13

That was a loooooong and painful discussion during the boost.locale review. Such a change was asked by the reviewers that wanted to be able to use wide strings as keys. For example translate(L"© All Rights Are Reserved") Where "©" is non-ASCII character. This change was mostly required to support non-ascii characters in keys. To be honest I was strongly against the change but finally had to accept it. See: http://thread.gmane.org/gmane.comp.lib.boost.devel/218543 Also you can search boost lists the locale review comments... Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/ -------------------------------------------- On Fri, 12/20/13, Alexander Lamaison <awl03(a)doc.ic.ac.uk> wrote: Subject: [boost] [Locale] translate() couples key and output character widths To: boost(a)lists.boost.org Date: Friday, December 20, 2013, 1:01 PM I've finally gotten round to changing from the pre-release version of Boost.Locale (v2.92) to the version now in Boost, and I was quite surprised by one change. Previously, I could do the following: void function_takes_wide_string(std::wstring message); function_takes_wide_string(boost::locale::translate("My translation key")); However, with the new version, the key must be passed in as a wide string if I am to be able to get a wide string out. This means changing `translate("blah")` to `translate(L"blah")` throughout. The change itself is no big deal, but the problem is that it feels like a change for the worse. The character width of the key is now coupled to the character width of the output, when the two are separate concepts and should be allowed to vary independently. The old class `message` coeerced the string to whichever width was required. The new class `basic_message<T>` coerces only to `basic_string<T>` and, worse than that, doesn't provide a method to explicitly convert to a different width string. My question, I suppose, is why was this change made? What makes the new API better? Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[Locale] translate() couples key and output character widths
by Alexander Lamaison 20 Dec '13

20 Dec '13

I've finally gotten round to changing from the pre-release version of Boost.Locale (v2.92) to the version now in Boost, and I was quite surprised by one change. Previously, I could do the following: void function_takes_wide_string(std::wstring message); function_takes_wide_string(boost::locale::translate("My translation key")); However, with the new version, the key must be passed in as a wide string if I am to be able to get a wide string out. This means changing `translate("blah")` to `translate(L"blah")` throughout. The change itself is no big deal, but the problem is that it feels like a change for the worse. The character width of the key is now coupled to the character width of the output, when the two are separate concepts and should be allowed to vary independently. The old class `message` coeerced the string to whichever width was required. The new class `basic_message<T>` coerces only to `basic_string<T>` and, worse than that, doesn't provide a method to explicitly convert to a different width string. My question, I suppose, is why was this change made? What makes the new API better? Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)

1 0