Boost Users :

Christian.Hoffmann_at_[hidden]

--
Christian Hoffmann                    
Trema Laboratories SARL 
-----Original Message-----
From: boost-users-request_at_[hidden]
[mailto:boost-users-request_at_[hidden]] 
Sent: Friday, January 21, 2005 6:12 PM
To: boost-users_at_[hidden]
Subject: Boost-users Digest, Vol 437, Issue 3
Send Boost-users mailing list submissions to
	boost-users_at_[hidden]
To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.boost.org/mailman/listinfo.cgi/boost-users
or, via email, send a message with subject or body 'help' to
	boost-users-request_at_[hidden]
You can reach the person managing the list at
	boost-users-owner_at_[hidden]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Boost-users digest..."
Today's Topics:
   1. Re: strange filesystem dll behaviour (Beman Dawes)
   2. Re: unordered_map/hash_table bug? (Daniel James)
   3. Re: Re: (newbie) Linking problem using unit
testframework(Mac
      OSX 10.3.7 gcc 3.3 XCode 1.5). (Gennadiy Rozental)
----------------------------------------------------------------------
Message: 1
Date: Fri, 21 Jan 2005 10:18:02 -0500
From: Beman Dawes <bdawes_at_[hidden]>
Subject: Re: [Boost-users] strange filesystem dll behaviour
To: boost-users_at_[hidden], boost-users_at_[hidden]
Message-ID: <6.0.3.0.2.20050121100502.049f35e0_at_[hidden]>
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 01:12 AM 1/20/2005, Paul wrote:
 >I looked deeper into the problem, and hacked up boost a little to find
 >out that the problem is the following check:
 >
 >       if ( (checker == no_check || checker == native) && src.size()
>= 2 
)
 >at path_posix_windows.cpp:243
 >
 >specifically checker==native.
 >
 >I had constructed path with boost::filesystem::native, but when I
hacked
 >it up to do the following:
 >
 >#     ifdef BOOST_WINDOWS
 >       std::stringstream ss; ss << "checker=" <<
 >reinterpret_cast<unsigned long>(checker) << std::endl
 >	      << "native=" << reinterpret_cast<unsigned long>(native) <<
 >std::endl;
 >       boost::throw_exception( filesystem_error(
 >	"boost::filesystem::path",
 >	ss.str() ));
 >
 >       if ( (checker == no_check || checker == native) && src.size()
>= 2 
)
 >
 >
 >I got the following results from calling the line:
 >boost::filesystem::path p(s,boost::filesystem::native);
 >
 >
 >linking to libboost_filesystem-mgw-d-1_32.lib:
 >checker=4201048   native=4201048
 >
 >linking to boost_filesystem-mgw-d-1_32.dll:
 >checker=4263776   native=1649966248
 >
 >
 >so, it appears that testing the checker using the address of a
function
 >is unreliable in a DLL context?  Have I compiled my program/library
 >incorrectly?  I am not too familiar with DLL details etc, can someone
 >else please shed some light on this?
I'm not a DLL expert either, but it certainly looks like there is some 
problem with address of functions across DLL boundaries.
This code will be going away in the next version of the library, so I'm
not 
sure if it is worth putting a lot of effort into fixing it. But I'll try
to 
reproduce the problem here. If it does reproduce, it shouldn't be too
hard 
to come up with an interim fix.
Thanks for the report,
--Beman
------------------------------
Message: 2
Date: Fri, 21 Jan 2005 16:15:48 +0000
From: Daniel James <daniel_at_[hidden]>
Subject: [Boost-users] Re: unordered_map/hash_table bug?
To: boost-users_at_[hidden]
Message-ID: <csr9ro$ma$1_at_[hidden]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Thorsten Ottosen wrote:
> "Martin Wartens" <martin.wartens_at_[hidden]> wrote in message 
> news:380-22005121815022188_at_my-mail.ch...
> Hi,
> has anybody tried the implementation of unordered map that can be
found at
>
http://groups.yahoo.com/group/boost/files/jtc1-sc22-wg21-2003-n1456.tar.
gz ?
> I believe there is a bug in the rehash function of the underlying
> hash_table. The new bucket indices are computed using the old number
of
> buckets. That means that the items stored in these buckets cannot be
found
> anymore later.
> -------
> 
> Btw, would you mind to submit a patch to me to fix this bug?
> 
> Thanks
> 
> Thorsten 
Hi Thorsten,
I'm working a new version which fixes this (and a few other) bugs. I'll 
upload it the file vault soon.
Daniel
------------------------------
Message: 3
Date: Fri, 21 Jan 2005 11:21:43 -0500
From: "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]>
Subject: [Boost-users] Re: Re: (newbie) Linking problem using unit
	testframework(Mac OSX 10.3.7 gcc 3.3 XCode 1.5).
To: boost-users_at_[hidden]
Message-ID: <csra6n$1sg$1_at_[hidden]>
> c++filt _ZTv0_n12_NSoD0Ev
> virtual thunk to std::basic_ostream<char, std::char_traits<char>
>::~basic_ostream()
> Then I tried to run just this:
> #include <iostream>
>
> int main (int arc, char** argv)
> {
> std::cout << "test";
> }
> ... and it failed with the same error.
> However, if I remove from the project the unit test framework files,
it
runs fine.
Hmm...
> I am using libstdc++.a. I don't understand what is happening.
So do I.
> Why when I add the unit test framework code it doesn't find the
standard
library ~basic_ostream() anymore ?
Most probably looks like compiler bug
> It seems these last 5 years doing only Java got me really rusty with
C++
(I'd rather work with C++ but the market forced me to go to Java).
I don't think 'last 5 years doing only Java' has anything to do with
this.
Let's try couple more thigs:
1. Could you locate where this undefined symbol referenced from?
2. Could you build framework as a standalone library and link with it?
Gennadiy
------------------------------
_______________________________________________
Boost-users mailing list
Boost-users_at_[hidden]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
End of Boost-users Digest, Vol 437, Issue 3
*******************************************
This message, including any attachments, is intended only for the person(s) to whom it is addressed. If you received it in error, please let us know and delete the message from your system. This message may be confidential and may fall under the duty of non-disclosure. Any use by others than the intended addressee is prohibited. Trema shall not be liable for any damage related to the electronic transmission of this message, such as failure or delay of its delivery, interception or manipulation by third parties, or transmission of viruses or other malicious code.