Boost

boost@lists.boost.org

November 2009

207 participants
272 discussions

[optional] layout
by Domagoj Saric 02 Nov '09

02 Nov '09

why is boost::optional laid out so that the bool comes before the object's placeholder/storage? this takes up to 7 extra bytes of storage with default alignement and, more importantly, it forces pointer offset adjustment/calculation when accessing a boost::optional<> through a pointer (and trying to access the actual contained object)... it also makes life harder for those of us keen to hackery ;) because it makes the address of an optional different from the address of the actual object within the optional... ps. it would be 'cool' if all of the functionality from boost::optional<> not related to the 'is initialized' bool (conditional destruction, etc...) could be extracted into a separate class (usefull for cases where you have to delay/in-place construct an object but are certain that you will construct it by the point where it needs to be used or destroyed...so you do not need the 'conditional' overhead)... -- "That men do not learn very much from the lessons of history is the most important of all the lessons of history." Aldous Huxley

6 10

Re: [boost] loglite - A logging library (JD)
by Tan, Tom (Shanghai) 01 Nov '09

01 Nov '09

> Please have a look and let me know what you think could be improved. The first thing I notice is that it does not support std::wstring directly. It's a big problem in my case I use wide-character in all my applications, which simplifies dealing with UTF-16 adopted by Modern Windows platforms. If I need to any string info from my program, I'll have to convert from UTF16(represented as std::wstring) to UTF8 so that it could be working well with LOGLITE. That's inconvenient. Offtopic, I am expecting boost::filesystem V3 for this very same reason.

3 2

Jump to page: