- Boost - lists.boost.org

[BGL] boost::add_vertex - add unique vertexes to graph
by Mariusz Kwiczala 23 Jun '09

23 Jun '09

Hi, Currently I externally check if vertex exist in graph. But it is look like boost::add_vertex can check internally if vertexes are unique. if (optional<vertex_descriptor> v = g.vertex_by_property(get_property_value(p, vertex_bundle))) return *v; Could you send me any example where boost::add_vertex just return already created vertex (line: "return *v") instead of create new one? boost_1_39_0\boost\graph\detail\adjacency_list.hpp contain: template <class Graph, class Config, class Base> inline typename Config::vertex_descriptor add_vertex(const typename Config::vertex_property_type& p, vec_adj_list_impl<Graph, Config, Base>& g_) { typedef typename Config::vertex_descriptor vertex_descriptor; Graph& g = static_cast<Graph&>(g_); if (optional<vertex_descriptor> v = g.vertex_by_property(get_property_value(p, vertex_bundle))) return *v; typedef typename Config::stored_vertex stored_vertex; g.m_vertices.push_back(stored_vertex(p)); g.added_vertex(g.m_vertices.size() - 1); return g.m_vertices.size() - 1; } Best regards, Mariusz

2 1

Re: [boost] GSoC Unicode library: second preview
by Artyom 23 Jun '09

23 Jun '09

> Of course, the library works with UTF-8 and UTF-32 just as > well, it makes no difference to the generic algorithms > (which don't exist yet, but expect substring searching and > the like), it's up to you to choose what makes the most > sense to use for your situation (for example, you may choose > to use UTF-8 because you need to interact a lot with > programming interfaces expecting that format). > Ok, this is really good. > They should be fairly easy to find. > Either you're using the algorithm that does the task > correctly, or you're fiddling with the encoding by hand > which is likely to be wrong. They are easy to find in the Unicode aware unit tests but not in real program. I did once a small test, what Unicode aware programs support characters outside of BMP, i.e. I tested a glyph that was encoded as surrogate pair in UTF-16... The results were total disaster: - Windows standard dialogs: displayed character correctly but every operation like deletion related to is as two pairs. For example file name dialog had problems. - Same behavior in notepad or any standard text-area widgets didn't work correctly. - Qt3 hadn't supported surrogate pairs at all (in Qt4 most of it was fixed) displaying two square "glyphs". - Opera Web browser, had similar problems with editing and displaying such characters. So... There is a huge problem with this encoding, because such simple QA test shouldn't give such bad results for such big amount of programs. Also, all programs that used internally utf-8 or utf-32 had passed these tests very well. So I really **do not** suggest recommending this encoding as "best" one for internal use. Artyom

1 0

boost namespace
by Igor S 22 Jun '09

22 Jun '09

Hi Everyone. I need to use two versions of boost in my application. One the libs I link against is statically linked against boost 1.34 and I'd like to use 1.35's asio library. I believe I can make both versions co-exist if I can manage to rename boost 1.35's namespace to something like boost135. I know this project could be time-consuming so I'd like you know your thoughts. What changes would I need to make to the build system? Thanks. -- Igor

1 0

GSoC Unicode library: second preview
by Mathias Gaunard 22 Jun '09

22 Jun '09

Here is the documentation of the current state of the Unicode library that I am doing as a google summer of code project: http://blogloufoque.free.fr/unicode/doc/html/ This preview comes a bit later than I planned, but after struggling to keep the documentation and the code in sync I decided to move to automatic documentation generation with doxygen, which I had trouble setting up due to my experience. The reference still lacks a lot of information, however. The library only features UTF support and the Unicode Character Database (not fully updated to latest Unicode version) at the moment, but grapheme clusters and normalization support will come very soon. I would like to get feedback on the UTF codecs, the various concepts (Pipe, Consumer, BoundaryChecker) and the whole approach of lazy ranges. Grapheme clusters (and other text boundaries facilities) support will also be provided in terms of the Consumer and BoundaryChecker concepts. The library features lazy ranges similar to that of Boost.RangeEx, and I used one of the naming conventions that was proposed during review: u8_encode is the eager algorithm, u8_encoded is the lazy one. Since it wasn't really agreed which naming to use for RangeEx, I would like this to be discussed as well.

4 7

Spice up your mobile
by lokesh755＠gmail.com 22 Jun '09

22 Jun '09

1 0

proposal for boost dynamic java styled , efficient class loading library
by dominic ibeme 22 Jun '09

22 Jun '09

Hello.. i wrote a class library that allows C++ classes to be loaded seamlessly using the class names.. just like in java... the library makes heavy use of the BOOST PREPROCESSOR library and is very stable, simple and light... however, it is subject to expansion... and review... i would like to share this library with the boost community as a sign of appreciations for their tremendous offerings... please direct me on how to go about this..

6 5

Re: [boost] GSoC Unicode library: second preview
by Artyom 22 Jun '09

22 Jun '09

Hello, > Here is the documentation of the > current state of the Unicode library that I am doing as a > google summer of code project: > http://blogloufoque.free.fr/unicode/doc/html/ [snip] Where is the source code? .... Some notes: > UTF-16 ... This is the recommended encoding for dealing with > Unicode internally for general purposes To be honest, it is most error prone encoding to work with Unicode: 1. It is variable length encoding 2. There surragate charrecters are quite rare and thus it is very hard to find bugs related with it. It was mostly born as a "mistake" at the beggining of the unicode when it was beleved that 16bit is enough for signle code point. So many software platforms adopted 16 bit encoding that supported only BMP, As a result you can **easily** find **huge** amount of bugs in the code that uses utf-16, In most of cases such bugs are hard to track because these code points are rare. For example, try to edit file-name in Windows with a charrecter that not in BMP you would see that you need to press "delete" twice, try to write such charecter in Qt3 application... that would just not work; There are many examples of it. So, I would be aware of recommending this encoding as internal encoding, just because many platforms use it. > UTF-32 ... This encoding isn't really recommended As I mentioned above, it is not quite true, it is much safer encoding to work with, So I would recommend not to write such "suggestions". More notes: ----------- - For boundary checks I'd suggest to use ICU or Qt4 like API: iterate over string and return each time next bound. Not check if there is a bound on specific character. - Examples and More description is required Artyom

3 3

Proposal: Monotonic Containers
by Christian Schladetsch 21 Jun '09

21 Jun '09

Hello, There is a need in high-performance realtime software to use containers that may only grow in size. These are typically reset at the end of each update cycle. The proposal here consists of a base 'monotonic allocator', which takes its storage from a buffer that you provide. Allocations are made from this buffer, and deallocation only calls an object's destructor; no actual memory-management is performed at all. This is very useful for realtime systems that have to do things like, for example, physics or renderering systems. These systems build up lists and other containers over the period of an update frame, however at the end of that frame the storage can just be reset. The benefit of using this system over a normal std::allocator is that memory is not fragmented, and memory allocation and deallocation is basically optimal. Within the package are: boost.monotonic.inline_storage boost.monotonic.list boost.monotonic.vector boost.monotonic.map boost.monotonic.set boost.monotonic.ptr_list I didn't bother adding the other ptr_* containers yet. The files for the proposal are in the vault at http://www.boostpro.com/vault/index.php?action=downloadfile&filename=Monoto… . I'd be happy to address any issues or comments. There are some improvements that could be made. Regards, Christian.

24 156

DateTime conversion to tm problem?
by Maciej Sobczak 21 Jun '09

21 Jun '09

Hi, The posix_time::to_tm function clears the date fields of the std::tm structure. Having zeros on year, month and day fields represent the 1900-01-00 date according to the std::tm conventions, which is a date that did not exist. Using such value with other APIs might result in out of range conditions. Is it considered to be a problem? What about setting tm_mday to 1 instead (which would represent 1900-01-01 - that is, the first legal date)? Regards, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com

3 4

[BOOST_ASSERT] any one against improving debug support?
by Thorsten Ottosen 21 Jun '09

21 Jun '09

Hi, The current difinition of BOOST_ASSERT is a pain to use with the debugger and Boost.Test because it doesn't trigger a break-point. Does anyone object to defining it like this in <boost/assert.hpp> #if (BOOST_MSVC >= 1400) #include <crtdbg.h> #define BOOST_ASSERT _ASSERTE #endif ? -Thorsten

5 12