Are these the best set of bitset macros in the world or what!?

[Brian]

Eric Sosman wrote:
[...]
- What is the type of `1'?
I would assume it would be "coerced" to the type of n, yes? [...]
The type of 1 is int.

No matter what the type of n is?

You might enjoy a draft with filename 'n1256.pdf'. Check out section
6.5.7. The '1' is promoted regardless of 'n'. Since plain '1' is an
'int', the result of the operator and its operands will be an 'int'.
Then 'n' is used to shift the promoted '1'. If 'n' is >= the width of
an 'int', the behaviour is undefined. The width of an integer type
includes the sign bit, whether or not there is one.

If we have 'int' (a signed integer type, per 6.2.5p4) with 15 value
bits and one sign bit, '1' might look like:

Pos: SEDCBA9876543210
Bit: 0000000000000001

Then '<<' is defined up to an 'n' (in your macro) of 15 (width - 1):

Pos: SEDCBA9876543210
Bit: 1000000000000000

This so happens to be the representation of a negative zero in a
sign-and-magnitude binary signed representation. It could actually
be a trap representation, causing trouble. So unless you can
guarantee that it's not a trap representation, you're only safe up to
an 'n' of 14 (under these circumstances).

Regardless of that, if you shift any further, the result does not get
any extra bits added to it. That means that if you use it in a
bitwise operation with some other operand larger than an 'int', you
mightn't get what you expect. The program might even crash. Assuming
it doesn't, you could still have something like:

Pos: SEDCBA9876543210FEDCBA9876543210
Bit: ???????????????????????????????? (1 << 16)[see note]
Bit: 00000000000000010000000000000000 & (65536)
Bit: 000000000000000?0000000000000000 (result)

Hope that helps. Perhaps I've gotten it wrong.

[note] Undefined, then usual arithmetic conversions[6.3.1.8] applied
for '&' operator evaluation.

Yeah, ok, thx. But really, this is hardly the time for me to analyze the
lowest levels of computer architecture or C. I was just cleaning up the
bitset stuff because I was working on the file API which led me there. I
AM trying to get my codebase to a place where I will be able to bring in
contractors to do the stuff I don't care to do (or that I won't live long
enough to figure out, it's all about time). Of course they will have to
be able to adapt to house standards and leave ISO at the door (along with
signing non-disclosure agreement and committing to "work done for hire").
Who knows, maybe even one of you guys (not likely, but weird things do
happen sometimes) will do the final testing (whitebox even, but not on
anything that reveals the product or constituents at a high level) of the
software. Right now, as long as my file and GUI libs work, all is good,
as there is a lot of important work still to be done

I'm glad I posted the macros. The dialog that ensued brought me out of
"code mode" and back into people-issue land. Finally, I will say that my
project is not yet funded, other than my own blood, sweat and tears. (One
of my products, but not the initital, may indeed be embedded if licensing
and similar issues can be resolved).

 

[Shao Miller]

(A bit late, sorry.)

I believe another way to do what ((u) * 0 + 1) is meant to do here would be

(0 ? (u) : 1)

except it doesn't evaluate "u" at all (6.5.15p4-5).

(The idea is not mine; I seem to remember somebody posting a link to
some C++ (specifically, boost) template magic here, and that string of
spells relied on both the non-evaluation and the type inference.)

Well maybe it's no co-incidence that after reading Mr. M. Grzegorczyk's
post ("...the macros do suffer from the usual problem...") but before
reaching yours, I was just thinking:

"Gee, it seems that the ternary conditional operator might come in
handy, here."

Perhaps you had read the "offsetof-style Fun with Ternary Conditional"
thread or perhaps the "Ternary Conditional Fun Macros for Any Type"
thread. Or maybe you read about this usefulness some time before that.

Fun possibly lurks in that operator.

 

[Brian]

Now who's resorting to insults?

You asked for it and I obliged. I know it's too early for me to post in
here again (?), but I anticipate that after everyone is thoroughly
pissed-off at me, then any real communication can happen. So, are you as
pissed-off as you can be? Not so much anymore huh. No need to apologize,
you're still almost OK with me. I've read your posts before and they seem
to be almost normal compared to the status quo for the ng. (Almost.
hehe!).

 

[Brian]

Still giving advice on activities you know nothing about, I see.
Be patient: As your body matures towards puberty (hormone injections
will help), eventually your testicle may descend and you may become
able to learn about something that is today just a remote rumor. When
and if the day arrives, though, you'll want to be more careful about
details and less indulgent of undefined behavior, lest you attempt the
wrong hole. If your partner is a patient sort he may forgive you, but
if you insist on trying to hump his navel he'll eventually give up on
you. And then you'll be left to twiddle your lonely little bit by
yourself, wondering why it always comes up zero.

See, my HS counselor was right: I should have gone into
student-counseling/teaching. As it stands, you grew up as you now are. I
fucked up. BTW, glad you posted because I lost sleep about that post.
What I meant was "bit twiddling maggot". So I apologize to other
bit-twiddlers, for twiddling bits is indeed a fine thing to do and even a
reasonable endeavor. What is bad though is being or becoming a bittwit.
The concepts are orthogonal. Bit-twiddling: good. Being a bit-twit: bad.

("thx" for the rebuttal platform Eric).

 

[Brian]

I looked up BNITU on the web and came up with nothing. What does that
stand for?

 

[Keith Thompson]

pete wrote:
Brian wrote:

Keith Thompson wrote:
Eric Sosman wrote:
[...]
- What is the type of `1'?

I would assume it would be "coerced" to the type of n, yes? [...]

The type of 1 is int.

No matter what the type of n is?

Correct.

In ((a) << (n)),
the types of (a) and (n) are unrelated.

I find that non-regular and surprising and a good reason for hiding
it behind some macros.

Only because you fail to understand the underlying principles.

No, because it is. And there are many faults in C. My macros correct some
of them. Next person who starts with the pedantic shit gets a size 12
boot up their ass. Just curb it bitheads, ok? ok, good.

It never occurs to you that anyone could disagree with you for some
reason other than being an idiot, does it?

*plonk*

 

[Brian]

Haven't time to wade through forty-odd posts to find the piece
of code you refer to, so I'll offer my own example instead:

#define bitn(n) (1<< n) /* your macro, verbatim */
#include <stdint.h>
typedef uint64_t bitset64;
...
uint64_t bit0 = bitn(0); /* works */
uint64_t bit14 = bitn(14); /* works */
uint64_t bit15 = bitn(15); /* works only probably */
uint64_t bit31 = bitn(31); /* works only probably */
uint64_t bit32 = bitn(32); /* almost certainly fails */
uint64_t bit33 = bitn(33); /* almost certainly fails */
...
uint64_t bit63 = bitn(33); /* almost certainly fails */

Yeah, yeah. I'm sure this is "important" (it isn't in the grand
"scheme"). While I DO know this stuff (maybe before more than now), it's
just not important to me: my goal is to deploy real product. It is
important for me to know the low level (important to me). Think of me as
your worst nightmare project manager that you cannot fool with any line
of code you write. That would hint at me. Oh, you don't do that (try to
"run the project" from bit-n-bytes-level knowledge)? C'mon, fess up. I
may have been married to your PM at one time!

That said, I gave you a platform to "show your stuff" a little (?).
Bits-n-bytes are fine to know. Somebody has to pick up the garbage,
right? Just kidding. I don't think in bits-n-bytes. I see bits-n-bytes
and then say, "how can and should this be abstracted", then I put the
ideal melam over the existing and move on with the ideal layer. If you
understand what I just said, than you know one of my thinking patterns.

THAT said, maybe my bitset macros are not the best in the world, but
until I see better, I'll keep using them. (Note too that I wouldn't have
been able to say a word beyond 'macro' had I posted in a C++ group, and
obviously I DO use C++ and know EVERYthing about it).

 

[Brian]

C has eleven funny-looking operators. Spend eleven hours,
or whatever it takes, to learn those eleven operators.
Once you've done that, you'll find C to be a remarkably
simple language.

I learned C, and used it to solve a number of real world problems, in the
late eighties. It has changed since then? What is your point? (I'm going
to start categorizing people in here if this continues, be warned).

 

[Brian]

I don't think that's clear-cut. Either way, I think it's a small
difference if there is any.

Agreed, but I err toward showing the non-programmer rather than
discussing with the computer scientist. (Aside, academia (wow, a big can
of worms in the internet age, for wikipedia replaces most of it) and
science (and industry), where is that at now?).

But pete is selling his version short. More important than the speed
is the fact that his version works no matter how wide the type of x.
It means you can change from, say, unsigned char to uint64_t without
having to remember to change the '1' in bitn.

Can I have the final release copy on Monday?

 

[Shao Miller]

... ... ... (I'm going
to start categorizing people in here if this continues, be warned).

Mr. K. McCormack offered a link once which I found entertaining:

http://redwing.hutman.net/~mreed/index.htm

Perhaps you would find it entertaining, too.

 

[Seebs]

It never occurs to you that anyone could disagree with you for some
reason other than being an idiot, does it?

It never ceases to amaze me. I sorta dread to some day go back and see
whether I was as insufferable when I was just starting out. Hmm.

Apparently not. I was annoying and didn't read FAQs until I'd been told
to a few times, but I was apparently at least basically capable of courtesy
to people who knew things I didn't. Neat!

-s

 

[Brian]

I also have a collection of bit manipulation macros, and I think
macros do have advantages over straight up code.

Don't patronize me! (Just kidding, I know you weren't, but I like to
kid-around).

1. Readability - This one is somewhat contentious for some of the
simpler methods, but when you start creating more sophisticated bit
manipulation methods, one can get lost in the mechanics.

OK? (I think I know what you mean? Tom (or Nick) Keithly suggested that
my macros did "nothing <significant>" (the word he used is not relevant),
but of course my macros were at "square one" of the C language: cleaning
up the cryptic (some would say "ugly") syntax.

<snip your code, I will save the post and promise never ever to see it
again!> (JK, ya know?).

In my opinion, this is much more readable and requires less effort to
understand what's going on than trying to do it raw (and I have worse
macros than this).

Nuff said. Me and you don't understand the "purist attitude". A show of
hands: how many expert programmers here are trained IT guys and how many
are from other areas?

Macros ARE bad, but if C (sorry C++ guys) or C++ is all you have, that is
how it has to be.

It does require some trust that the macro
implementation does what it's supposed to do correctly,

What I said above.

but if that
can be verified, the net gain is higher than having complicated bit
manipulation spread throughout the code.

Yes (!). I didn't test my "new" macros before I posted them. They were my
"best" effort before I engaged the debugger or unit tests. I don't think
they failed miserably, but again, I may have even learned about
bitshifting and stuff from those where I "stole" them. I think I made
them better (there were no toggle macros). Someone said iso646? Was a
"boon' to me when I found it. Is 'eq' better than '=='? Of course. Is it
'C'? Do you think I care if it is?

2. Encapsulating the operation in one central location, the macro
definition, makes maintenance easier.

Not only that. It is "progressive", in that new programmers don't have to
be limited by the past or feel imposed upon by a legacy programming
language (it's history, learn from the mistakes). It is the internet age"
and it is time to move forward at more than the previous snail pace, IMO.

The biggest gain from using a macro to encapsulate the bit
manipulation is that mistakes are localized to a single definition.

I'm not sure that is true, but ... let me digress (really, sowwy):

I remember my parents' friends teaching me slide rule. (I think I still
have it? Damn, if I lost it.. damn!). Everything he said made sense to me
and I "sponged it up" (hardly). He was an engineer and I "knew" what he
did for a living. I remember every detail and could write a book about
it, but I will spare you all from that and "get to the bottom line". At
the end of his lesson, he asked me to show him some (maybe more than just
simple) thing, and I got how to multiply or something. He saw I was into
it but not really listening. I was being tested on what I had (was
supposed to have) learned, and some dialog ... and then... while I
understood everything he was saying, I said something like, "that's what
my calculator does".

I still have the compasses he gave me. Damnit I miss that slide rule.

 

[Ian Collins]

No, because it is. And there are many faults in C. My macros correct some
of them. Next person who starts with the pedantic shit gets a size 12
boot up their ass.

Assaulting people's donkeys now are we? Tut tut.

 

[Brian]

pete wrote:
Brian wrote:

Keith Thompson wrote:
Eric Sosman wrote:
[...]
- What is the type of `1'?

I would assume it would be "coerced" to the type of n, yes?
[...]

The type of 1 is int.

No matter what the type of n is?

Correct.

In ((a) << (n)),
the types of (a) and (n) are unrelated.

I find that non-regular and surprising and a good reason for hiding
it behind some macros.

Only because you fail to understand the underlying principles.

No, because it is. And there are many faults in C. My macros correct
some of them. Next person who starts with the pedantic shit gets a
size 12 boot up their ass. Just curb it bitheads, ok? ok, good.

It never occurs to you that anyone could disagree with you for some
reason other than being an idiot, does it?

*plonk*

Has it ever occurred to you that I like playing with the minds of fools?

 

[Brian]

It never ceases to amaze me. I sorta dread to some day go back and
see whether I was as insufferable when I was just starting out. Hmm.

Apparently not. I was annoying and didn't read FAQs until I'd been
told to a few times, but I was apparently at least basically capable
of courtesy to people who knew things I didn't. Neat!

Yes, let's land on the beach of Normandy! Go **** yourself.

 

[Brian]

Assaulting people's donkeys now are we? Tut tut.

Noted: you are still not done. Someone get me a clue why these greenbeans
don't know how to put their shoes on! Mrs. Collins, did you come all the
way from where you came from just to piss me off?

 

[Brian]

Mr. K. McCormack offered a link once which I found entertaining:

http://redwing.hutman.net/~mreed/index.htm

Perhaps you would find it entertaining, too.

I do not understand those hieroglyphics. Read: I ain't your father.

 

[Shao Miller]

I do not understand those hieroglyphics. Read: I ain't your father.

Sorry, it's a link with various and entertaining categories for people.
You said you were going to start categorizing people, so I thought you
might be entertained.

 

[luserXtrog]

Oh, so you are in general a defamer and above the law? Look into it,
bitch. Shut up. Or say what you want to say. I'm not going to "sue" you.
Stop getting away with it. Get it off your mind (what you wanted to say
and not in a place with the threat of "law").

I don't know which is funnier! Stadtler/Waldorf or Fozzie Bear?
FYI, ICYC, here is the entire message [Message-ID: <i6t0kv$gdr
[email protected]>] in which the
abbreviation occured. If you read all the words, you may find,
between two double-quote characters ('\"'), a phrase, the initials
of which match the abbreviation in question.

This rather drives home the point of avoiding unncessary layers
of abstraction.

Barry Schwarz wrote:
[...]
And what happens if you want to test the sign bit? You might avoid
syntax errors and undefined behavior with
#define bit(n) (1u<< (n))

While I don't see the need, some might even want 1lu or 1llu.

OK on 1u. But the compiler wouldn't really change to signed if an
unsigned was passed (guaranteed with use of the bitsetX defines
below), would it?

You're *still* not seeing the problem, are you? All, right,
let's go through it step by step:

- What is the type of `1'?

I would assume it would be "coerced" to the type of n, yes?

No.

I would assume it would be "coerced" to the type of n, yes? OK, not for
the uint8 and uint16: C's conversion/promotion rules suck rocks.

Since you don't know those rules, your opinion of them is
worthless.

Good
thing I have these macros to make things less error-prone than the raw
syntax. A hundred more of them and C may even be turned into something
good.

You've demonstrated that you don't know C, that you're a novice
who makes novice errors -- and renders uninformed novice opinions.

No answer?

No answer?

No answer? All these questions are too hard for you?

(Side note: I was wrong here. It's not the annotations' phrase,
but the holy text of the Eighth Commandment itself.)

Try something new. You'll like it (unless you like vi!). C is an
impediment to understanding that's why a programmer needs macros to make
it understandable.

Years ago when I was young and stupid, my own BNITU was

#define until(x) while(!(x))

.... but I soon outgrew that puerile stage.

 

[Nick Keighley]

Nick Keighley wrote:

That is "emphasized" way too much and it wastes a lot of time and makes
code unmaintainable. First assess the real needs, not some
way-out-there-chance, and build what is appropriate. The "portability"
rant is pure dogma or the like.

We aren't going to agree here but I have seen cases where it really
mattered. With embedded systems the system used for initial test is
often different from the final target system. Sometimes the target
just doesn't exist when software development starts. Sometimes you
don't want to do do your first test run on real hardware (Anti-lock
brakes, fly by wire). Sometimes it's just plain easier to debug a
version that actually has a screen, a keyboard and a hard disk.

I've seen non-portable code fail when the compiler was upgraded. In
theory a change in optimisation could trigger a changs in behaviour.

I've seen large applications ported between quite incompatible
platforms. This was mostly done by good encapsulation and required
some code changes. 90% + of the code didn't notice a thing.

A comms application ran on both a large unix box and a Z80 based bit
of embedded hardware. The embedded version was far less capable but
they shred a lot of code. Most of the debugging and testing could be
done on the unix box.