mcostalba wrote:memcmp is a dirty trick to say at least, don't use it, is not portable, is compiler dependent, is endian dependent, is probably broken and most impostant is unnecessary for you.
rubbish
Of course memcmp() is a standard function. But just compares RAM. Is the use of memcmp to compare struct that has that long list of qualities.
I don't know if this was clear. Perhaps is still rubbish for you, hopeful less smelly
Hey, you guess what ? there is a lot of rubbish out there
The latter is a thread on a newsgroup called comp.lang.c where a bunch of fanatics that call themselfs c++ gurus enjoy with ludicrous arguments against memcmp used to implement operator==()...strange world....strange people!
mcostalba wrote:memcmp is a dirty trick to say at least, don't use it, is not portable, is compiler dependent, is endian dependent, is probably broken and most impostant is unnecessary for you.
rubbish
Of course memcmp() is a standard function. But just compares RAM. Is the use of memcmp to compare struct that has that long list of qualities.
I don't know if this was clear. Perhaps is still rubbish for you, hopeful less smelly
Hey, you guess what ? there is a lot of rubbish out there
The latter is a thread on a newsgroup called comp.lang.c where a bunch of fanatics that call themselfs c++ gurus enjoy with ludicrous arguments against memcmp used to implement operator==()...strange world....strange people!
Well I've already set-out the conditions under which I would use memcmp - if you don't want to use it then don't! Who cares. Can you point out to me where anyone else thinks memcmp is compiler dependant and endian dependant please?
mcostalba wrote:memcmp is a dirty trick to say at least, don't use it, is not portable, is compiler dependent, is endian dependent, is probably broken and most impostant is unnecessary for you.
Cardoso wrote:Thank you all for your answers.
Now please consider the special case of a struct with no pointers in it and the compiler switch to padding with 1 byte turned on.
BTW does padding with 1 byte mean no padding bytes at all? The sizeof(structname) would be what we see in the code with no hidden bytes?.
Now, would memcmp work with no problems at all?
If that is the case then I would have my opening book struct array problem solved.
Thanks,
Alvaro
Yes, that would probably work.
However, if the compiler would otherwise chose padding on 4 byte boundaries, it does that for a reason. Most often that reason is the performance of all other operations on the members, like assignment or increment.
mcostalba wrote:memcmp is a dirty trick to say at least, don't use it, is not portable, is compiler dependent, is endian dependent, is probably broken and most impostant is unnecessary for you.
Cardoso wrote:Thank you all for your answers.
Now please consider the special case of a struct with no pointers in it and the compiler switch to padding with 1 byte turned on.
BTW does padding with 1 byte mean no padding bytes at all? The sizeof(structname) would be what we see in the code with no hidden bytes?.
Now, would memcmp work with no problems at all?
If that is the case then I would have my opening book struct array problem solved.
Thanks,
Alvaro
Yes, that would probably work.
However, if the compiler would otherwise chose padding on 4 byte boundaries, it does that for a reason. Most often that reason is the performance of all other operations on the members, like assignment or increment.
Do you want memcmp to be fast, or everyting else?
It is possible to pack certain structures and leave everything else efficient. E.g. with MS VC++:
#pragma pack(1)
/*
packed struct definitions here...
*/
#pragma pack(8)
However, it is almost always better to make a sensible comparison method instead of using memcmp(). Using memcmp() is inherently non-portable, creates nonsensical orderings and probably will not create any real savings anyway.
But YMMV.
I suppose that there is a time for it, if desperate times call for desperate measures as revealed by a profile. I would definitely never do it that way myself for an opening book comparison method but that is neither here nor there. I would fail that practice on almost any code review we have here (but we code in C++ across multiple platforms so using memcmp() for ordering is simply broken beyond repair for our uses [*]).
[*] -- cough -- there is one place in our code where I use it for a server side equality compare under a specific operating system for specific data types. So, "Never say 'never'." Drats. I just said it.
Cardoso wrote:Thank you all for your answers.
Now please consider the special case of a struct with no pointers in it and the compiler switch to padding with 1 byte turned on.
BTW does padding with 1 byte mean no padding bytes at all? The sizeof(structname) would be what we see in the code with no hidden bytes?.
Now, would memcmp work with no problems at all?
If that is the case then I would have my opening book struct array problem solved.
Thanks,
Alvaro
Yes, that would probably work.
However, if the compiler would otherwise chose padding on 4 byte boundaries, it does that for a reason. Most often that reason is the performance of all other operations on the members, like assignment or increment.
Do you want memcmp to be fast, or everyting else?
Well, my obsession for memcmp is that it would allow me to sort an array of structs so that Î can do a binary search on that array looking for a board position.
Cardoso wrote:Thank you all for your answers.
Now please consider the special case of a struct with no pointers in it and the compiler switch to padding with 1 byte turned on.
BTW does padding with 1 byte mean no padding bytes at all? The sizeof(structname) would be what we see in the code with no hidden bytes?.
Now, would memcmp work with no problems at all?
If that is the case then I would have my opening book struct array problem solved.
Thanks,
Alvaro
Yes, that would probably work.
However, if the compiler would otherwise chose padding on 4 byte boundaries, it does that for a reason. Most often that reason is the performance of all other operations on the members, like assignment or increment.
Do you want memcmp to be fast, or everyting else?
Well, my obsession for memcmp is that it would allow me to sort an array of structs so that Î can do a binary search on that array looking for a board position.
Alvaro
Yes, I can see that.
The thing is that
1. If and when that is a good idea, the compiler might do that for you.
2. It is unlikely that your program spends any significant time in the opening book.
We have had numerous discussions here about bit twiddling techniques. Sometimes, the best alternative was to write the code as simply as possible, because then the compiler's optimizer actually understood the intention, and could generate minimal code. The trickiest code always runs the risk that the compiler doesn't understand it, and has to avoid some optimizations.
Save your low level tricks until you know that they are needed. Perhaps you can spend the time saved considering a hashed opening book, where you can avoid the binary search alltogther?
mcostalba wrote:memcmp is a dirty trick to say at least, don't use it, is not portable, is compiler dependent, is endian dependent, is probably broken and most impostant is unnecessary for you.
rubbish
True, it is not endian dependent.
No, it was none of things stated
I promise to myself not to answer...but I failed to keep that promise
As I have _already_ explained in a previous post, is not memcmp that is broken.
It is broken the USE OF memcmp to compare structs. This is becuase the same struct can be rapresented in RAM in differtent ways according to the compiler, the OS and, yes, also the endianess: a struct created on a MAC and saved on disk and then read back in a x86 will be stored differently in memory.
mcostalba wrote:memcmp is a dirty trick to say at least, don't use it, is not portable, is compiler dependent, is endian dependent, is probably broken and most impostant is unnecessary for you.
rubbish
True, it is not endian dependent.
No, it was none of things stated
I promise to myself not to answer...but I failed to keep that promise
As I have _already_ explained in a previous post, is not memcmp that is broken.
It is broken the USE OF memcmp to compare structs. This is becuase the same struct can be rapresented in RAM in differtent ways according to the compiler, the OS and, yes, also the endianess: a struct created on a MAC and saved on disk and then read back in a x86 will be stored differently in memory.
rubbish
