October 2006 - Boost - lists.preview.boost.org

Can someone confirm this fix (for bug #798357)?
by Daryle Walker 02 Nov '06

02 Nov '06

I just checked in a fix for bug #798357, which concerns boost::rational's operator< overflowing. Can someone confirm the fix, especially on wacky compilers (like MSVC 6)? The new test includes large numbers that are relatively prime, which the old code couldn't handle. (The old code hoped that partial cancellation would happen to lessen the component values.) I want to close out the bug. The old code used cross multiplication before integer comparisons, which can overflow. The new code manually does the Euclidian GCD algorithm, since its intermediate results give the continued fraction expansion. The components of that expansion are compared, with the regular code ending when corresponding components differ, and special code when one sequence ends early (or both end simultaneously without a difference). The changes are in "rational.hpp", "rational_test.cpp", and "rational.html" (the performance descriptions for comparisons have changed). -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 1

Re: [boost] [proposal] Sequence container with O(log n) random access _and_ O(log n) insertion/removal (wherever)
by Martin Knoblauch Revuelta 02 Nov '06

02 Nov '06

Rene Rivera wrote: > Martin Knoblauch Revuelta wrote: > > How about a sequence container [..]. > > I was wondering how long it would take this to make it from the usenet > groups to here :-) > > I've mentioned this type of container here in the past, under the name > of "rank_tree". Very soon now I will have the version I wrote, and use, > ported to the framework that Bernhard produced for the SoC tree project. > You can look at the draft TR > <https://boost-consulting.com:8443/trac/soc/browser/boost/soc/2006/tree/trun…> > that mentions it, and other trees. > > I don't have time to look at your implementation right now. But perhaps > you could comment on how you think your implementation might fit within > the above. And of course if there's something we haven't thought about. Well, maybe the most important thing is the experimental feature NPSV that I added in version 1.1. I described it briefly in my message, but there's a detailed description in the notes for version 1.1 of stlavlarray.h. The example program in npsvexample.cpp shows it's behaviour. Example where NPSV would be useful: a simple avl_array (or rank_tree) would waste a lot of memory when used for small contained types. This can be solved with NPSV, by storing more than one contained type element in every tree node. The 'width' of the node would be the number of occupied elements in the node, which would contain a circular buffer. Additionally, avl_array has the next characteristics (use it as a check list): * On iterators, ++ and -- are O(1) * begin(), end(), rbegin() and rend() are all O(1) * Copy constructor, assignment operator and destructor are O(n) * Other constructors, where the number of elements is known, are O(n) * Comparison operators are all O(n) * reverse(), merge(), and unique are O(n) * avl_array swap is O(1) * element swap is O(1) unless when NPSV is used _and_ the elements' widths don't match (then it is O(log n)) * element swap also works between two different avl_arrays * resize, range-insert and range-erase take O(m log n) when m is small, but O(n) when m is reasonably significant compared to n. (m: number of elements to insert/erase; n: size of the array) * move() is O(log n) unless it is a single-position move, in which case it is done with a swap * both sort() and stable_sort() are provided with O(n log n) * search tree methods are provided * insert_anywhere() inserts without rotations favouring balance (though still O(log n)) * Iterators follow their referenced elements, even when theese are moved from an avl_array to another one Can all this be done with generic trees while keeping them simple, efficient and usable for other purposes where the hierarchy is visible to the user? Regards, Martin Knoblauch Revuelta

9 27

[proposal] Sequence container with O(log n) random access _and_ O(log n) insertion/removal (wherever)
by Martin Knoblauch Revuelta 02 Nov '06

02 Nov '06

- How about a sequence container (like a vector) with the advantage of logarithmic time insertion/removal at any point of the sequence? The disadvantage is that random access takes logarithmic time too (instead of the usual constant time random access of a vector). Here it is: http://sourceforge.net/projects/avl-array It is implemented with a tree, but it is _not_ a map. The 'position' of elements in avl_array are always natural numbers (0, 1, 2... up to size()-1). When an element is inserted/removed, it changes automatically the position of all elements after it in the sequence (in logarithmic time!). A simple experiment realized consisted in populating a container by inserting random numbers in random positions, and then removing numbers from random positions, showing the value of the last one for checking. In this test AVL Arrays completely outperform list, vector and deque. The test code and the results are in sourceforge too. Version 1.1 includes a new experimental feature that I call "Non-Proportional Sequence View". In the normal sequence, every element occupies a position of size 1. Additionally, elements can be viewed as a sequence where the 'width' of every element can be changed (in O(log n) time), being the position of every element the sum of the widths of all previous elements in the sequence. Negative widths are forbidden, but zero widths are valid. The type used for the width is a template parameter, so any class supporting some operators can be used, not only unsigned or double. I've tried to adapt it to the boost requirements, but I'm sure there's still a lot of things to change. If you are interested, please take a look at it, and tell me your opinion. Regards, Martin Knoblauch Revuelta Universidad de Alcala

4 11

Boost regression notification (2006-10-31 [RC_1_34_0])
by Douglas Gregor 02 Nov '06

02 Nov '06

Boost Regression test failures Report time: 2006-10-31T11:56:09Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 36 failures in 7 libraries date_time (1) iostreams (10) mpl (4) program_options (7) random (1) serialization (12) utility (1) |date_time| testgreg_serialize_xml: msvc-8.0 |iostreams| bzip2_test: msvc-7.1 msvc-8.0 example_test: vc-6_5-stlport file_descriptor_test: cw-9.4 finite_state_filter_test: cw-9.4 gzip_test: msvc-7.1 msvc-8.0 mapped_file_test: cw-9.4 zlib_test: msvc-7.1 msvc-8.0 |mpl| multiset: gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc |program_options| cmdline_test_dll: cw-9.4 options_description_test_dll: cw-9.4 parsers_test_dll: cw-9.4 positional_options_test_dll: cw-9.4 unicode_test_dll: cw-9.4 variable_map_test_dll: cw-9.4 winmain_dll: cw-9.4 |random| random_test: intel-linux-9.0 |serialization| test_class_info_load_text_warchive: vc-6_5 test_reset_object_address: vc-7_0 test_reset_object_address_dll: vc-7_0 test_simple_class_binary_archive_dll: vc-6_5 test_simple_class_text_archive_dll: vc-6_5 test_simple_class_text_warchive_dll: vc-6_5 test_simple_class_xml_archive_dll: vc-6_5 test_simple_class_xml_warchive_dll: vc-6_5 test_variant_xml_archive: borland-5_8_2 test_variant_xml_archive_dll: borland-5_8_2 test_variant_xml_warchive: borland-5_8_2 test_variant_xml_warchive_dll: borland-5_8_2 |utility| operators_test: gcc-3.4.5_linux_x86_64

3 2

[xml] XML Reader Interface
by Sebastian Redl 01 Nov '06

01 Nov '06

Hi, Once again I'm turning to the list for discussion about a design issue in the XML library. This time I hope to avoid any discussion about the implementation on the library and focus on interface only. The interface in question is the reader interface, also known as pull interface. Like SAX, the pull interface is an event-based interface. There are a few event types (roughly, StartElement, EndElement, Characters, and a few more for other XML features), all of which provide come with some additional data: the element name, the character data, etc. There are two types of reader interfaces currently in use that I've found. I've come up with a third. I wonder which the people on this list would prefer, where they see their weaknesses and strengths. The names that I've given them are my own creation. 1) The Monolithic Interface Examples: .Net XMLReader, libxml2 XMLReader (modeled after the .Net one), Java Common API for XML Pull Parsing (XmlPull) (don't confuse with JSR 173 "StAX") In the monolithic interface, the XML parser acts as a cursor over the event stream. You call next() and it points to the next event in the stream. From there, you can query its type (usually some integral constants) and call some methods to retrieve the data. All methods are always available on the object; calling one that is not appropriate for the current event (e.g. getTagName() for a Characters event) returns a null value or signals an error. Pro: Event objects do not need to be allocated. The parser itself contains the entire state and can, for example, be passed down a recursive function group. Contra: You cannot store raw events: calling next() overwrites the current data. The parser contains a lot of state. This interface does not protect you in any way from calling inappropriate methods. 2) The Inheritance Interface Examples: JSR 173 "StAX" In the inheritance interface, the event types are modeled as a group of classes that all inherit from an Event base class. The parser acts as an iterator, Java style; calling next() returns a reference/pointer to the event object for this event. You use RTTI or a similar mechanism to find the type of the event, then cast the reference to the appropriate subclass. The subclasses then provide access to the data that is actually available for this event type. Pro: Cannot call methods that are inappropriate for the event. Event objects are independent of the parser and can be stored as they are. This is especially interesting if you have an event-based output system that uses the same event type: in this case, you can store the events, shuffle them, edit them, then pass them on to the writer. A proper analog to the stateful parser is harder to design. The parser contains less state, as it does not need to store the data that is currently queried. Contra: Event objects need to be allocated on the heap. In a non-GC language like C++, this is even more of a problem than in Java, as you have to use either a smart pointer or have the user responsible for deleting the object. The scenario of a group of functions as mentioned above is limited insofar as that if some functions want to process the same event, they need to be passed the current event along with the parser. 3) The Variant Interface Examples: None. I believe I came up with this entirely on my own. The variant interface seeks to combine the strengths of the other two interfaces. It uses a non-monolithic interface, that is, the parser acts like an iterator and the data is not stored within it. It does not return a reference to the event object, though, but instead a boost::variant of all possible events. This way, heap allocation of the event object is avoided, together with all the trouble coming with that. The event type can be determined either by calling variant::which, or with a variant visitor (type-safe!), or with a special get_base() function that works like get() but can retrieve a reference to a common base of all the variant types. (This is possible, although an implementation does not exist in Boost.) Pro: Cannot call methods that are inappropriate. The visitor system allows type-safe usage. (Of course, it also loses you part of the advantage of a pull interface over a push interface.) Does not need heap allocation if the event classes are properly designed (i.e. not trigger the case where the variant allocates heap memory.) Events can be stored, copied (another advantage over the inheritance interface, which would require a clone() method for that), and manipulated at will. They can be pre-allocated, a reference passed to next(), to save even the stack allocation. Contra: The issue about a group of function still applies. Independently of the type of interface chosen, another issue is important: the scope of the interface. Should it report all XML events, including those coming from DTD parsing? Should this be a user choice, or should there perhaps be two interfaces, one "high-level" and one "low-level"? Should errors be reported as error events, or as exceptions? Should this, too, be a user choice? How about warnings: exceptions are inappropriate for them. Should it be possible to disable them completely? All comments are welcome. Sebastian Redl

8 19

[thread] A simply static initializeable mutex
by Roland Schwarz 01 Nov '06

01 Nov '06

Triggered by the question how to do static initialization of a mutex, I tried to write one that is. The most basic initialization that wil be performed by the compiler, is zero initialization of static (POD) objects. This kind of initialization will take place before any other initializations. Consequently the mutex is initialized by its mere declaration. However this does come at a price: 1) Since the mutex has no ctor, one must not forget to initialize it when using it as a member of some containing object. But this is the same as with other POD's. 2) Altough the mutex is copyable this does not make any sense. The identifying property of a mutex is its memory address. Trying to lock a copied mutex will get you in trouble. It is not possible to protect against such usage since we have no ctor that could be declared private. On the other side you can make a object that contains a mutex copyable by simply reinitializing it to zero, which is not possible with the current mutex, since copying is strictly prohibited. I appended to this mail my first attempt to implement such a mutex . The code is commented and a pingpong test is included as example. So far this is only for windows. I would be very interested to get feedback about this idea. Roland // Copyright (C) 2006 Roland Schwarz // // Distributed under the Boost Software License, Version 1.0. (See accompanying // file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) #ifndef MUTEX_HPP__ #define MUTEX_HPP__ class scoped_lock; class semaphore; typedef scoped_lock* volatile mutex; class scoped_lock { public: scoped_lock(mutex& m, bool initially_locked = true); ~scoped_lock(); void lock(); void unlock(); private: bool is_locked; mutex* pmutex; scoped_lock* next_lock; scoped_lock* pred_lock; semaphore* volatile next_flag; semaphore* volatile sema_flag; semaphore* sema; void set(semaphore* volatile* pflag); void wait_for(semaphore* volatile* pflag); }; #endif // Copyright (C) 2006 Roland Schwarz // // Distributed under the Boost Software License, Version 1.0. (See accompanying // file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) // This is an experimental implementation of a mutex // that is of type POD. I.e. typedef scoped_lock* volatile mutex; // An unowned mutex has value 0. Consequently there is no need // for dynamic initialization, which solves the static // initialization problem. // Furthermore it also is not necessary to e.g. // mutex mx = 0; because static objects are zero initialized // by default, before any other initializations take place. // As such, availability of this mutex type makes a once // function unnecessary. // // Memory and resource management is fully automatic. I.e. // no leaks under normal usage. (In the basic version no cleanup // in the atexit handler is required.) The implementation needs // availability of some atomic primitives and semaphores // from the operating system. // // The required data structures are all within a scoped_lock // object. Destruction of the lock also frees up the resources. // // Typical usage: // mutex mx; // void foo() // { // scoped_lock lk(mx); // ... // } // // How does it work: // The scoped_lock object contains a doubly linked list. // The mutex is pointing to the head of this list. When // the mutex is zero the list ist empty and the mutex // unowned. // Locking the mutex means putting a list entry to the // head of the list. This is done atomically. Concurrent // requests are queued up, and each put on a separate // semaphore. This scheme already could be used by itself // (see e.g mcs-locks in win32 pthreads), however it // imposes a FIFO scheduling behaviour. // This implementation instead uses this queue only during // the build up, and then hands over the waiting to a // shared semaphore, to let the system scheduler wake up // the threads. The doubly linked list makes it possible // to remove list items from the list in an arbitrary // order. // // Performance: // I did only a minimalistic "pingpong" test, which showed // comparable performance to the current boost::mutex. // I expect that the performance can be improved, if the // semaphore objects are not completeley destroyed after // temporary use, but instead put in a lock free container // for later reuse. This however would raise the requirement // to destroy them during atexit. // // Missing parts: // I havent tried yet if it is possible to also provide // try and timed lock variants. // Altough I tried to take care of the necessary memory // barriers for SMP, I am not convinced yet that I got it // straight in this first attempt. // Also I have not yet been able to prove the correctness of // the algorithm. #include "mutex.hpp" // The operating system dependent part #include <windows.h> #include <limits.h> #include <cassert> template<class T> inline T* atomic_swap_full(T* volatile * p, T* a) { return (T*)InterlockedExchangePointer(p,a); } template<class T> inline T* atomic_load_full(T* volatile *p) { return (T*)InterlockedExchangeAdd((LPLONG)p,0); } template<class T> inline bool atomic_bool_compare_and_swap_full(T* volatile *p, T* c, T* s) { return (c == (T*)InterlockedCompareExchange((LPLONG)p,(LONG)s,(LONG)c)); } template<class T> inline T* atomic_compare_and_swap_full(T* volatile *p, T* c, T* s) { return (T*)InterlockedCompareExchange((LPLONG)p,(LONG)s,(LONG)c); } class semaphore { public: // The open and close functions could be extended // to put the closed items onto a lock free // container instead. static semaphore* open(int count = 0) { return new semaphore(count); } static void close(semaphore* sema) { delete sema; } void post() { ReleaseSemaphore(sem, 1, NULL); } void wait() { WaitForSingleObject(sem, INFINITE); } private: semaphore(int count) { sem = CreateSemaphore(NULL, count, LONG_MAX, NULL); } ~semaphore() { CloseHandle(sem); } HANDLE sem; }; // The following should be operating system independent scoped_lock::scoped_lock(mutex& m, bool initially_locked) : is_locked(false) { pmutex = &m; if (initially_locked) lock(); } scoped_lock::~scoped_lock() { if (is_locked) unlock(); } void scoped_lock::lock() { assert(!is_locked); next_lock = 0; pred_lock = 0; sema_flag = 0; next_flag = 0; scoped_lock* pred = atomic_swap_full(pmutex, this); if (0 != pred) { pred_lock = pred; pred->next_lock = this; wait_for(&pred->sema_flag); // pass on the shared semaphore sema = pred->sema; set(&sema_flag); set(&pred->next_flag); sema->wait(); } else { // create the shared semaphore sema = semaphore::open(); set(&sema_flag); } is_locked = true; } void scoped_lock::unlock() { assert(is_locked); scoped_lock* n = atomic_load_full(&next_lock); if (0 == n) { if (0 != pred_lock) { pred_lock->next_lock = 0; pred_lock->next_flag = 0; } if (atomic_bool_compare_and_swap_full(pmutex,this,pred_lock)) { if (0 == pred_lock) { // We have no predecessor and are the last // to hold this semaphore. Sucessors wil get // a fresh semaphore for this mutex. // Release it. semaphore::close(sema); } else { // We have been removed from the head, but have // a predecessor to wake up. sema->post(); } is_locked = false; return; } wait_for(&next_flag); n = atomic_load_full(&next_lock); } else { wait_for(&next_flag); } if (0 != pred_lock) pred_lock->next_lock = n; n->pred_lock = pred_lock; sema->post(); is_locked = false; } void scoped_lock::set(semaphore* volatile* pflag) { // If unflagged the value is 0. // The special value -1 is getting used when set is called // before a wait takes place. Since this is an illegal memory // address be careful not to call set again without having // reset the flag in between! semaphore* f = atomic_compare_and_swap_full(pflag,(semaphore*)0,(semaphore*)-1); if (0 != f) { f->post(); } } void scoped_lock::wait_for(semaphore* volatile* pflag) { if (0 == atomic_load_full(pflag)) { semaphore* f = semaphore::open(); if (atomic_bool_compare_and_swap_full(pflag,(semaphore*)0,f)) { f->wait(); } semaphore::close(f); } } // Copyright (C) 2006 Roland Schwarz // // Distributed under the Boost Software License, Version 1.0. (See accompanying // file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) #include "mutex.hpp" #include <iostream> #include <ctime> #include <boost/thread/thread.hpp> #include <boost/thread/mutex.hpp> #include <boost/thread/condition.hpp> #include <boost/bind.hpp> // set to 0 if you want to test against boost::mutex #if 1 typedef mutex test_mutex; typedef scoped_lock test_lock; #else typedef boost::mutex test_mutex; typedef boost::mutex::scoped_lock test_lock; #endif test_mutex mtx0; test_mutex mtx1; test_mutex mtx2; test_mutex mtx3; boost::mutex smx; boost::condition cs; bool start = false; void pingpong(long int turns) { test_lock lk0(mtx0, false); test_lock lk1(mtx1, true); test_lock lk2(mtx2, false); test_lock lk3(mtx3, true); boost::mutex::scoped_lock lkstart(smx); start = true; cs.notify_one(); lkstart.unlock(); for (long int i=0; i<turns; ++i) { lk0.lock(); lk1.unlock(); lk2.lock(); lk3.unlock(); lk1.lock(); lk0.unlock(); lk3.lock(); lk2.unlock(); } } // this needed about 30 sec on my machine const long int N = 1000000; int main(int argc, char* argv[]) { // pingpong timing test test_lock lk0(mtx0, true); test_lock lk1(mtx1, false); test_lock lk2(mtx2, true); test_lock lk3(mtx3, false); boost::mutex::scoped_lock lkstart(smx); boost::thread thd(boost::bind(pingpong, N)); while (!start) cs.wait(lkstart); std::time_t t0 = std::time(0); for (long int i=0; i<N; ++i) { lk0.unlock(); lk1.lock(); lk2.unlock(); lk3.lock(); lk1.unlock(); lk0.lock(); lk3.unlock(); lk2.lock(); } std::time_t t1 = std::time(0); std::cout << "time: " << t1-t0 << std::endl; thd.join(); return 0; }

6 29

[proto] interface changes
by Eric Niebler 01 Nov '06

01 Nov '06

To all those currently using the proto expression template toolkit at boost/xpressive/proto (all 2 of you, you know who you are), this is a heads up that the code has been rewritten, and the interfaces changed considerably. The changes have been committed to HEAD. The goals of the rewrite were many, but to sum up, the new code has a simpler, more uniform interface, integrates better with Fusion, and seamlessly supports ET nodes stored by value or reference. As a perk, xpressive now compiles 2x faster with vc7.1, and 25% faster with vc8. (No significant change with gcc.) The people most interested would be the Spirit people. The changes are specifically to make proto a better platform upon which to build Spirit-2. Now that I have an interface I can live with, I'm more inclined to write docs, and I will. The old proto v1 code from 1.34 now lives at boost/xpressive/proto/v1_ in the boost::proto1 namespace. -- Eric Niebler Boost Consulting www.boost-consulting.com

4 4

Re: [boost] [fusion] random access views?
by dan marsden 31 Oct '06

31 Oct '06

Eric Niebler wrote: >A fusion transform_view of a random access sequence should itself be a >random access sequence, and its category is random access, but it >doesn't seem to implement the complete interface. For instance: > >struct plus1 >{ > template<typename T> struct result { typedef T type; }; > template<typename T> T operator ()(T const &t) const > { > return t + 1; > } >}; > >template<typename V> >void bar(V const &v) >{ > boost::fusion::at_c<1>(v); // OK > boost::fusion::transform_view<V const, plus1> view(v, plus1()); > boost::fusion::at_c<1>(view); // ERROR >} > >int main() >{ > bar(boost::fusion::make_vector(1,2,3)); > return 0; >} > > >I can't randomly access elements of a transformed fusion::vector. Bug? The at_impl had been completed omitted. I've fixed this in the cvs, and added covering tests. Thanks for spotting this. Cheers Dan ___________________________________________________________ Try the all-new Yahoo! Mail. "The New Version is radically easier to use" – The Wall Street Journal http://uk.docs.yahoo.com/nowyoucan.html

2 1

Simulating log{10}(2)
by Daryle Walker 31 Oct '06

31 Oct '06

Our code that deals with determining how many characters are needed to express an integer in decimal form, based on the number of bits, use a conversion factor like: #digits <= 2 + #bits * log{10}(2) where "log{10}(2)" is the logarithm of 2 for base 10. This can be calculated from "ln(2) / ln(10)", where "ln" is the natural logarithm function. Since the conversion factor is used in compile-time integer contexts, the constant is expressed as an integer multiply followed by an integer divide. The decimal expansion of the constant is approximately 0.30102999566.... Our code uses cut-off versions of that expansion for the constant: static int const digits10 = 2 + digits * 301 / 1000; I've also seen "30103 / 100000" being used. Couldn't there be better approximate fractions to use? Based on various web calculators, like Google's and "Contfrac" at <http://wims.unice.fr/wims/wims.cgi?session=B75AF6A950.2&+lang=en&+module=to ol%2Fnumber%2Fcontfrac.en>, I've found a continued fraction representation of the constant. An irrational number has an infinitely long c.f. expansion, but the convergents off that expansion are usually the best rational approximations of an irrational value. Let's compare expansions: 1. ln 2 / ln 10 = [0; 3, 3, 9, 2, 2, 4, 6, 2, 1, 1, 3, 1, 18, 1, 6, 1,...] 2. 0.301 = [0; 3, 3, 9, 1, 2, 3] 3. 0.30103 = [0; 3, 3, 9, 2, 2, 4, 5, 1, 1, 1, 2] where [a0; a1, a2,...] = a0 + 1/(a1 + 1/(a2 + ...)). The common approximation 0.301 differs from the actual expansion at a4 = 2. The convergent there is 59/196. The absolute differences between those values and the actual value are: |log{10}(2) - 0.301| = 2.9995664e-5 |log{10}(2) - 59/196| = 9.58750072e-6 The convergent is 3.1 times closer to the actual value than the common approximation. Using 0.30103 versus the convergent 4004/13301 at the point of differing a7 = 6 gives the convergent an improvement factor of 2.1. The convergents have smaller numerators and denominators than their common approximations, making them easier to calculate without worry of overflow. Conversely, if you know that you have more leeway in multiplications, then using higher convergent fractions instead of the decimal expansion are a better bet. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

6 8

[GIL] Asking for help for vc2003 compiler bug
by Christian Henning 31 Oct '06

31 Oct '06

Hi there, taking the latest GIL source from their site is exposing a tedious compiler bug with VC2003. I have been trying to find an easy wokaround but failed. It fails in channel.hpp when trying to define specializations for channel_min_value() and channel_max_value. Here is the code: template <typename T> typename channel_traits<T>::value_type inline channel_min_value() { return std::numeric_limits<typename channel_traits<T>::value_type>::min(); } template <typename T> typename channel_traits<T>::value_type inline channel_max_value() { return std::numeric_limits<typename channel_traits<T>::value_type>::max(); } template<> inline bits8 channel_min_value<bits8>() { return 0; } template<> inline bits8 channel_max_value<bits8>() { return 255; } template<> inline bits16 channel_min_value<bits16>() { return 0; } template<> inline bits16 channel_max_value<bits16>() { return 32768; } template<> inline bits32f channel_min_value<bits32f>() { return 0.0f; } template<> inline bits32f channel_max_value<bits32f>() { return 1.0f; } Here is the compiler error messages: c:\gil\gil\core\channel.hpp(95) : error C2785: 'channel_traits<T>::value_type gil::channel_min_value(void)' and 'gil::bits8 gil::channel_min_value(void)' have different return types c:\gil\gil\core\channel.hpp(90) : see declaration of 'gil::channel_min_value' c:\gil\gil\core\channel.hpp(95) : see declaration of 'gil::channel_min_value' c:\gil\gil\core\channel.hpp(95) : error C2912: explicit specialization; 'gil::bits8 gil::channel_min_value<gil::bits8>(void)' is not a specialization of a function template c:\gil\gil\core\channel.hpp(95) : fatal error C1903: unable to recover from previous error(s); stopping compilation I have been trying to find a workaround reading some news groups entry. But all I could find are conformations that this is a bug and that VC2005 is compiling. Not very helpful. Does anyone here at boost know a workaround? I have realized that this request is offtopic. Please, ignore when feeling that my request is inappropriate. Thanks, Christian

2 1