468,736 Members | 2,039 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,736 developers. It's quick & easy.

Stuff a pair of size_t into an uint32_t

Hi,

I apologise for starting a new thread on a partially answered question.
My previous problem has gotten more serious :)

So I have a function defined as follows:

bool observe(const WordID* dataword);

where WordID is

typedef uint32_t WordID;
My purpose is to use this function with some different data I already
have: the problem is, this data is NOT in the WordID format.

What I have is *pairs* of values, that I would like to input together
into observe(). In other words, I have pairs of numbers whose type is size_t

(size_t, size_t), (size_t, size_t), ... etc.

How can I input one of these pairs into observe()? I've heard that on
gcc size_t can be bigger than one uint32_t, so stuffing two into that
would definitely be a problem. What if I redefine the typedef such that
WordID is

typedef uint64_t WordID;

? And then maybe I could concatenate the two size_t and cast them into
that uint64_t? Would a uint64_t be enough? I was thinking about this:

observe(uint64_t* wordid);

and then

uint64_t chain(uint32_t one, uint32_t two) {
// get two 32bit rands and concatenate
uint64_t longrand = one;
longrand <<= 32;
longrand |= two;
return longrand;
}

The problem is this is a global typedef, used by many more function and
I'm not sure if this would harm something.

Any ideas would be greatly appreciated.

Cheers
Giuseppe
Jul 12 '08 #1
3 3949
Sam
Giuseppe: writes:
? And then maybe I could concatenate the two size_t and cast them into
that uint64_t? Would a uint64_t be enough? I was thinking about this:

observe(uint64_t* wordid);

and then

uint64_t chain(uint32_t one, uint32_t two) {
// get two 32bit rands and concatenate
uint64_t longrand = one;
longrand <<= 32;
longrand |= two;
return longrand;
}
Well, that might work, but what's going to happen is that a few years from
now your code will be the featured article on http://www.thedailywtf.com,
and everyone in the world will be laughing at it.

If you have a requirement that you must, somehow, process either a uint64_t
or a pair of size_t's, then you do exactly that, instead of trying to invent
some rogue mutation:

bool observe(uint64_t* wordid)
{
// …
}

bool observe(size_t word1, size_t word2)
{
// …
}

and factor out the common logic into a separate set of classes or functions,
that get invoked by the overloaded function code. Overloading, in C++, is
there precisely to address this situation.

There are many ways other to do this that are clean, and the resulting code
is readable and maintainable. Another way, that comes to mind, for example:

struct observe_params {
uint64_t *wordptr;
size_t word1;
size_t word2;
};

bool observe(uint64_t *wordptr)
{
struct observe_params parms;

parms.wordptr=wordptr;
parms.word1=0;
parms.word2=0;
return observe(parms);
}

bool observe(size_t word1, size_t word2)
{
struct observe_params parms;

parms.wordptr=NULL;
parms.word1=word1;
parms.word2=word2;
return observe(parms);
}

bool observe(struct observe_parms &parms)
{
// …
}

Then you supply the required logic here. If the wordptr class member is not
null (presuming that observe(int64_t *) never receives a null ptr), your
code knows that it received a uint64_t ptr. If the wordptr class member is
null, your code uses the two size_t parameters.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkh4vocACgkQx9p3GYHlUOJaDgCfSvtDUjJWCV nlQPKevp+F5vKv
l28Ani5mdNrO4SoZTtLACReeHG/Q4wA/
=digB
-----END PGP SIGNATURE-----

Jul 12 '08 #2
Sam wrote:
Then you supply the required logic here. If the wordptr class member is
not null (presuming that observe(int64_t *) never receives a null ptr),
your code knows that it received a uint64_t ptr. If the wordptr class
member is null, your code uses the two size_t parameters.
Thanks Sam, I guess I get the philosophy behind this now.

Only thing is, how would you go about creating a unique piece of data
from the two size_t?

In my program, while size_t word1 may appear several times, and size_t
word2 may appear several times, the combination of the two is unique.

Observe() is part of a Bloom filter, and what I'm trying to do is
storing (size_t 1, size_t 2) into the filter, and then later test the
filter for membership of the pair.

Could I, for instance, append one size_t to the other?

Regards
Giuseppe
Jul 12 '08 #3
Sam
Giuseppe: writes:
Sam wrote:
>Then you supply the required logic here. If the wordptr class member is
not null (presuming that observe(int64_t *) never receives a null ptr),
your code knows that it received a uint64_t ptr. If the wordptr class
member is null, your code uses the two size_t parameters.

Thanks Sam, I guess I get the philosophy behind this now.

Only thing is, how would you go about creating a unique piece of data
from the two size_t?
Define a class that contains these two objects, then proceed to overload all
the comparison operators for your class, as needed.

With most STL containers, you only need to overload operator<:

class twosizes {

public:
size_t a;
size_t b;

bool operator<(const twosizes &o) const
{
return a < o.a || (a == o.a && b < o.b);
}
};

This is good enough for all STL containers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkh4+I0ACgkQx9p3GYHlUOL+OQCcDJmz4bw52S P1EFoCewdc0Vx1
R4EAnApI3XpfSr4oCSaFLszTqs/WBe+3
=My5B
-----END PGP SIGNATURE-----

Jul 12 '08 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

14 posts views Thread by Neil Zanella | last post: by
5 posts views Thread by ma740988 | last post: by
4 posts views Thread by Florent Garcin | last post: by
12 posts views Thread by Alex Vinokur | last post: by
7 posts views Thread by meshko | last post: by
89 posts views Thread by Tubular Technician | last post: by
3 posts views Thread by n.torrey.pines | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.