Re: Boost::Threads g++ warnings

From: williamkempf_at_[hidden]
Date: 2001-10-16 08:13:09

--- In boost_at_y..., helmut.zeisel_at_a... wrote:
> --- In boost_at_y..., Darin Adler <darin_at_b...> wrote:
> > on 10/15/01 1:57 PM, williamkempf_at_h... at williamkempf_at_h...
> > wrote:
> > 
> 
> > > ../src\once.cpp:61: warning: unsigned int format, DWORD arg 
(arg 
> 3)
> > > ../src\once.cpp:61: warning: unsigned int format, pointer arg
> (arg 
> 4)
> > 
> > These are warning about values passed to a printf-family function 
> that do
> > not match the format in the printf string.
> > 

This much I understood ;).  What didn't make a lot of sense to me was 
that on Win32 platforms unsigned long (DWORD) and unsigned int are 
the same size.  So the first warning seemed to be overly pedantic.  I 
was also unsure how to handle the second warning since there's no 
gaurantee that a pointer can be converted to an integral type of a 
given size.  The %p flag would work, but would produce a string 
different from what I wanted.  That's a minor issue, I guess, since 
the string produced would still be unique, it would just be longer 
which is only a minor optimization.
 
> std::ostringstream has been designed to avoid these problems.
> Instead of
> 
>         char name[41];
>         std::sprintf(name,
>                      "2AC1A572DB6944B0A65C38C4140AF2F4%X%X",
>                      GetCurrentProcessId(), 
>                      &flag);
>         HANDLE mutex = CreateMutex(NULL, FALSE, name);
> 
> you could include <sstream> and use
> 
>         std::ostringstream name;
>         name << "2AC1A572DB6944B0A65C38C4140AF2F4"
>              << std::hex << GetCurrentProcessId() 
>              << &flag;
>         HANDLE mutex = CreateMutex(NULL, FALSE, name.str().c_str());
> 
> This is type safe and avoids potential problems with buffer 
overflows;
> in particular, it should also work on future windows version
> were the return type of GetCurrentProcessId() might change
> (IA64?)

Not likely to change.  And there's not really any chance for buffer 
overflows here... the string is of a known size.
 
> OTOH you have an additional dependecy on <sstream>
> and a (negligible?) performance penalty
> for the dynamic memory allocation in std::ostringstream.

On many platforms (loose terminology that I'm using to include 
compilers and their standard libraries) the performance of iostreams 
can be as much as 30% slower, and when you add in the dynamic memory 
allocations used by stringstream in particular this can go up a lot 
more.  I hoped to avoid any unecessary overhead in this case.  
However, it may not be feasable to do so and for portability I may 
have to switch to the stringstream approach.

Bill Kempf