- Boost-users - lists.boost.org

Re: Compiling CRC
by Daryle Walker 04 Apr '02

04 Apr '02

on 4/3/02 3:54 PM, David Brownell at david_brownell(a)hotmail.com wrote: > Daryle, thanks for your response. The code does work on VC6. Here is > the crc.hpp related errors I get when I compile with VC7. [TRUNCATE] I think the first error means that VC7 is choking on the forward declaration of crc_optimal. The other errors cascade from that one. What does "BOOST_CRC_PARM_TYPE" expand to on VC7? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com

2 1

preprocessor lists question
by jkharris01 04 Apr '02

04 Apr '02

I want to have some way to automatically put the right number of close parentheses on a list (using boost/preprocessor.hpp). For instance, given this list: #define _THE_LIST \ BOOST_PP_LIST_CONS(red, \ BOOST_PP_LIST_CONS(orange, \ BOOST_PP_LIST_CONS(yellow, \ BOOST_PP_LIST_CONS(green, \ BOOST_PP_LIST_CONS(blue, \ BOOST_PP_LIST_CONS(violet, \ BOOST_PP_LIST_CONS(gray, \ BOOST_PP_LIST_CONS(white, \ BOOST_PP_LIST_NIL )))))))) is there a way to automatically generate the eight close parentheses?

1 0

Re: Compiling CRC
by Daryle Walker 03 Apr '02

03 Apr '02

on 3/29/02 11:05 AM, David Brownell at david_brownell(a)hotmail.com wrote: > I have the following code that doesn't compile using VC 7.0. I am > getting many errors in crc.hpp. Am I missing something simple here? I > have just glanced at the manual, so please be gentle with the RTFM > responses :) > > TIA, > David Brownell > > #include<iostream> > #include "boost\crc.hpp" > > int main(void) > { > const unsigned char DATA[] = { 1, 2, 3, 4, 5 }; > > boost::crc_32_type crc; > > crc.reset(); > crc.process_bytes(DATA, sizeof(DATA) / sizeof(*DATA)); > > std::cout << crc.checksum() << std::endl; > return(true); > } I ran it just fine (and got "1191942644" printed). There may be some VC++ 7 quirks. Did you try it with VC++ 6? What error messages did you get? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com

2 1

Building graphviz under VC6
by Wolf, Frank 03 Apr '02

03 Apr '02

Has anyone succesfully build the graphviz libs under VC6? I tried to do so, but ran into fatal error LNK1179 I really would be grateful for any help Thanks. Frank

2 1

Non-scoped mutex's with Boost.Threads
by Dale Peakall 02 Apr '02

02 Apr '02

I believe it is possible to use Boost.Threads mutexes without the need to use a scoped_lock style guard. I vaguely recall it being something to do with a mutex_traits class or something (but I can't find any documentation). Can anyone help me out. Thanks. - Dale.

2 1

suggestion: harness destructor in scoped_ptr<>::reset
by jlehrer 02 Apr '02

02 Apr '02

Before I propose this to main boost mailing list, I wanted to see what others thought of this idea. I propose changing the following method on scoped_ptr<>: void reset(T* p=0) {if(ptr!=p) {checked_delete(ptr); ptr=p;}} to void reset(T* p=0) {if(ptr!=p) {scoped_ptr<T>(p).swap(*this);}} void swap(scoped_ptr<T>& other) {std::swap(ptr,other.ptr);} Of course, we would then have global methods for std::swap, as there are for the other smart pointers, to map to this method. Finally, the same change should be made to scoped_array<>. shared_ptr<> and shared_array<> already have these semantics. The idea is to harness the destructor of the scoped_ptr in order to delete the pointer, rather than calling checked_delete in two places. This has a few advantages over the old code: 1- destruction is handled in one place, the destructor. This seems natural, and gives developers one place to look to see what happens when a pointer is deleted 2- I have had occasion to specialize the destructor of the scoped_ptr<> class to do something other than delete. In that case, I needed to specialize the destructor AND the reset method. With this change, one would only need to specialize the destructor and reset would harness that specialization as well. Comments?

2 1

Fw: Boost.Threads thread_specific_ptr and more
by Philip Ashmore 02 Apr '02

02 Apr '02

Oops! I didn't know I had to join the group! Regards, Philip Ashmore ----- Original Message ----- From: "Philip Ashmore" <philip_ashmore(a)hotmail.com> To: "William Kempf" <williamkempf(a)hotmail.com> Cc: <Boost-Users(a)yahoogroups.com> Sent: Wednesday, March 20, 2002 12:29 PM Subject: Re: Boost.Threads thread_specific_ptr and more > Hi there. > > Rather than respond to your points directly, I've written a document > outlining my ideas on how static data could be managed more clearly. This > obviously relates to thread_specific_ptr as instances are global, hence > static, but is quite general and therefore hopefully more useful. > > Regards, > Philip Ashmore. > ----- Original Message ----- > From: "William Kempf" <williamkempf(a)hotmail.com> > To: <philip_ashmore(a)hotmail.com> > Sent: Friday, March 15, 2002 3:13 PM > Subject: Re: Boost.Threads thread_specific_ptr and more > > > > >From: "Philip Ashmore" <philip_ashmore(a)hotmail.com> > > >To: <williamkempf(a)hotmail.com> > > >Subject: Boost.Threads thread_specific_ptr and more > > >Date: Fri, 15 Mar 2002 14:37:39 -0000 > > > > > >Hi there. > > > > > >first of all, I'm assuming that it's appropriate to contact you directly > regarding some queries I have regarding the Boost.Threads > thread_specific_ptr<T>. > > > > Yes, though if you'd send it to the Boost Users list on Yahoo Groups > (Boost-Users(a)yahoogroups.com) instead others could benefit from the answer > as well. > > > > >As it happens I developed something similar before I became aware of > Boost.Threads thread_specific_ptr<T>, but with the following extra features > you might consider discussing or adding. > > > > > >1. Automatic construction of new instances of T as needed when > dereferenced. > > > > I considered this and rejected it, mostly because this behavior may be > surprising to users. Another issue is that this would require T to be > default constructable, which will limit the usefulness at least somewhat. > > > > >2. Assignment to thread_specific_ptr<T> of a local variable of type T. > This is basically already there with reset() but an explicit template class > could handle connection and disconnection, coping with exceptions. > > > > Could you elaborate? I'm not sure I understand why you think an > assignment operator would be better then reset(). > > > > >3. An optional Structor class template argument. Here the Structor would > know how to create and destroy instances of T, useful when T can be used in > different contexts. > > > > This sounds like an Allocator, and if it wasn't a standard Allocator then > it could be used to eliminate one of the problems I referred to in (1), but > beyond this I don't see any benefit. > > > > >4. Automatic cleanup of instances of T when the thread_specific_ptr<T> > goes out of scope. These would be useful when you aren't in control of the > thread creation or destruction. > > > > To be portable, thread_specific_ptr<> must be used only to instantiate > global variables (or the equivalent static variants). So, this one can't be > done (or more specifically adds 0 benefit). > > > > > This relates to static instance management. As you may know, some > compilers (or maybe it's C++ itself) have problems if you have static > instances of classes that have non-trivial static data members. The idiom of > clients and managers is one solution - manager lifetimes enclose client > lifetimes. I've implemented this and it works. > > > > I'm not sure that I'm aware of the problem you're alluding to. Can you > elaborate? > > > > >A more general idiom is a dependency tree, where wrapper objects declare > their dependency explicitly and a functor tree is created that is > independent of the order of static construction (a map would work here). > This tree is traversed during start-up and shutdown (using a scoping object) > to ensure correct instantiation and destruction. > > > > Are you referring to issues with the order of construction/destruction for > global data? If you are, there is no universal solution to this problem and > I'm not about to try and address it. > > > > >It takes over work that the compiler should do correctly but doesn't (at > least not on Visual C++ 6.0 sp5). > > >This would effectively solve all > static-object-dependency-across-libraries issues in a portable way. > > >Maybe this merits a file of its own in Boost.Utility. What do you think? > > > > I think I need more explanation and possibly code examples. > > > > Bill Kempf > > williamkempf(a)hotmail.com > > > > > [Non-text portions of this message have been removed]

2 2

How to build boost to get proper boost::regex configuration?
by rnicz 01 Apr '02

01 Apr '02

I've build boost on Windows NT4.0 with following settings: JAM_TOOLSET=VISUALC TOOLS=msvc and until now everything works fine. But when I tried to use boost::regex library I found that I got wrong libraries: I got libboost_regex.lib in four directories: 1) libs\regex\build\bin\libboost_regex.dll\msvc\debug 2) libs\regex\build\bin\libboost_regex.dll\msvc\release 3) libs\regex\build\bin\libboost_regex.lib\msvc\debug\runtime-link- dynamic 4) libs\regex\build\bin\libboost_regex.lib\msvc\debug\runtime-link- dynamic but now when I try to use boost::regex library file regex_library_include.hpp forecs linking against library with name like vc6-re300l.lib. Is there a way to get proper libraries when boost is built or to force compiler to use libboost_regex.lib during linking? Thank you in advance. Best regards Ryszard Niewisiewicz

3 5

Unable to compile boost_1_27_0 with Visual C++ .net - MORE...
by deep_thought_or_not 31 Mar '02

31 Mar '02

BTW I also had to update the Jamrules for msvc, such that I had to change the prog names "cl", "link" to "cl.exe" and "link.exe" respectively. For some reason, I have to specify the extension to run a program. Does not work without it. I am NOT doing this through a cygwin shell.

1 0

Unable to compile boost_1_27_0 with Visual C++ .net
by deep_thought_or_not 31 Mar '02

31 Mar '02

C:\downloads\boostlib\boost_1_27_0\libs\graph\build>jam.exe - sBOOST_ROOT=..\..\. . -sTOOLS="msvc" ...found 151 targets... ...updating 4 targets... msvc-C++-action ..\..\..\libs\graph\build\bin\libbgl- viz\msvc\debug\inlining-on\ runtime-link-dynamic\graphviz_graph_parser.obj graphviz_graph_parser.cpp ..\..\..\boost\type_traits\composite_traits.hpp(155) : fatal error C1001: INTERN AL COMPILER ERROR (compiler file 'msc1.cpp', line 2844) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information cl.exe /Zm750 -nologo -GX -c /Zi /Od /Ob1 /GX /GR /MDd - I"..\..\..\libs \graph\build" -I"." -I"..\..\.." -I"C:\Program\include" - I"Files\Microsoft\incl ude" -I"Visual\include" -I"Studio\include" -I".NET\VC7\include" - Fo"..\..\..\li bs\graph\build\bin\libbgl-viz\msvc\debug\inlining-on\runtime-link- dynamic\graphv iz_graph_parser.obj" -Tp"../src\graphviz_graph_parser.cpp" ...failed msvc-C++-action ..\..\..\libs\graph\build\bin\libbgl- viz\msvc\debug\in lining-on\runtime-link-dynamic\graphviz_graph_parser.obj ... msvc-C++-action ..\..\..\libs\graph\build\bin\libbgl- viz\msvc\debug\inlining-on\

1 0