May 2009 - Boost-users - lists.boost.org

[gil] raw image resizing problem
by Stephan Menzel 05 May '09

05 May '09

Hi there, I'm trying to resize an image that comes as a raw RGB8 interleaved buffer into another buffer. According to the resize.cpp sample that comes with boost that should work like this: #include <boost/gil/image.hpp> #include <boost/gil/image_view_factory.hpp> #include <boost/gil/typedefs.hpp> #include <boost/gil/extension/numeric/sampler.hpp> #include <boost/gil/extension/numeric/resample.hpp> using namespace boost::gil; rgb8_view_t view = interleaved_view(orig_width, orig_height, reinterpret_cast<rgb8_ptr_t>(original_buffer), orig_width * 3); rgb8_image_t scaled(new_width, new_height); resize_view(view, view(scaled), bilinear_sampler()); I'm getting an compile error in the resize_image line though and don't know what to make of it: : error C2664: 'boost::gil::pixel<ChannelValue,Layout> &boost::gil::image_view<Loc>::operator ()(const boost::gil::point2<T> &) const' : cannot convert parameter 1 from 'boost::gil::rgb8_image_t' to 'const boost::gil::point2<T> &' 1> with 1> [ 1> ChannelValue=boost::gil::bits8, 1> Layout=boost::gil::rgb_layout_t, 1> Loc=boost::gil::rgb8_loc_t, 1> T=ptrdiff_t 1> ] 1> and 1> [ 1> T=ptrdiff_t 1> ] 1> Reason: cannot convert from 'boost::gil::rgb8_image_t' to 'const boost::gil::point2<T>' 1> with 1> [ 1> T=ptrdiff_t 1> ] 1> No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called Any ideas? Thanks... Stephan

2 2

Linux + Boost 1.36.0 + static
by ferdinand.weiher＠gildemeister.com 05 May '09

05 May '09

coLinux gcc 3.4.5 libc 2.3.5 Boost 1.36.0 Hello, I'm new to boost AND Linux and after days trying out different things I just ask here. When starting the build process with <bjam --toolset=gcc --build-type=complete --with-thread link=static install> I get the following log: warning: Graph library does not contain optional GraphML reader. note: to enable GraphML support, set EXPAT_INCLUDE and EXPAT_LIBPATH to the note: directories containing the Expat headers and libraries, respectively. warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. WARNING: No python installation configured and autoconfiguration failed. See http://www.boost.org/libs/python/doc/building.html for configuration instructions or pass --without-python to suppress this message and silently skip all Boost.Python targets Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (don't panic: this is a strictly optional feature). ...patience... ...found 14167 targets... ...updating 43 targets... MkDir1-quick-fix-for-unix bin.v2 MkDir1-quick-fix-for-unix bin.v2/libs MkDir1-quick-fix-for-unix bin.v2/libs/thread MkDir1-quick-fix-for-unix bin.v2/libs/thread/build MkDir1-quick-fix-for-unix bin.v2/libs/thread/build/gcc-3.4.5 MkDir1-quick-fix-for-unix bin.v2/libs/thread/build/gcc-3.4.5/debug MkDir1-quick-fix-for-unix bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static MkDir1-quick-fix-for-unix bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/threading-multi gcc.compile.c++ bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/threading-multi/thread.o gcc.compile.c++ bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/threading-multi/exceptions.o gcc.compile.c++ bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/threading-multi/once.o gcc.archive bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/threading-multi/libboost_thread-gcc34-mt-d-1_36.a /usr/bin/ar: unable to rename 'bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/threading-multi/libboost_thread-gcc34-mt-d-1_36.a' reason: Input/output error "/usr/bin/ar" rc "bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/threading-multi/libboost_thread-gcc34-mt-d-1_36.a" "bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/threading-multi/thread.o" "bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/threading-multi/exceptions.o" "bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/threading-multi/once.o" ...failed gcc.archive bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/threading-multi/libboost_thread-gcc34-mt-d-1_36.a... ...removing bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/threading-multi/libboost_thread-gcc34-mt-d-1_36.a ...skipped <p/usr/local/lib>libboost_thread-gcc34-mt-d-1_36.a for lack of <pbin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/threading-multi>libboost_thread-gcc34-mt-d-1_36.a... ...skipped <p/usr/local/lib>libboost_thread-gcc34-mt-d.a for lack of <p/usr/local/lib>libboost_thread-gcc34-mt-d-1_36.a... MkDir1-quick-fix-for-unix bin.v2/libs/thread/build/gcc-3.4.5/release MkDir1-quick-fix-for-unix bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static MkDir1-quick-fix-for-unix bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/threading-multi gcc.compile.c++ bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/threading-multi/thread.o gcc.compile.c++ bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/threading-multi/exceptions.o gcc.compile.c++ bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/threading-multi/once.o gcc.archive bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/threading-multi/libboost_thread-gcc34-mt-1_36.a /usr/bin/ar: unable to rename 'bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/threading-multi/libboost_thread-gcc34-mt-1_36.a' reason: Input/output error "/usr/bin/ar" rc "bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/threading-multi/libboost_thread-gcc34-mt-1_36.a" "bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/threading-multi/thread.o" "bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/threading-multi/exceptions.o" "bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/threading-multi/once.o" ...failed gcc.archive bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/threading-multi/libboost_thread-gcc34-mt-1_36.a... ...removing bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/threading-multi/libboost_thread-gcc34-mt-1_36.a ...skipped <p/usr/local/lib>libboost_thread-gcc34-mt-1_36.a for lack of <pbin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/threading-multi>libboost_thread-gcc34-mt-1_36.a... ...skipped <p/usr/local/lib>libboost_thread-gcc34-mt.a for lack of <p/usr/local/lib>libboost_thread-gcc34-mt-1_36.a... MkDir1-quick-fix-for-unix bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/runtime-link-static MkDir1-quick-fix-for-unix bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/runtime-link-static/threading-multi gcc.compile.c++ bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/runtime-link-static/threading-multi/thread.o gcc.compile.c++ bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/runtime-link-static/threading-multi/exceptions.o gcc.compile.c++ bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/runtime-link-static/threading-multi/once.o gcc.archive bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/runtime-link-static/threading-multi/libboost_thread-gcc34-mt-sd-1_36.a /usr/bin/ar: unable to rename 'bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/runtime-link-static/threading-multi/libboost_thread-gcc34-mt-sd-1_36.a' reason: Input/output error "/usr/bin/ar" rc "bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/runtime-link-static/threading-multi/libboost_thread-gcc34-mt-sd-1_36.a" "bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/runtime-link-static/threading-multi/thread.o" "bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/runtime-link-static/threading-multi/exceptions.o" "bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/runtime-link-static/threading-multi/once.o" ...failed gcc.archive bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/runtime-link-static/threading-multi/libboost_thread-gcc34-mt-sd-1_36.a... ...removing bin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/runtime-link-static/threading-multi/libboost_thread-gcc34-mt-sd-1_36.a ...skipped <p/usr/local/lib>libboost_thread-gcc34-mt-sd-1_36.a for lack of <pbin.v2/libs/thread/build/gcc-3.4.5 /debug/link-static/runtime-link-static/threading-multi>libboost_thread-gcc34-mt-sd-1_36.a... ...skipped <p/usr/local/lib>libboost_thread-gcc34-mt-sd.a for lack of <p/usr/local/lib>libboost_thread-gcc34-mt-sd-1_36.a... MkDir1-quick-fix-for-unix bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/runtime-link-static MkDir1-quick-fix-for-unix bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/runtime-link-static/threading-multi gcc.compile.c++ bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/runtime-link-static/threading-multi/thread.o gcc.compile.c++ bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/runtime-link-static/threading-multi/exceptions.o gcc.compile.c++ bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/runtime-link-static/threading-multi/once.o gcc.archive bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/runtime-link-static/threading-multi/libboost_thread-gcc34-mt-s-1_36.a /usr/bin/ar: unable to rename 'bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/runtime-link-static/threading-multi/libboost_thread-gcc34-mt-s-1_36.a' reason: Input/output error "/usr/bin/ar" rc "bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/runtime-link-static/threading-multi/libboost_thread-gcc34-mt-s-1_36.a" "bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/runtime-link-static/threading-multi/thread.o" "bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/runtime-link-static/threading-multi/exceptions.o" "bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/runtime-link-static/threading-multi/once.o" ...failed gcc.archive bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/runtime-link-static/threading-multi/libboost_thread-gcc34-mt-s-1_36.a... ...removing bin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/runtime-link-static/threading-multi/libboost_thread-gcc34-mt-s-1_36.a ...skipped <p/usr/local/lib>libboost_thread-gcc34-mt-s-1_36.a for lack of <pbin.v2/libs/thread/build/gcc-3.4.5 /release/link-static/runtime-link-static/threading-multi>libboost_thread-gcc34-mt-s-1_36.a... ...skipped <p/usr/local/lib>libboost_thread-gcc34-mt-s.a for lack of <p/usr/local/lib>libboost_thread-gcc34-mt-s-1_36.a... ...failed updating 4 targets... ...skipped 8 targets... ...updated 31 targets... All the files get created (as far as I can tell) except the skipped and failed *.a ones. When I use "link=shared" instead of "link=static" everything works fine. I've tried different versions of Boost and bjam, different bjam options and so on but same result. What seems really strange is "unable to rename '...' reason: Input/output error". Maybe somebody can help me. Greetings, Ferd DMG Electronics GmbH, Sitz der Gesellschaft: Pfronten; Amtsgericht Kempten (Allg.), HRB 9572; Geschäftsführer: Dipl.-Ing. (TU) Rudolf Hahn; Dipl.- Wirtschaftsing. Darko Sutlar, Dipl.-Kfm. Tobias Bode Ust-Id-Nr: DE 256219491 - Umsatzsteuer-Nr: 349 / 5723 / 2713 http://www.gildemeister.com E-Mail Disclaimer Der Inhalt dieser E-Mail ist ausschliesslich fuer den/die bezeichneten Empfaenger bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein sollten, so beachten Sie bitte, dass jede Form der Kenntnisnahme, Veroeffentlichung, Vervielfaeltigung oder Weitergabe des Inhalts dieser E-Mail unzulaessig ist. Wir bitten Sie, sich in diesem Fall mit dem Absender der E-Mail in Verbindung zu setzen. Wir moechten Sie ausserdem darauf hinweisen, dass die Kommunikation per E-Mail ueber das Internet unsicher ist, da fuer unberechtigte Dritte grundsaetzlich die Moeglichkeit der Kenntnisnahme und Manipulation besteht. The information contained in this email is intended solely for the recipient(s). Access to this email by anyone else is unauthorized. If you are not the intended recipient, any form of disclosure, reproduction, distribution or any action taken or refrained from in reliance on it, is prohibited. Please notify the sender of this E-Mail immediately. We also like to inform you that communication via email over the internet is insecure because third parties may have the possibility to access and manipulate emails.

1 0

Boost.Graph with MST: getting started
by arm2arm 05 May '09

05 May '09

Hello, I would like to start to use Graph for my project, I have seen that boost.Graph has a MST implemented. My problem is that I have points in 3D/2D with properties; I would like to link them together in to MST using their distance/coordinate or some property. Then I would like to extract the groups for the given Edge length. How to organize the container? Thank you beforehand. Arman. -- View this message in context: http://www.nabble.com/Boost.Graph-with-MST%3A-getting-started-tp23383569p23… Sent from the Boost - Users mailing list archive at Nabble.com.

1 0

[Boost 1.39] different naming?
by Christoph 04 May '09

04 May '09

I built Boost 1.38 (and earlier) with the following options --buildid=xxxx --layout=system This resulted in libs named libboost_regex-mt-xxxx.so With Boost 1.39 the libs (they *are* built with multi-threading support) are named 'only' libboost_regex-xxxx.so (note the missing "-mt") When linking against Boost libs I have written -lboost_regex-mt-xxxx in my code. Was that a bad idea (I mean the including -mt part)? I can fix this by passing --buildid=mt-xxxx to get the old names, but I am curious if that change was done on purpose. (I would like to avoid having to change Boost libs' names in my makefiles with every second Boost release or so ;-) So, to make the questions clear: 1) why was the change made? 2) is linking against sth like -lboost_regex-mt a bad idea? If so, why? 3) will the new naming remain? Best regards, and thanks a bunch for a bunch of helpful libs Christoph

2 1

[serialization] Confusion serializing dynamic arrays of pointers.
by John Murray 04 May '09

04 May '09

Let me begin by saying that I am still rather new to C++ as a language. I've only taken one low level university course on the language, and most of my programs are still very limited in scope and functionality. I am attempting to use the serialization library to save and load objects from a dynamic array of pointers. The object to be serialized contains an object***. The first pointer will bring me to an array of 10 elements, from there each element contains an arbitrarily large array of pointers to objects that will be dynamic allocated as they are needed. While I understand that the library can handle simple arrays, as well as pointers to objects, I cannot seem to get it work in this instance. Attempting to serialize the pointer itself results in an error. >In static member function 'static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::text_iarchive, T = spell**]': >instantiated from 'void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::text_iarchive, T = spell**]' >instantiated from 'void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::text_iarchive, T = spell**]' >instantiated from 'void boost::archive::detail::iserializer<Archive, T>::load_object_data(boost::archive::detail::basic_iarchive&, void*, unsigned int) const [with Archive = boost::archive::text_iarchive, T = spell**]' >functions/general.cpp:85: instantiated from here This seems to make sense as there is not way for the library to serialize a pointer without knowing what it is pointing to (and array of arrays in this case). My next choice of action was to try to serialize the pointer just as I had created it during its initialization. My hope was that the library would then be able to reconstruct the object during loading. This is shown in this code. class spellbook { public: //Lots of functions ommited private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar,const unsigned int version){ ar & name; ar & spellcounts; ar & spellarraysize; for(int x=0;x<10;x++){ for(int y=0;y < 10;y++){ ar & spellptr[x][y]; } } ar & target_level; }; string name; int spellcounts[10]; //! Each element of the array keeps track of the number of spells in the spellptr int spellarraysize[10]; //! Size of the array of the spells of each level spell*** spellptr; //! This should point to a 10xY array of spell pointers. First array is of different levels, second of the spell pointers themselves int target_level; //! Shame to waste the memory, but needed to manage archives }; This compiles, but during run time i get the following error when I attempt to load the object immediately after saving it to disk. >terminate called after throwing an instance of 'boost::archive::archive_exception' > what(): stream error >Abort trap I am fairly confident it is not the save/load archive code as I am currently using what is more or less a duplicate of it to serialize other objects in the file. I'd like to keep the currently implementation of pointers as it keeps memory loads as dynamic to the needs of the application as possible. Has anyone had any experience with serializing something of this nature, or care to offer any helpful tips to get serializing and unserializing to work with this situation? I've ommited a large portion of the code as the headers get somewhat large for this posting format. I can include links to the full source code if needed. John

2 1

Re: [Boost-users] Boost-users Digest, Vol 1984, Issue 2
by John Dlugosz 04 May '09

04 May '09

> Date: Sun, 03 May 2009 21:43:59 +0100 > From: Chris Spencer <spencercw(a)googlemail.com> > Subject: [Boost-users] Filesystem: Case insensitive search on case > sensitive systems > To: boost-users(a)lists.boost.org > Message-ID: <49FE020F.6030905(a)googlemail.com> > Content-Type: text/plain; charset=UTF-8 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > > I am writing a cross-platform program which takes path names from a > Windows-originating file. As such, there is no guarantee that the paths > match the case of what is actually stored in the file system. Does > anyone have any advice on the best way to do a case-insensitive search > to get the correct path? > > Thanks, Chris. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkn+AgoACgkQ6iqRtkAADZhrFQCgxL0prbFme94Y6/D6IqNQccT+ > bWYAoPZPopoX4YyhjrkCe/u74YsjZUQM > =SavU > -----END PGP SIGNATURE----- For NTFS, the rules are in the $UpCase (reserved file #10) in the root directory. But don't forget that short-name aliases are also matched against. For FAT, the rules depend on the OEM Code Page used. That's not just because the chars are encoded differently, but the rules are different too. Specifically, does upper-casing a letter keep or remove an accent mark? Or, do some letters not have case equivalents at all? But now FAT has a "longname" in there also, which is stored in USC2. There's the ISO file system used on CDs, with or without Joliet extensions. There's the UFS file system on DVDs. Both have their own standards on what case-insensitivity means, which may or may not be followed by the OS to various degrees. Basically, the rules are specific to the file system and the individual media. If you know those rules (try looking at ReactOS), you still have to match each subdirectory along the path individually and watch for symbolic links and reparse points which can shift you to a different volume with different rules in force. Check out <http://blogs.msdn.com/michkap/archive/2007/10/24/5641619.aspx>, for example. --John (sorry about the footer) TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

1 0

Re: [Boost-users] Boost-users Digest, Vol 1984, Issue 1
by John Dlugosz 04 May '09

04 May '09

> Date: Sat, 02 May 2009 13:01:07 -0600 > From: tom fogal <tfogal(a)alumni.unh.edu> > Subject: [Boost-users] Recent compilation troubles with gcc atomics > To: boost-users(a)lists.boost.org > Message-ID: <auto-000019291789(a)sci.utah.edu> > > Hello all, > http://gcc.gnu.org/ml/gcc/2009-05/msg00039.html > > In it, he notes that the availability of these builtins is not solely > a function of the compiler version. In particular, the platform (CPU, > OS, runtime support) seems to be a factor, as well as the backend code > generation options (i.e. -march gcc compiler option). > > He also suggests that the only reliable methodology for discovering the > availability of these functions/builtins is by doing link-time tests. > I mention as much because (unverified) I think boost's current solution > is #ifdefs based on architecture and compiler version, which I think is > fighting a losing battle. > > I hope this information is useful for those stuck on the problem, > and/or boost developers. > I'm in the middle of refactoring my "atomic_counter" templates, originally in the August 1998 issues of Visual C++ Developer (<http://www.dlugosz.com/Repertoire/refman/Classics/atomic_counter_white paper.html#toptop>). Besides design changes, it targets AMD-64. My experiments showed that the compiler's intrinsic support was spotty at best, and the documentation wasn't clear as to their availability. In particular, the VC++ compiler only generates intrinsic opcodes in 64-bit targets, and links to a library function for 32. The original issue is that the supplied API is too limited. If I want a post-increment (x++), the library function does the CPU opcode which is a post increment, then incs the result again to give the new value as the result, so then my code has to subtract it back out. Why dance around it? Furthermore, it didn't handle all different word sizes. More have been added to the win32 API, but it's still missing char! My latest solution is to expose them via functions written in assembly language. They cannot be inlined. But, the synchronized opcode is so slow anyway, and the call is now so cheap, being eaten by the prefetch stages, that I concluded that it didn't matter. On AMD-64, the calling convention was defined in the CPU's documentation so all platforms should follow it. The same functions should work for all operating systems, but would need macros for the actual (mangled C++) function names. Way back when, when doing it originally, I found that inline asm in an inline function in Microsoft's compiler didn't work out very well, since inlining would destroy the calling convention and values would be in the wrong registers before the body of the code! On the other hand, the WatCom compiler had a very good inline/intrinsic generator that would let you specify asm code to emit and which registers to set up for the inlined "call". I haven't seen that compiler in years, though. I'm tempted to make the new 32-bit version as a separate asm file, too, rather than inline asm. This will be more portable across different compilers and OS's, with the potential of using macros to give the correct C++ names, and if all compilers of interest can't generate the same "fastcall" calling, have prolog/epilog macros that takes the passed parameters and puts them in registers and cleans up the call, specified separately. And, use NASM to assemble it, which allows very powerful macros and can generate many target object file formats for the different operating systems. It's still x64 and x86 specific asm code. But the very concepts at this low level is CPU specific anyway. I notice the documentation for Windows on IA64 platform has "acquire/release" stuff. That is, different ways of doing it. Trying to sweet-talk each different compiler is a losing battle, especially since its supplied set of primitives is very incomplete. I conclude that just doing it in assembly language is easier. --John TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

1 0

Using boost::assign::map_list_of with multimap
by Sean Farrow 04 May '09

04 May '09

Hi: Is there a way to use boost::assign::map_list_of() with std::multimap? If not could a list_multi_map_of function? Any help appreciated. Sean. __________ Information from ESET NOD32 Antivirus, version of virus signature database 4052 (20090504) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

2 1

Re: [Boost-users] Boost-users Digest, Vol 1983, Issue 1
by John Dlugosz 04 May '09

04 May '09

> Date: Fri, 01 May 2009 20:15:50 -0600 > From: tom fogal <tfogal(a)alumni.unh.edu> > Subject: Re: [Boost-users] General C++: Class Method Signatures > Miss-Match > To: boost-users(a)lists.boost.org > Message-ID: <auto-000019286349(a)sci.utah.edu> > > Dominique Devienne <ddevienne(a)gmail.com> writes: > > On Fri, May 1, 2009 at 10:32 AM, Dan Day <coolmandan(a)gmail.com> > wrote: > > > I thought that int represented the natural word size of the > > > architecture. If so, then wouldn't unsigned int be 64-bit on a > > > 64-bit platform as well? > > I had heard this before as well. I took a quick look through c1x-1336 > (current (?) draft of C) though, and I could not find anything to this > effect. > > Of course, that doesn't say it's not there, and I did not check the C++ > standard. > > > The few 64-bit platforms I've seen keep [unsigned] int at > > 32-bits. --DD > What is "natural"? The AMD-x64 is built on top of the 32-bit architecture. The instruction set (in 64-bit mode) uses 32 bits as the nominal and default data size for most operations. Even for memory addresses, it's a 32-bit relative-to-IP value. It takes an opcode prefix to indicate the use of 64-bit values. The memory architecture can handle 32-bit values without penalty, and you fit more of them in the cache. So 32-bit ints are not at all "unnatural". In principle, using 32-bit ints for casual use instead of gratuitously using 64-bits where you don't need the extra size will run faster. It reduces the memory bandwidth for both data and code size, even though the internal execution is the same speed in either case. --John (sorry about the footer; it's not my idea) TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

1 0

Character Encoding (was: General C++: Class Method Signatures)
by John Dlugosz 04 May '09

04 May '09

> Date: Fri, 1 May 2009 17:51:03 -0500 > From: Dominique Devienne <ddevienne(a)gmail.com> > Subject: Re: [Boost-users] General C++: Class Method Signatures > Miss-Match > To: boost-users(a)lists.boost.org > Message-ID: > <255d8d690905011551v108b95c4sbfeaa21c443ac23e(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Fri, May 1, 2009 at 10:38 AM, Etienne Philip Pretorius > <icewolfhunter(a)gmail.com> wrote: > > Wide chars as far as I know are different from platform to platform. > > Microsoft uses 16 bit wide chars while *nix uses 32 bit wide chars. > And for > > unicode I need at least 21 bits. > > It's not only a question of char size, the encoding matters. I don't > know for sure, but I bet Windows' can represent all code points by > using pairs of 16-bit wide chars (surrogate pairs). As long as you > have a way to convert the current wstring instances to a know encoding > like UTF-8, UTF-16 (bom, le, be), or UTF-32 for wire transport or > persistence, the actual representation of wstring doesn't matter. The Windows API uses 16-bit characters and calls it "Unicode". Originally it was UCS2, meaning each code point was simply a 16-bit unsigned integer. Later, they added some support for surrogate pairs, which allows codes >64K to be represented as a pair of values. This is now known as UTF-16. This only works for some of the text functions, though. Much of the API and any casual handling functions will simply count each 16-bit cell as 1 character unit. So yes, if you are using the font-related functions to draw text, you can represent any code point using UTF-16. But for opening a file, it treats the name as a sequence of 16-bit values without any understanding of surrogate pairs or duplicate meanings. For manipulating wstrings in C++, neither the standard library wcs* functions nor the wstring class deals with surrogate pairs. So if you call wsclen, for example, you get the number of elements in the wchar_t array, not the number of Unicode code points, if some of them are encoded pairs. > Of course I don't know what the encoding conversion methods would be > for Windows and Linux and *nix in general. Does Boost.IOStream provide > those in a portable fashion? I'd be interested on pointers on this > topic if you know about those methods. Thanks, --DD My limited knowledge is that Linux can use UTF-8 as the code page. Some distros do that by default. General pointer on this topic: When specifying a file or interchange format, (1) use Unicode, and (2) specify the encoding or options thereof. IMHO, manipulating strings as UTF-16 is neither here nor there. You bloat the size if you are dealing with mostly Western language text, but *still* have to deal with multi-unit sequences. So if you care about characters, really, as opposed to just how much room do you need for the representation, then use 32-bit characters (I call it "xstring") or stick with UTF-8 if that's what's loaded/saved. --John (mind the footer...) TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

1 0