- Boost - lists.preview.boost.org

[interprocess] detail/move.hpp macros conflict with boost/move/move.hpp
by Daniel Larimer 11 Aug '11

11 Aug '11

I am attempting to include my own <boost/move/move.hpp> header, but the macros conflict with <boost/interprocess/detail/move.hpp>. It would seem to me that boost interprocess should 'namespace' the macros like it did the types so that when boost/move is included there are no conflicts. When will Boost.Move be included in an official release? Dan

1 0

[tti] Changes will go on Boost trunk
by Edward Diener 11 Aug '11

11 Aug '11

For interested parties, I have put TTI on the Boost trunk and will be making changes there in getting TTI ready for a Boost release. I will keep the reviewed copy in the sandbox until TTI is officially part of a Boost release, after which I will remove the sandbox version.

1 0

[tti] compiler error: shadows template param `class T`
by Lorenzo Caminiti 11 Aug '11

11 Aug '11

Hello, The TTI library macros expand to code that uses naive template parameter names like "T", "F", "U", etc. The library implementation should be changed to use library reserved names to avoid clashing with user template parameter names. For example, the library use a name like boost_tti_aux_T (or even better BOOST_PP_CAT(boost_tti_aux_T_, __LINE__)) instead of T and state in the documentation that any name prefixed by boost_tti_aux (in any namespace) is reserved for the library implementation. The same should be done for any other implementation symbol defined by the TTI library. This is an issue if the macros are expanded for example within a class (which is and should be possible after changing them not to expand in the boost::tti namespace). For example, assuming BOOST_TTI_HAS_COMP_MEMBER_FUNCTION is fixed not to expand in boost::tti then the following: template< typename T > struct myvector { BOOST_TTI_HAS_COMP_MEMBER_FUNCTION_TRAIT(has_push_back, push_back) // expand to code using a template parameter naively named T ... }; Will generate a compiler error on GCC "error: shadows template param class T". --Lorenzo

3 3

[containers review] A reminder that the containers review ends tomorrow
by John Maddock 11 Aug '11

11 Aug '11

Just a quick reminder that the containers lib review ends tomorrow - there have been lots of good comments, but not so many reviews - so now's your chance ;-) If there are any reviews pending that are likely to be late please let me know so we can extend the review period. Documentation from the library may be viewed online here: http://svn.boost.org/svn/boost/sandbox/move/libs/container/doc/html/index.h… The source may be accessed from the "move" directory of the sandbox SVN or downloaded from http://www.drivehq.com/web/igaztanaga/boost_container.zip. Note that this download contains a copy of the accepted, but not yet release, Boost.Move library - extract the zip over a copy of Boost-1.47 to get a full working copy. Regards, John.

1 0

[Autosave] Re: [math][accumulators] Empirical distribution function
by Simon West 11 Aug '11

11 Aug '11

Hi, On Sun, June 19, 2011 22:36, er wrote: > Hope this can serve as a basis for a conversation: > > > https://svn.boost.org/svn/boost/sandbox/acc_ecdf/ > I'm assisting Eric with the maintenance of Accumulators. I've had a look through the code at the above link, and would like to offer the following comments (if I have misunderstood anything, please let me know). My basic concern with the code is that a map is used to store the counts of data-points that have been added (the map keys are the data-points, the map values are the counts). In real-world floating point data it is rare for two data-points to be exactly the same, so in practice the map would have a single key-value pair for each data-point q_i, of the form (key=q_i,value=1). This is inefficient, because all the key values will be 1. Also, the memory usage will grow linearly with the number of data-points accumulated, which doesn't seem to be in keeping with the spirit of the Accumulators library. For these reasons, I'm not convinced that the code should be added to the library in its current state. Simon.

3 2

[tti] getting write access to Boost trunk
by Edward Diener 11 Aug '11

11 Aug '11

I sent a message a few days ago to the Boost moderators at boost-owner(a)lists.boost.org to get write access to the Boost trunk so I could work on my TTI library there, since it has been accepted into Boost, but I have not received any response. Is anybody at home ? Edward Diener

2 1

[move] [variant] Some problems with VC++10
by Antony Polukhin 10 Aug '11

10 Aug '11

There are some problems with VC10 libraries and move implementations in Boost,Variant and Boost.Move. The problem is that VC10 uses move() in it's STL implementation without directly specifying namespace. That leads to ambiguity, when VC10 containers are used with boost classes. I can not exactly reproduce the bug, because I have no VC at home, but thats how it looked like: std::vector< my_variant > vec; vec.push_back( my_variant(some_data) ); // ERROR: Leads to ambiguity. Compiler can not choose between std::move that is defined in the same namespace and boost::variant::detail::move(), which is found via ADL. I think, that the same thing can happen with Boost.Move library, if some class defined in namespace boost will be used in VC++ STL containers. Most generic way to get rid of such ambiguity, is to import std::move in namespace boost (if we have std::move). Best regards, Antony Polukhin

4 5

[move] Pathscale and Sun
by Daniel James 09 Aug '11

09 Aug '11

Hi Ion, Boost.Move seems to work okay with Pathscale (at least the unordered container tests pass), but you've marked it as not supported. IIRC it used to have some configuration problems which were fixed a little while ago. Have you got any plans to fix the issue with 'boost::rv' on Sun C++ or should I work around it? Daniel

2 2

[containers] reviewette
by Gregory Crosswhite 09 Aug '11

09 Aug '11

Hey everyone, I don't know if I will get the chance to perform a full review within the review window, but I just wanted to share my limited experience with the library. Back in February I wrote (or more precisely, rewrote in C++) a production numerical simulation code [1] that makes extensive use of Boost.Move because move-but-not-copy semantics were the most natural fit for most of my data objects. (The rationale for this was that in nearly all cases I only wanted one entity to hold a given data object, and in the remaining cases few I could just wrap the data object in a shared_ptr.) Since I wanted to have vectors containing these objects, I made use of the containers::vector class that was bundled with Boost.Move, so the headers for Boost.Move and at least the vector class of the proposed Boost.Containers library have lived in my code for a few months now. Being able to return a vector without having to worry about whether it would be copied was so nice that I eventually just started using boost::containers::vector everywhere I would normally have used std::vector; it was also very nice to be able to use the .emplace* methods to construct elements in place because this saved both some overhead *and* additional typing on my part. (Of course, I will eventually get these things by default in std::vector as soon as C++0x is available everywhere, but it is really nice to have them now! :-) ) The code has been stable enough that I never encounter any problems using it. Now, I don't know what has changed since I coped the Boost.Move+Boost.Container headers into my tree in Febrary so hopefully nothing has been broken, but based on my personal experience using the library I can say that it at least boost::containers::vector seems to work just fine in production code and I would really like to see it be a part of Boost. Cheers, Greg [1] Nutcracker, a matrix product state based quantum simulation code, available at: http://github.com/gcross/Nutcracker

2 1

[lockfree] Review
by Grund, Holger 09 Aug '11

09 Aug '11

Hi everyone, I'm sorry for the late review -- things have been busy as usual. I've briefly gone over the code and think Tim's Lockfree library would make an excellent addition to Boost and should be accepted, provided some points are addressed. First and foremost, I don't think the library can be called ready when it doesn't support Visual C++/x86 in a meaningful way -- which I believe it doesn't right now. What is your evaluation of the design? -------------------------------------- The library seems well-designed. As I believe has been discussed in a separate thread, naming is somewhat inconsistent. The failure modes are not clear to me (e.g. does enqueue/push return false or throw an exception when there is no more memory), but overall I think Tim did an excellent job. What is your evaluation of the implementation? ---------------------------------------------- As mentioned, it would appear that bundled atomic implementation has a lot of shortcomings, but one is particularly bad: atomic<tagged_ptr> is not actually lock-free for Visual C++. The DCAS implementation should be straightforward, but seems to be absent . in case you wonder I did an initial implementation of <(cstd)atomic> and added all required intrinsics for a simple implementation to the compiler. These made it all into VC++2010 RTM (IIRC, there was only one 64-bit, most where 8 & 16-bit variants) There are a few points that make me a bit nervous. Specifically, the alignment story is a bit weak. It seems there is only one use of BOOST_LOCKFREE_CACHELINE_ALIGNMENT and that's for fifo<>::node. Older compilers (GCCs and VC at least) don't dynamically align the stack with __declspec(align)/__attribute__((aligned). Other classes do not use alignment at all. It seems somewhat inconsequent to add internal padding to move members to different cachelines, but at the same time not ensuring alignment (which means potential cacheline overlaps at back and front of the object). Also the code seems to assume that compilers will use an empty base class optimization for noncopyable -- I guess, that's fine for most major compilers. Also it is not clear how it is ensured that nodes allocated are actually aligned. Allocators can and usually do ignore alignment requirements greater than intmax_t types. Some may just fail to instantiate. likely/unlikely are often defined as macros as in the Linux kernel. People probably shouldn't do that for C++, but I have seen it quite a bit. It probably doesn't help that many compilers' inlining oracles don't do very well for modern code. The name freelist_t is somewhat confusing for a template parameter and while I'm not sure what harm it could do it should probably follow the general convention of CamelCase. What is your evaluation of the documentation? --------------------------------------------- This is a bit of a weak point right now. There isn't much documentation to begin with. The definition of wait-free and lock-free is a bit weird. Specifically, the term concurrent operations is a bit vague. I think it's easier to grasp if you say something along the lines of at least one thread makes forward progress at any given point in time. With the current definition in the docs (and most others I know of), it may not be immediately clear why a mutex-based implementation wouldn't be lock-free. There's a paragraph: > The synchronization is done completely in user-space with no interaction without any direct interaction with the operating system [1] . > This implies that they are not prone to issues like priority inversion (a low-priority thread needs to wait for a high-priority thread). I think there's some duplication in the first sentence. I'm not sure what lock-free has to do with priority inversion and I would think that priority inversion means priorities are -- well, inverted. I.e. a high-priority thread is not scheduled, because a lower priority thread owns a resource needed by the high-priority thread. This also makes it sound a bit like lock-free is superior to OS mechanisms, but that really depends. A standard lock-free list is not fair for writers, but an implementation making use of OS facilities can be. On the other hand ticket lockets can provide some fairness. fifo<> and ringbuffer::empty says it is not thread-safe. I would assume that means the value returned is potentially stale, but it can't break class invariants, or can it? What is your evaluation of the potential usefulness of the library? ------------------------------------------------------------------- I think the library addresses a very important use-case and could therefore be a very useful addition to Boost. But to reiterate, I would expect Lockfree to actually be lock-free on all mainstream platforms. Did you try to use the library? With what compiler? Did you have any problems? ------------------------------------------------------------------------------ I don't have Boost libs built here, so only tried some simple tests with VC++ 10 SP1. No problems. I'm planning to run some perf tests with GCC 4.1 on AS5 x86_64. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? -------------------------------------------------------------------------------------------- I spent about four hours mostly going over the code and the docs. Are you knowledgeable about the problem domain? ----------------------------------------------- I have done quite a lot of lock-free work over the last the last 8 years. I did an initial implementation of <atomic> for Microsoft and my current job involves a lot of tweaking of very low latency code, where we very much care about upper limits for execution time (but also about throughput). While I'm still constantly surprised by modern CPUs, I do consider myself to be quite knowledgeable about this area. -hg Holger Grund, Vice President Morgan Stanley | MS Strats and Modeling 25 Cabot Square | Canary Wharf | Floor 03 London, E14 4QA Phone: +44 20 7677-4095 Holger.Grund(a)morganstanley.com -------------------------------------------------------------------------- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.

5 16

Re: [boost] [math][accumulators] Empirical distribution function
by Denis Arnaud 09 Aug '11

09 Aug '11

On 8/8/11, er wrote: > Thanks, but it was just, I quote, a "basis for a conversation" at the > request of a user (Denis Arnaud), but it failed to go anywhere at the time. Note that I am still interested in using such a component/library. The difficulty I had was the integration with the rest of Boost and, therefore, the build of that component. Indeed, I use CMake (from the Ryppl initiative) rather than bjam, for the Boost sandbox components, and the integration is therefore a little bit different. AFAIU, Daniel Pfeifer is now close to have a CMake-ified Boost able to integrate Boost sandbox libraries. One of the first such use case would be to integrate and to test your Empirical CDF component. Nevertheless, thanks for having proposed a solution, even though I understand it is still not perfect. Best Denis

1 0

[tti] Write access to Boost
by Edward Diener 09 Aug '11

09 Aug '11

For my TTI library I need write access to the Boost repository si I can check the library into the trunk and maintain it there. Eddie Diener

2 2

[function][bind] Crash with g++ 4.5.0 -O[23]
by Daniel Larimer 08 Aug '11

08 Aug '11

I recently wrote some code that only crashes with g++ 4.5.0 -O[23] and am not sure whether it is a g++, boost::bind, or boost::function bug. I have prepared a minimum test case that crashes every time: 0 test 0x00000001000016ba Private::method_name(std::string const&) + 26 1 test 0x0000000100001348 boost::detail::function::function_obj_invoker1<boost::_bi::bind_t<void_t, boost::_mfi::mf1<void_t, Private, std::string const&>, boost::_bi::list2<boost::_bi::value<Private*>, boost::arg<1> > >, void_t, std::string const&>::invoke(boost::detail::function::function_buffer&, std::string const&) + 24 2 test 0x00000001000027bb boost::detail::function::void_function_obj_invoker2<functor<std::string, boost::function<void_t ()(std::string const&)> >, void, std::string const&, std::string&>::invoke(boost::detail::function::function_buffer&, std::string const&, std::string&) + 59 3 test 0x0000000100003893 Private::test() + 2723 4 test 0x00000001000012d8 main + 56 5 test 0x0000000100001250 start + 52 Mac OS X 10.6 Snow Leopard g++-4.5.0 -O3 or -02 crashes g++-4.5.0 -O1 works. g++-4.2 -O3 works. g++-4.0 -O3 works llvm-g++-4.2 -O3 works The odd thing is that if I replace boost::bind() with my own custom functor then it does not crash. If I include both working and non-working functors (uncomment code) then they both work. Because older versions of g++ work (pre C++0x support) it could be a bug in how boost::function or boost::bind use rvalue references. Because replacing boost::bind() with my own custom functor also fixes it, I suspect that the problem, if not g++, lies in boost::bind. If I remove boost::function from the equation by creating functor<Seq,Functor> with Functor = TYPEOF( boost::bind( ... ) ) via the use of a helper method, then it also does not crash. Thus some combination of creating a boost::function<...> from a boost::bind() functor on g++4.5 causes the crash.

2 2

[Containers] Should flat_* expose implementation vector?
by Phil Endecott 08 Aug '11

08 Aug '11

Dear All, Should Ion's proposed flat_set, flat_map etc. expose the underlying vector that they use as their implementation? Pros: it lets the user efficiently load and save the content, and implement algorithms that cannot be done via the flat_* interface. Cons: it lets the user break the invariants. Const access to the impl is another possibility. Related to that: could the implementation type be a template parameter? Example: could one implement a flat_set on top of a stable_vector? (Is that useful?) And/or: should flat_* actually be adaptors that take a reference to their underlying implementation? Regards, Phil.

8 10

[gsoc] mentor summit
by Andrew Sutton 08 Aug '11

08 Aug '11

Mentors, If you are interested in attending the mentor summit (Mountain View, CA Oct 22-24 -- check the calendar that might be wrong), please let me know. We send 2 people to represent Boost. I will not be one of them since I have a prior engagement. The reimbursement scheme looks like it's going to change this year. Essentially, Boost (actually the SFC) will submit a single purchase order for mentored projects + the cost of mentor summit air travel. That means that actual reimbursement for your flight costs may not happen until... I don't know. June 2012? The process is ridiculously slow, and I never got word that Boost received mentor payments from last summer. Andrew

1 0

[Date Time] bug in documentation example (Localization Demonstration)
by Frédéric Bron 08 Aug '11

08 Aug '11

In "Localization Demonstration": http://www.boost.org/doc/libs/1_47_0/doc/html/date_time/examples.html#date_… 11 should be 12 and 6 should be 7 in the following lines: std::copy(&de_short_month_names[0], &de_short_month_names[11], std::back_inserter(short_months)); std::copy(&de_long_month_names[0], &de_long_month_names[11], std::back_inserter(long_months)); std::copy(&de_short_weekday_names[0], &de_short_weekday_names[6], std::back_inserter(short_weekdays)); std::copy(&de_long_weekday_names[0], &de_long_weekday_names[6], std::back_inserter(long_weekdays)); Regards, Frédéric

1 0

Boost.Atomic, pushing forward and a little request for help
by Helge Bahmann 07 Aug '11

07 Aug '11

Hi folks, from the comments to Boost.Lockfree I understand that you consider a non-reviewed Boost.Atomic as a "blocker"? I apologize that I have not pushed forward for review (considering that "it just works for me", and considering the length of the review queue...), but if you consider it blocking please just let me know what I would need to do to clear the path. What I will do shortly is to provide and uptodate package containing several fixes, several contributed by others (they are in the repo, but not in any release archive) as well as some missing bits to more closely match latest C++0X draft. The big sore point is still support for the various flavours of VC -- I know that there are (especially older) versions for which it is not working, but I am lacking test systems, so if you are affected please let me know and I will do my best to resolve the issues. Cheers, Helge

10 14

[interprocess::file_mapping] Please add resize method
by Dmytro Ovdiienko 07 Aug '11

07 Aug '11

Hello, Could you please add resize method to the file_mapping class? Also please don't fill file with zeros by default? This functionality increases latency spikes. Make it as quick as possible. Thanks. Best regards. Dima -- Dmytro Ovdiienko e-mail: dmitriy.ovdienko(a)gmail.com skype: dmitriy.ovdienko(a)gmail.com mobile: +38050-1909731

2 5

[containers] review
by Gordon Woodhull 07 Aug '11

07 Aug '11

Hi Ion, John, all, I apologize that I don't have time for a full review, as I'm going offline hiking for the rest of the review period. Obviously the library should be accepted. Move emulation, stateful allocators, emplace, recursive containers, ... so many excellent features. And this code has been tested as part of Interprocess for years. However, I do find the documentation lacking. While the Doxygen reference looks very complete, I want to see the overview documentation expanded, including covering the following topics: Stateful allocators seem to be unmentioned. Do they affect performance or behavior? I know this might be a big topic; links are okay. My understanding is that these are fully supported but other allocator improvements are not yet present? Out of curiosity I'd like to see a bit of text about the future directions, mentioning N1953 & N2045. Could the contents of Joachin's blog post http://bannalia.blogspot.com/2008/08/stable-vectors.html go into an overview section for stable_vector? Recursive container is not defined, also maybe link to http://en.wikipedia.org/wiki/Recursive_data_type What is it used for: directed graph. Some guideline about when it's better to use flat_*. I figure you would use such a structure when you're not doing a lot of inserts or when there are few elements. The advice can be somewhat handwavy and instruct the user to do measurements, but it should be there. Silly question, but I'm not clear how to use this ordered_unique_range_t that's in the Doxygen - is there a constant or do you default construct it or what? As earlier pointed out, a lot of the Doxygen parameters and descriptions have gotten out of sync k/x first/i etc. Well, I've run out of time. Hope this helps a little. Cheers, Gordon

3 3

[Container] boost::container::vector<bool>
by Joel falcou 07 Aug '11

07 Aug '11

It is not clear from the doc but does the vector from boost::container *don't* do the so not useful bool optimization ? Aka can I finally take a pointer to vector<bool> element ? Thanks

2 1

[Containers] Complexity of flat_*::insert(first,last)
by Phil Endecott 07 Aug '11

07 Aug '11

Hi Ion, This library looks great. A quick comment about range-insertion in the flat containers, e.g.: template<typename InputIterator> void insert(InputIterator first, InputIterator last); Requires: i, j are not iterators into *this. Effects: inserts each element from the range [i,j) . Complexity: N log(size()+N) (N is the distance from i to j) search time plus N*size() insertion time. (Note typo: i,j vs, first,last) What implementation are you assuming to get that complexity? It seems to me that it is worse than it could be if you implement it something like this (PSEUDO-CODE): template<typename InputIterator> void insert(InputIterator first, InputIterator last) { iterator m = end(); insert(end(), first, last); sort(m,end()); inplace_merge(begin(),m,end()); } (I've only ever done this with multi* containers. For set and map you'll need something to avoid duplicates.) Regards, Phil. p.s. Having typed that I have developed a feeling of deja vu. Have I asked you this before?

4 11

[fusion] joint_view bug?
by Eric Niebler 07 Aug '11

07 Aug '11

The following code asserts at compile time for me. Am I doing something wrong? typedef fusion::vector2<int,int> pair; pair p(1,2); fusion::joint_view<pair, pair> x(p, p); auto begin = fusion::begin(x); auto end = fusion::end(x); int i = fusion::distance(begin, end); The assert is on line 39 of fusion/iterator/distance.hpp: template <typename Tag> struct distance_impl { // default implementation template <typename First, typename Last> struct apply : distance_detail::linear_distance<First, Last> { BOOST_MPL_ASSERT_NOT((traits::is_random_access<First>)); BOOST_MPL_ASSERT_NOT((traits::is_random_access<Last>)); }; }; In this case, First is a joint_view iterator and Last is a vector iterator, which is indeed random-access. If I simply comment out the compile-time asserts, the code compiles and works as expected. I think these asserts are bogus. OK to remove them? -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 2

[log] Documentation improvement suggestions - was :how to set attributes under multi-threaded application
by Klaim - Joël Lamotte 06 Aug '11

06 Aug '11

Hi, Andrey Semashev said: I think the common formula "library design + tutorial + features description > + reference" is the golden middle for medium-sized projects, like Boost.Log. > Also, quite a few common case examples will help to get things started. The > rest will come with experience. > > I would like to give my limited feedback with the log docs about this very point : What I think might be a bit overhelming and don't help beginners with boost.log is the library design page itself. http://boost-log.sourceforge.net/libs/log/doc/html/log/design.html I mean the content organisation of the page, not the fact that it exists and I agree with you that it should be up front. The main problems with the page : A. there is a BIG bloc of text with almost no apparent hierarchy - that's a showstopper for a lot of people that will just click the "tutorial" link to see what it's really about; B. the scheme is clear technically but might be easier to read if it was to be read from left to right instead of right to left (at least because it uses english text); an alternative would have been from top to bottom : reading the scheme should follow the way data goes from loggers to sinks (in fact the current scheme looks like an inverted comics page to me...) Here are some suggestions to improve this page : 1. Structure the big block of text in several distinct parts, with titles. I think those parts already exists but they just lack obvious separations like just big titles. 2. Add links in the text to definitions from the previous page (Definitions). Reading the definitions first doesn't always make things really clear immediately. Often you read them used in context and then understand...or not if your forgot what it was. There are 9 definitions with several having the same beginning. It might be easier to the user to link to those simple definitions when they need them, when reading the library design text (might not be necessary after that?). 3. Invert the reading sens of the scheme or make it top to bottom. Obviously I'm an humble user, not an authority in the matter, but I hope it helps getting more users not stop at this page. Joël Lamotte

3 4

boost::iostreams::detail::basic_buffer int usage
by Judson Weissert 05 Aug '11

05 Aug '11

Hello, I believe there is a type conflict in boost/iostreams/detail/buffer.hpp. ------ Snippet from buffer.hpp ------ class basic_buffer { ... basic_buffer (int buffer_size); ... std::streamsize size_; }; ------ End snippet ------ Here is some example code that triggers the same warnings I was receiving: // Tested with boost 1.46.1 // Compiler Microsoft VC2010 SP1. // Compiled with cl /EHsc /W3 repro.cpp #include <boost/iostreams/copy.hpp> #include <boost/iostreams/device/array.hpp> #include <boost/iostreams/filtering_streambuf.hpp> int main (int, char *[]) { static const char b[] = { 'A', 'B', 'C' }; boost::iostreams::array_source as (b, 3); boost::iostreams::filtering_streambuf <boost::iostreams::input> in; in.push (as); // This line generates a 'std::streamsize' to 'int' warning. // See also boost/iostreams/detail/buffer.hpp boost::iostreams::copy (in, std::cout); return 0; } Perhaps the fix is as simple as s/int/std::streamsize/g within buffer.hpp. Any thoughts? Thanks, Judson

1 0

[type trait extension] I hate volatile...
by Frédéric Bron 05 Aug '11

05 Aug '11

I am still working on the implementation of the traits to detect operators. I have an issue with operators returning a volatile object (being a reference or not). This breaks the code I wrote to detect if the return type is void or not. In particular, the following code compiles with RET=int but not with RET=ret. Can somebody tell me why? It seems that any volatile object (reference or not) cannot be bound to a const reference apart for fundamental types. So is there any useful case to return a volatile object? If not, I can maybe just ignore those cases or it becomes to be a nightmare. By the way, it is 1:30am. I am going to bed! Frédéric struct ret { }; #define RET int RET result; RET r() { return result; } RET const rc() { return result; } RET volatile rv() { return result; } // fails to compile RET const volatile rcv() { return result; } // fails to compile RET & rr() { return result; } RET const & rcr() { return result; } RET volatile & rvr() { return result; } // fails to compile RET const volatile & rcvr() { return result; } // fails to compile int main() { RET x; x=r(); x=rc(); x=rv(); // fails with RET=ret x=rcv(); // fails with RET=ret x=rr(); x=rcr(); x=rvr(); x=rcvr(); return 0; }

4 13