I need a uuid class. After a bit of googling I see that at some point
there was some work in boost for this but it looks like it will be a
while before it is generally available. It is not in 1.41.1. Does
anyone know if there is one available elsewhere? It must be portable
of course. The project I am currently working on uses the UUID stuff
from Microsoft (for RPC). I want to avoid such lock-in.
uuids are quite tricky to implement from scratch. I tried to do it
myself several years ago, using ideas from the uids in DCE. One of the
problems is in efficiently generating random numbers with a large
period. Plus, they have to be unique across machines where several
processes on several machines may be generating them simulataneously.
This will definately be the case for my app. I reckon this is why such
uids often incorporate elements of the IP or MAC address. That's
tricky to do in a portable and efficient way. Last time I did it I
wound up having to interrogate the ethervard card using int86
(uurrgghh) on windows and using ioctl for solaris (eeuuggh).
Regards,
Andrew Marlow
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
>I need a uuid class. After a bit of googling I see that at some point
>there was some work in boost for this but it looks like it will be a
>while before it is generally available. It is not in 1.41.1. Does
>anyone know if there is one available elsewhere? It must be portable
>of course. The project I am currently working on uses the UUID stuff
>from Microsoft (for RPC). I want to avoid such lock-in.
I don't know offhand how portable it is, but the uuid implementation
that is in Linux's EXT2/EXT3 filesystem is used by a number of systems
that need global identifiers. See the e2fsprogs package.
George
Hello Andrew,
Andrew wrote:
> Hello,
> I need a uuid class. After a bit of googling I see that at some point
> there was some work in boost for this but it looks like it will be a
> while before it is generally available. It is not in 1.41.1. Does
> anyone know if there is one available elsewhere? It must be portable
> of course. The project I am currently working on uses the UUID stuff
> from Microsoft (for RPC). I want to avoid such lock-in.
You can have a look at Poco, which does have a portable UUID class. I
don't know if it suits you, but you can have a look:
Just look under Documentation in the Foundation classes.
lg,
Michael
On Dec 10, 3:03 pm, Andrew <marlow.and...@googlemail.com> wrote:
> Hello,
>
> I need a uuid class. After a bit of googling I see that at some point
> there was some work in boost for this but it looks like it will be a
> while before it is generally available. It is not in 1.41.1. Does
> anyone know if there is one available elsewhere? It must be portable
> of course. The project I am currently working on uses the UUID stuff
> from Microsoft (for RPC). I want to avoid such lock-in.
>
> uuids are quite tricky to implement from scratch. I tried to do it
> myself several years ago, using ideas from the uids in DCE. One of the
> problems is in efficiently generating random numbers with a large
> period. Plus, they have to be unique across machines where several
> processes on several machines may be generating them simulataneously.
> This will definately be the case for my app. I reckon this is why such
> uids often incorporate elements of the IP or MAC address. That's
> tricky to do in a portable and efficient way. Last time I did it I
> wound up having to interrogate the ethervard card using int86
> (uurrgghh) on windows and using ioctl for solaris (eeuuggh).
>
I wonder why do you need a class for that.
Also, I'd be amazed that you have a target system where you want an
UUID and that system doesn't already have function for that. It's
certainly one call away on a Unix clone (uuid_generate) and Windows
(CoCreateGUID).
Goran.
UUIDs have a very specific format to reduce the possibility of collision.
Thus you should not be implementing them if you think they ever contain an
IP address.
(Hint they never do, but type A does use a MAC address). The only way to
create valid UUIDs
is standard C++ is to use the types bashed on hashing the name of the
object. That in turn requires a universally unique name, such as a URN.
Somewhat portable (i.e. portable to Windows, OS X, Linux, and perhaps some
Unices) do exist, one that Wikipedia points out is the class in Qt.
Otherwise, most of the rest of the solutions seem to be either Windows
specific or POSIX-specific.
> I don't know offhand how portable it is, but the uuid implementation
> that is in Linux's EXT2/EXT3 filesystem is used by a number of systems
> that need global identifiers. See the e2fsprogs package.
Doesn't sound very portable to me. Sounds like its Linux-only. That's
not even portable among versions of UNIX. And I need something that
works on Microsoft Windows. I am using their GUID for RPC routines at
the moment.
Regards,
Andrew Marlow
>On 11 Dec, 20:16, George Neuner <gneun...@comcast.net> wrote:
>> On Thu, 10 Dec 2009 08:03:21 CST, Andrew
>>
>> <marlow.and...@googlemail.com> wrote:
>> >I need a uuid class. ... It must be portable of course.
>
>> I don't know offhand how portable it is, but the uuid implementation
>> that is in Linux's EXT2/EXT3 filesystem is used by a number of systems
>> that need global identifiers. See the e2fsprogs package.
>
>Doesn't sound very portable to me. Sounds like its Linux-only.
The generic generator claims to be portable to any POSIX platform and
it has fairly extensive #ifdefs for different environments (including
Windows). There is also a parallel Windows-only generator that is a
thin wrapper around the native GUID API.
I haven't tried it but I glanced at the code briefly ... the only
thing that isn't immediately clear to me is whether the generic
generator can create an id without having a NIC available - on desktop
OSes the loopback is always available, but I don't know what would
happen, for example, on an embedded platform without a network (of
course, in that case it would be unlikely that you'd need uuid in the
first place).
George
Hi,
I have implemented a class that generates random UUIDs using system
supplied (pseudo)random numbers, /dev/urandom in Unix and the
CryptoApi in Windows, which AFAIK should be at least cryptographically
strong. I tested it in Linux, Solaris and Windows.
As you noted, implementing a portable generator that uses MAC and time
is a very difficult, if not impossible, task. Besides, even if this is
available, things like virtualization can easily spoil a solution
otherwise considered secure.
http://sourceforge.net/projects/ooid/
HTH,
Kenneth
Well, let's assume each system has its own specific GUID call. To make
a portable one, couldn't you just write something like:
string makeNewGUID()
{
#ifdef WIN32
string const x = WindowsGUIDCall();
return "win32" + x;
#elif defined Linux
string const x = LinuxGUIDCall();
return "Linux" + x;
//etc.
#else
#error
#endif
}
Aka: Add a prefix for each particular implementation to avoid
collisions. Given that each platform implementation avoids collisions
with itself, then your new function will avoid collisions across all
platforms.
However, this assumes the existence of such a system function on each
platform, and it assumes that each implementation is correct.
It's pending review.
It's already available, it's just not into a boost release yet.
Well, that's slightly better than I thought, but still wonlt work for
MS-Windows. I downloaded it anyway and took and look. It really is
aimed at POSIX platforms due to its use of automake/autoconf. It works
with Cygwin but with Visual Studio.
> I haven't tried it but I glanced at the code briefly ... the only
> thing that isn't immediately clear to me is whether the generic
> generator can create an id without having a NIC available
That's not a worry for me. I tend to trust the implementation of these
things. The problems are well understood by now and include more than
just NIC worries (that's where my own version was using int32 to talk
to the NIC). The random number generator also needs a good source of
entropy. Some platforms provide one, others don't in which case there
are documented compromises.
-Andrew Marlow