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
> > > ../src\once.cpp:61: warning: unsigned int format, pointer arg
> > 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;
> 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
> in particular, it should also work on future windows version
> were the return type of GetCurrentProcessId() might change
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk