Re: [boost] BOOST TEST and strict /Za no lanugage extensions option -virturenot fully rewarded?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 03 September 2003 15:56, Paul A. Bristow wrote: > #ifdef _MSC_VER // or BOOST_MSVC? > #pragma warning (disable : 4511) // copy operator could not be generated > #pragma warning (disable : 4512) // assignment operator could not be > #endif // _MSC_VER In this case, BOOST_MSVC is the right one, possibly with a version. The reason is that other (IMO thus broken) compilers also define that symbol ... However, I seem to remember that that is documented. If not, I'm probably confusing this with STLport sources. Uli -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/VksSwVdGSYi8Mq8RAs7KAJ4xnOaAlDJwjf32LETGOK2AvqbqBwCdEOu/ QH/ZHMrAzWmpS5XWYf9g1SA= =DDqA -END PGP SIGNATURE- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Problem using bjam with g++ 3.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 20 August 2003 20:41, Maciej Sobczak wrote: > This is my first attempt to build Boost 1.30.2 on FreeBSD with gcc 3.2 > installed. Debian 3.0/x86 here. > The command: > $ tools/build/jam_src/bin.freebsd/bjam "-sTOOLS=gcc" > builds Boost using the default gcc and g++ compilers. Following the > docs, I tried to do: > > $ tools/build/jam_src/bin.freebsd/bjam "-sTOOLS=gcc" "-sGXX=g++32" > "-sGCC=gcc32" > > but I can see that still the default versions are used. Same problem here, using both 1.30.0 and 1.30.2. I have found a workaroud, it consists of deactiating two lines in gcc-tools.jam: flags gcc GXX : $(GXX) ; flags gcc GCC : $(GCC) ; When these two are commented, the build uses the explicitly given compiler. I also 'fixed' a totally different related problem, that boost is totally ignorant of the compiler-version as far as gcc is concerned. In order to build different versions for different GCCs, I simply copied gcc-tools.jam to gcc-3.2-tools.jam. Hmm, maybe these things are only tangentially on-topic here, since there is a jamboost-mailinglist. However, I remember trying to subscribe to it, but was kept off by - - the sheer amount of personal information yahoo wants to collect - - the fact that their crappy webinterface requires java for some parts I can imagine that being asked defore, but isn't there a way to either loosen these restrictions or move to a sane provider for MLs ? cheers Uli P.S. What I just found out to work is accessing that list via the gmane nntp access (haven't tested posting yet though). -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/RJx8wVdGSYi8Mq8RAj4XAJ9UYyDJvMVRYUm9cxUtkrGOMqr3TgCcCy3w FHTq3CCxrc9VJRHaE+/e64M= =LdIx -END PGP SIGNATURE- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] stlport & gcc support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 20 August 2003 02:02, Trey Jackson wrote: > It appears that stlport is only used with gcc 2.95.3 (and in Windows > with Intel's C++ compiler and MS C++ 6.0). > > Is boost moving away from supporting stlport? Or are the regressions > not being run for some other reason? 1. GCC3 has a stdlibrary that deserves its name. Using STLport for the one that came with earlier versions isn't necessary anymore. 2. Leaving out the early beta-versions of GCC (3.0, 3.1), there is no support for the 3.x branch in any official STLport release. People are actively working on it though, see the forum on stlport.org. Uli -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Qx0bwVdGSYi8Mq8RAiIMAJ9IqzfKAV1w4SYhRlduDIwEnhsn1wCdE5Zu 6blDoZrf8ur579so4Fo6QVY= =b1JW -END PGP SIGNATURE- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] reflect ABI in libname
Greetings! The problem: - AFAIK, the two[1] libs built from boost always result in e.g. libboost_thread.so. The problem is that currently no OS has support for embedding the required ABI[2] into the runtime-linker info, therefore it only knows a libray name. When it finds a library but that lib has a wrong ABI, it fails more or less early and with more or less meaningful error-messages. The workarounds: - 1. not using more than one compiler on a system. This works on a few Unix-like platforms where a compiler is part of the system but even there, people sometimes want to install a different one for various reasons. 2. use static linking. Works, but we don't want static linking. 3. supply a path to the proper lib explicitly. This is already a pretty good solution, apart from the fact that there are no "default install paths for ABI XYZ". 4. encode the ABI in the library-name. This solution is e.g. used by STLport on win32: stlport_vc645.dll is STLport 4.5 compiled with VC6. I'd like to have boost adopt version 4 of it. Note that apart from the ABI itself, we'd also have to encode the stdlibrary into the name because std::string from GCC has a different binary layout than the one from STLport. The name would then be like this: _[_].so The stdlib would be optional because a) not every lib necessarily uses it b) when not given, the default one that comes with the compiler is assumed. For the tags for compiler and stdlib, I'd start this list: gcc2.95 - for GCC 2.95 gcc2.96 - for the evil thing known as "GCC 2.96" (http://gcc.gnu.org/gcc-2.96.html) gcc3.2 - for GCC 3.0 - 3.2 gcc3.3 - for GCC 3.3 vc6 - MS visual C++ 6 vc7 - (anyone a clue if there is a version 7 or if that version was marketed as .Net ?) stlp4.5 - STLport 4.5 which mostly describes what compilers I use. Drawbacks: --- There is no such thing as "this compiler's ABI". GCC 3.3 by default emits the GCC3.2-ABI unless told differently. VC7's compiler finally makes wchar_t a distinct type, at least if told so by a commandline switch. I'm sure other compilers have their own ways to achieve the same. No, I don't have a solution to this and I don't think there is one. I fear someone will have to step up and say "for XYZ 3.14 the command-line switches have to be --ph00=4". There will be people that wont like that decision, but there wont be a way around it. In case enough good arguments speak for a change, the next version of boost might change to a different setting for the compiler. Else, above workarounds can still be applied. One big advantage to me is that I can simply link an app against say libboostthread1.30_gcc3.2.so and, assuming I didn't mess it up, be sure it runs on another system with that lib. It also means that boost could theoretically distribute compiled versions of its libs. Options: - People often like having a 'debug-version' around that usually includes some assertions and is not stripped. Adding that as info to the libname in a uniform fashion would also be nice (I'd just append a '_debug' or '_dbg'). Yes, I know that all this is not ideal. However, I believe that the resulting chaos is much smaller than it could be and better than the status quo. It also means that mistakes will be made, but I'm willing to make them. I have the hope that we can agree on a common ABI for most cases and the rest can still use other means. Not daring to make a mistake for lack of a perfect solution is the greater pain for me. Ulrich Eckhardt [1] threads and Python-bindings (and regex ?) [2] Application Binary Interface. Different C++ compiler's objectcode can't be mixed since e.g. name-mangling or calling conventions are different. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] qt and msvc
On Friday 27 June 2003 20:02, gedalia pasternak wrote: >I've just started playing with bjam and I was wondering if anyone > could enlighten me about using qt and msdev 6.0. Reading the docs seems > to indicate that qt can't be use with msvc but seems like it should be a > straight forward thing to do. Qt = the toolkit from Trolltech ? msvc = MS Visual C++ ? If those assumptions are right, then it is a bit OT here; also, the solution is to simply RTFM that comes with Qt. If you're having problems with bjam, I humbly suggest asking something specific or describing a problem differently than 'doesn't work'. Ulrich Eckhardt ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] why is config not part of the public boost interface ?
Hi! I'm talking about http://boost.org/libs/config/config.htm. In http://boost.org/libs/libraries.htm#workarounds it says 'not intended for library users'. Why not ? I just stumbled across this some time ago and was very surprised because I use exactly that in quite some code that doesn't otherwise use any 'real code' from boost... Ulrich Eckhardt ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Threads and msvc 7
On Thursday 12 June 2003 17:05, William E. Kempf wrote: > JOLY Loic said: > > 1/ Dynamic libraries > > Although I compiled boost with the option "-sBUILD=debug release > > static/dynamic", the library is still generated as a DLL. > > I do not exactly know what is meant by "static" in this case. > > specifies how you link against the C RTL, not what type of > library will be built. > > Currently (and for the forseeable future), Boost.Threads will only produce > dynamic link libraries. Read the mail archives for a detailed explanation > of why. There is on rather hackish way to use static linkage. We simply setup three .cpp-files that included the .cpp-files from out of the boost sourcetree. Works fine for 1.28 and 1.29 and only required one conditional for 1.30. If there is interest, I can post these files here (I'm not at work atm...). hth Ulrich Eckhardt ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Filesystem library name
On Wednesday 15 January 2003 15:49, you wrote: > At 04:25 AM 1/15/2003, Steven Kirk wrote: > >windows. Judging by the naming convention used by the other current boost > >libraries, shouldn't this library be called "libboost_filesystem.lib"? > > Yes, I guess. I'll add it to the do list. > Isn't there a big flaw in that naming-convention ? It means I can't install a version compiled for different compilers due to their differing ABIs. Therefore, I'd rather go for libboost__-version.lib 'name' being 'filesystem' in this case and 'ABI-tag' an identifier for the compiler, possibly including the stdlib. (note: STLport already uses such a scheme, I'd prefer just stealing their ABI-tags if there are no good reasons to do otherwise). Just my 2ยข Ulrich Eckhardt ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] bidirectional pointer proposal
#include
I was recently having a case where I was coupling two objects loosely. Both
needed to know about each other, but the connection was not static, they
sometimes where separated and reconnected somewhere else. For the curious, I
was connecting a propertylist-widget with a container of entries for the list.
I currently fixed the issue by making some friend-declarations, some asserts
and just 'paying attention that it works', but this is of course not
satisfactory. I thus started thinking about a bidi_ptr<> template
Any suggestions ? Is this a worthwhile idiom ?
cheers
Ulrich Eckhardt
Outline:
- takes two types as template-arguments, the types of the owners that are to
be connected.
- bidi_ptr<>s come in pairs, bidi_ptr is complementary to bidi_ptr
- every bidi_ptr mainly consists of two pointers, one points to the owning
object (m_owner), the other to the complementary bidi_ptr<> (m_peer)
- assignment is defined as 'void bidi_ptr::operator=(bidi_ptr&rhs)'
Note that is doesn't return a reference and that 'rhs' is not a const
reference. This is used to 'connect' two peers. Also note that 'a = b' has
the same effect as 'b = a'.
- destruction of either bidi_ptr results in the peer being nulled
- redirecting a pointer to a new peer nulls the former peer
- pointer-like behaviour (*,->,get()) is implemented by accessing
'm_peer->m_owner'
- operator! and conversion to a boolean are mostly copied from
boost::shared_ptr
TODO:
- (how) can I implement that I can connect a bidi_ptr to a
bidi_ptr ?
- bidi_ptr needs to be initialized with 'this' and store that pointer. I'm a
bit dissatisfied with that, because it effectively doubles the
memory-requirement and is not necessary (oversimplified example: 'owner =
this-0x8') since it should easily be computed.
- I have no idea if operator safe_bool() is properly implemented, because I
don't understand the whys and hows of it, anyone a pointer to the rationale
for it ?
- using assignment for connecting peers warps the 'normal' modus operandi of
assignment, should I rather us an auxillary function ?
- usually, I would make bidi_ptr a friend of bidi_ptr, because it
needs access to its peers internals in order to not work recursively. This
doesn't work with my compiler if B is the same as A, the compiler complains
that any class is implicitly its own friend. Therefore all data is currently
public.
- what should operator-> or * do when there is no peer attached ?
- provide an implementation that uses a non-template base-class with two
void-pointers, with derived classes only doing the casts. Measure executable
size with and without.
#include "bidi_ptr.h"
#include
struct X;
struct Y;
struct Z;
struct X
{
X():m_pY(this), m_pX(this){}
void test() const;
void notify() const
{ std::cerr << "X::notify()\n"; }
bidi_ptr m_pY;
bidi_ptr m_pX;
};
struct Y
{
Y():m_pX(this){}
void notify() const
{ std::cerr << "Y::notify()\n"; }
bidi_ptr m_pX;
};
void X::test() const
{
std::cerr << "X::test()\n";
if(m_pX)
m_pX->notify();
if(m_pY)
m_pY->notify();
}
int main()
{
X x;
{
Y y;
connect(x.m_pY, y.m_pX);
connect(x.m_pX, x.m_pX);
x.test();
}
x.test();
return 0;
}
#ifndef BIDI_SMART_POINTER_H
#define BIDI_SMART_POINTER_H
#include
template
class bidi_ptr
{
typedef bidi_ptr this_type;
typedef bidi_ptr complement_type;
// not default-constructible
bidi_ptr();
public:
/** you always have to init a bidi-pointer with the owning object,
i.e. this. */
bidi_ptr(ThisType* owner):m_owner(owner),m_peer(0)
{ assert(m_owner);}
/** connect two pointers
Note:
- 'p1 = p2' as the same postcondition as 'p2 = p1'
- return-type is void because expressions like 'p1=p2=p3' make no sense
- the other pointer is taken by non-const reference
*/
void operator=(bidi_ptr& other)
{
if(m_peer!=&other)
{
other.reset();
reset();
m_peer = &other;
other.m_peer = this;
}
}
//friend class bidi_ptr;
~bidi_ptr()
{ reset();}
void reset()
{
if(m_peer)
m_peer->m_peer = 0;
m_peer = 0;
}
typedef bool (this_type::*safe_bool)() const;
operator safe_bool() const
{
return m_peer?&this_type::operator!:0;
}
bool operator!()const
{ return m_peer == 0; }
OtherType* get() const
{
