- Boost - lists.boost.org

Fwd from ms.p.vc.l: Boost with VC6
by Jeff Flinn 05 Oct '05

05 Oct '05

Just an FYI related to first time boost users efforts at installation. I'm forwarding this from microsoft.public.vc.language. I've answered this to the best of my abilities in that thread, and suggested that the OP join the boost.user list. Jeff "andré m.a" <a.m.a(a)videotron.ca> wrote in message news:%2%_e.4643$f_3.44986@weber.videotron.net... > hi there. > > It's been suggested my many that i use Boost libraries. > So i went to boost.org and downloaded the win32 files. > Unziped the boost folder into : > C:\Program Files\Microsoft Visual Studio\VC98\Include\ > > even added the boost directory in the IDE using : > tools>options>directories... > > I read the docs at boost and it says that for VC6 the files > (hpp) should work as is, but every time i try to compile > something im missing static libraries like : > libboost_program_options-vc6-sgd-1_33.lib is missing. > > Wich even google in its vast DB entries is unable to > produce a single hit for. > > Then again MSDN is discouraging using VC6 and suggest > i spend a lot of money for a .Net :-} > ( very amusing ) > > Any tips would be gigantically helpfull.

2 1

Re: [boost] GUI coordinate units (Was: GUI foundations)
by Martin Bonner 05 Oct '05

05 Oct '05

----Original Message---- From: Stefan Seefeld [mailto:seefeld@sympatico.ca] Sent: 04 October 2005 14:35 To: boost(a)lists.boost.org Subject: Re: [boost] GUI coordinate units (Was: GUI foundations) > Sizes are usually given in resolution-dependent coordinates (i.e. > pixels). If you change resolution, you typically don't do that to > expose more detail, but to make your desktop 'bigger' (by making > text, widgets, etc. smaller). This seems to be a common view among developers. I can only assume they are all still young with excellent eyesight. When I moved from 800x600 to 1024x768 what I really wanted was less fuzzy letters (not more letters). I moved from 1024x768 to 1280x1024 because I got given a 17" LCD monitor. Windows-XP doesn't make a bad fist of scaling everything back again to a reasonable size, but a lot of GUIs get a bit messed up because people have done everything in pixels rather than scalable graphics. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

5 6

[Boost-bugs] [ boost-Bugs-1313543 ] range, VC 7.1, compile error.
by SourceForge.net 05 Oct '05

05 Oct '05

Bugs item #1313543, was opened at 2005-10-05 16:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1313543&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sergey Shandar (sergey_shandar) Assigned to: Nobody/Anonymous (nobody) Summary: range, VC 7.1, compile error. Initial Comment: Compiler: VC 7.1 Example: --------- #include <boost/range/iterator.hpp> template<class Container> typename boost::range_iterator<const Container>::type begin(const Container &X) { return 0; } int main() { char a[3]; int b = begin(a); return 0; } --------- The compile-time error message is --------- c:\Boost\include\boost-1_33\boost\range\iterator.hpp(37) : error C2825: 'C::iterator': cannot form a qualified name main.cpp(12) : see reference to class template instantiation 'boost::range_iterator<C>' being compiled with [ C=char [3] ] --------- It's a VC 7.1 bug but there is possibility to work around. Instead of using C::iterator by default (existing code shown below): --------- namespace boost { namespace detail { template< typename C > struct range_iterator { typedef BOOST_DEDUCED_TYPENAME C::iterator type; }; } } --------- Use C::iterator only if C is a class. Code showing the possible implementation is shown below --------- namespace boost { namespace detail { template< typename C, bool IsClass> struct range_iterator { typedef void type; }; template< typename C> struct range_iterator<C, true> { typedef BOOST_DEDUCED_TYPENAME C::iterator type; }; } } --------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1313543&group_… ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Feature Requests-1313447 ] Socket C++ library
by SourceForge.net 05 Oct '05

05 Oct '05

Feature Requests item #1313447, was opened at 2005-10-04 20:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1313447&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Socket C++ library Initial Comment: Without a socket library, C++ can't be on the net. Hope boost can do something ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1313447&group_… ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

gui - previous discussions
by rasmus ekman 05 Oct '05

05 Oct '05

Hi, Some time ago I collected a pageful of links to the discussions on gui design in the mail archives. I just uploaded the page as is to the wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostDevelGu… - also I very impolitely linked to it at the *top* of the wiki BoostGUI page. I thought it might be one resource for future discussions - it feels some of the threads cover a lot of the same ground. Uh, rephrase to a more positive note: There's quite a bit there to learn or at least consider if you're thinking about the design of a modern gui toolkit! Regards, re

1 0

Re: [boost] BOOST_ASSERT and __assume on MSVC
by brangdon＠cix.compulink.co.uk 04 Oct '05

04 Oct '05

In-Reply-To: <200509282055.j8SKtbXI017230(a)shannonhoon.balstatdev.susq.com> stewart(a)sig.com (Rob Stewart) wrote (abridged): > if (!e) > { > BOOST_ASSERT(false); > __assume(false); > } > > The optimizer can't elide the entire else clause because > BOOST_ASSERT(false) is in it. Do you agree that if the code was: int x = 0; if (!e) { ++x; __assume(false); } cout << x; then the compiler can elide the increment? At this stage I am trying to convince myself that you understand the point I was making, whether or not you agree with how it applies to BOOST_ASSERT. __assume(false) can have retrospective effects. -- Dave Harris, Nottingham, UK.

5 9

Re: [boost] Are there any interest in a pimpl library?
by Martin Bonner 04 Oct '05

04 Oct '05

----Original Message---- From: Asger Mangaard [mailto:tmb@tmbproductions.com] Sent: 27 September 2005 16:13 To: boost(a)lists.boost.org Subject: Re: [boost] Are there any interest in a pimpl library? >> Could you be more specific as to what functionality such a library >> would supply? If you already have an implementation then an example >> of it's use would be interesting. That was my immediate reaction too. >> It is my understanding that the pimpl idiom is fairly simple yet >> also class specific. I currently implement it like this: [snip classic pimpl idiom] > The only thing my library does is to initialize the forward declared > class, using heap or static memory through policies. Also, provides an > easy way of accessing the data. > > Eg. > > .hpp > > boost::pimpl<struct CMyData> m_MyData; > > .cpp > > struct CMyData > { > CMyData() > : m_Integer(0) > { > } > int m_Integer; > }; > > /// Data access > m_MyData->m_Integer = 2341; > > The CMyData will be initialized the first time its data members are > accessed. That means each use of m_MyData operator ->() has got to check whether the structure is initialized or not, and initialize it if so. Isn't it much easier to initialize the pimpl struct in the constructor of the outer class? I also don't see how much easier it can get to access the data than to write: pimpl->m_Integer -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

7 27

Re: [boost] [asio] init acceptor to reuse_address?
by BRIDGES Dick 04 Oct '05

04 Oct '05

Hi Chris. > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of > Christopher Kohlhoff > Sent: Monday, October 03, 2005 3:01 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] [asio] init acceptor to reuse_address? > > > Hi Dick, > > --- BRIDGES Dick <Dick.Bridges(a)us.thalesgroup.com> wrote: [snip] > > Mumbling something about defaulting modern socket libraries > > to SO_REUSEADDR, > > Do you think I should change the default to set SO_REUSEADDR to true? > At the moment I leave all options to default to whatever the OS > provides. Is there a good reason why all OSes (that I know of) have it > default to false I wonder? Or is it just historical? No. SO_REUSEADDR does increase the attack surface. Not a lot and less now than in the past but IMHO there's no point in helping the bad guys even a little bit if it's not required. Besides, I doubt all that many people would find it useful. My mumbling was aimed more toward myself than anything else - I have written a fair amount of "server" code and should have developed better habits by now. ;) [snip] > > asio::ipv4::tcp::endpoint endpoint(port); > acceptor_.open(endpoint.protocol()); > acceptor_.set_option(asio::socket_acceptor::reuse_address(true)); > acceptor_.bind(endpoint); > acceptor_.listen(); > acceptor_.async_accept(new_connection_->socket(), > boost::bind(&server::handle_accept, this, > asio::placeholders::error)); > > (From the new http example I've written: > http://cvs.sourceforge.net/viewcvs.py/asio/asio/src/examples/ > http/server/server.cpp?rev=1.1&view=markup). Hmmm. The copy of the library I downloaded on 14 September doesn't have socket_acceptor::reuse_address and linux.softpedia.com says the last update was 5 September. I used stream_socket::reuse_address instead and that worked. Is there a newer version of the library somewhere else? Other than that one substitution, this fixed the problem. I would like to see this initialization code pushed back down into the acceptor. Maybe something along the lines of an "option_policy", but I can't come up with anything to suggest that isn't more trouble than it's worth. Thanks - *AGAIN* - for the help. Regards, Dick

2 1

[relational] Relational Model Library
by Calum Grant 04 Oct '05

04 Oct '05

Hi all, I have recently completed a library for implementing relational models in C++. Using template metaprogramming, multi-index containers can be manipulated using SQL-style queries, while retaining type-safety and efficiency. The web page is http://visula.org/relational This might be an appropriate interface for the database library that was recently discussed. This is not the same as Relational Template Library, which uses an entirely different interface. Is there any interest in providing relational containers in Boost? Are there any features/improvements you can suggest for RML? Many thanks, Calum

13 44

boost::dynamic_array
by Boris 04 Oct '05

04 Oct '05

I stumbled about boost::dynamic_bitset in the documentation which is a runtime sized version of std::bitset. Now I wonder why there is no boost::dynamic_array. We have boost::array but just like with std::bitset you need to know the size at compile time. Is there any interest in boost::dynamic_array (I mean is anyone else interested except me :-)? Boris

7 9