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?

 

[Ian Collins]

Just because you can't doesn't mean that anyone else can't.

Can't what?

Write obscure code? No problem I can manage that.

Not understand how C differs form C++? No, I find that hard.

Don't worry,
you can continue to program in C. No one is going to make you change your
religion.

I enjoy programming in several languages, so I consider myself to be
multi-denominational.

 

[Brian]

Can't what?

Fix C/C++ especially if having used it for years. That would not be a
good sign: a programmer without a highly evolved toolbox (not just source
code either) after a few years, say 5, but surely after 10, of
programming in a language. The only thing worse would be a programmer
that has no idea what is even wrong with the languages.

 

[Nick Keighley]

OK, I thought it was a C++ thing and that's where I got the idea. I just
extended it and use my own header as I try to avoid standard headers as
much as possible and stick with the language proper.- Hide quoted text -

you want to *avoid* standard headers?! Why for deity's sake?

 

[Ian Collins]

Fix C/C++ especially if having used it for years.

There no such thing as C/C++. The languages are distinct, each with its
own set of foibles.

That would not be a
good sign: a programmer without a highly evolved toolbox (not just source
code either) after a few years, say 5, but surely after 10, of
programming in a language.

What does that have to do with fixing a language? If you wish to fix a
language, get involved with the standardisation process.

The only thing worse would be a programmer
that has no idea what is even wrong with the languages.

One thing worse is a programmer who demonstrates that they don't
understand how to use the languages they want to fix.

 

[Ian Collins]

you want to *avoid* standard headers?! Why for deity's sake?

He appears to be labouring under the impression that they are not part
of the "language proper".

Or he could just be taking the piss.

 

[Brian]

you want to *avoid* standard headers?! Why for deity's sake?

Well that sounds like something for a separate thread on another day. I'm
sure some of you guys will like those thoughts as much as my macros. I
don't usually post code because it's all really "top secret" but this
stuff is not and I had a feeling some of you could do better with the
bit-level than me (the correctness, not the naming ) as I haven't
traditionally found the very low-level "design" to be interesting enough
but am getting more of an appreciation for it, but I think it should be
fixed once and then used "forever" rather than dealt with at every line
of code for that is a waste of human effort and money. A "great" way to
get a paycheck for some I guess without taxing the mind at all though.

 

[Brian]

There no such thing as C/C++. The languages are distinct, each with
its own set of foibles.

Why even say such trivia? Do you think sounding like a broken record is
flattering?

What does that have to do with fixing a language? If you wish to fix
a language, get involved with the standardisation process.


One thing worse is a programmer who demonstrates that they don't
understand how to use the languages they want to fix.

You may someday learn that there is very much more to it than just bits
and bytes and that knowing how to twiddle bits does not somehow give you
power or control over others. I don't even need one of those full time on
a software project and maybe not even at all. It certainly won't be one
who can't escape paradigmic thought and I won't be coming to this ng to
find one that's for sure (but maybe it's just you squeeky wheels that I
would reject and some lurkers out there may actually "get it").

 

[Nick Keighley]

On 16 Sep, 06:25, "Brian" <BWeird!@internet.> wrote:

[...] I
just extended it and use my own header as I try to avoid standard
headers as much as possible and stick with the language proper.

you want to *avoid* standard headers?! Why for deity's sake?

Well that sounds like something for a separate thread on another day. I'm
sure some of you guys will like those thoughts as much as my macros. I
don't usually post code because it's all really "top secret"

you program missiles?!

but this
stuff is not and I had a feeling some of you could do better with the
bit-level than me (the correctness, not the naming ) as I haven't
traditionally found the very low-level "design" to be interesting enough
but am getting more of an appreciation for it,

but I think it should be
fixed once and then used "forever" rather than dealt with at every line
of code for that is a waste of human effort and money.

yes, this is correct. A set of bit handling abstractions *is* a good
idea if your code is doing a lot of bit manipulation. Where did you
get the idea that anyone was disagreeing. Where we part company is if
your macros are powerful (they aren't, they are trivial), useful (not
very), correct (maybe not with the off-by-one errors) and standards
based (you seem to avoid standard headers and hide C behind obscure
macros). So are these the best set of bitset macros in world?

 

[Ian Collins]

I don't even need one of those full time on
a software project and maybe not even at all.

I thought you had demonstrated through your narcissistic approach and
disregard for standards that you weren't part of software team?

 

[Nick Keighley]

What's the benefit of these macros?  How is
        setbit(x, n)
easier to read or to write than
        x |= 1 << n;

a better abstraction

 

[luserXtrog]

Use if you wish. It's not like I invented anything other than short
names. Doing it once and wrappering it is loads better than being at the
lowest level all the time. That indeed is what programming is all about.
Just because standard C is fixed in stone doesn't mean anyone has to be
limited by that.

Yes, but there's a distinction between abstracting and obfuscating.
I'm all for idiosyncracy and even cleverness; but it's useless if
not tempered by pragmatism. Unless you're directly invoking
fundamental archetypes, the right brain needs lots and lots of
context to deliver informed intuitions. Uninformed intuitions
are worse that poor logic because the error is so much more difficult
to extract.

Besides 'and' is 3 characters while '&&' is only 2.
That's a 33.3% savings in both time and space.
And one fewer dimensional layer means an infinite
difference towards simplicity.

Once you analyse the intended purpose of the dogma,
it no longer rules you, you rule it. Then you may apply it or not
as the situation demands.

 

[Brian]

On 16 Sep, 06:25, "Brian" <BWeird!@internet.> wrote:

[...] I
just extended it and use my own header as I try to avoid standard
headers as much as possible and stick with the language proper.

you want to *avoid* standard headers?! Why for deity's sake?

Well that sounds like something for a separate thread on another
day. I'm sure some of you guys will like those thoughts as much as
my macros. I don't usually post code because it's all really "top
secret"

you program missiles?!

but this
stuff is not and I had a feeling some of you could do better with the
bit-level than me (the correctness, not the naming ) as I haven't
traditionally found the very low-level "design" to be interesting
enough but am getting more of an appreciation for it,

but I think it should be
fixed once and then used "forever" rather than dealt with at every
line of code for that is a waste of human effort and money.

yes, this is correct. A set of bit handling abstractions *is* a good
idea if your code is doing a lot of bit manipulation. Where did you
get the idea that anyone was disagreeing. Where we part company is if
your macros are powerful (they aren't, they are trivial),

It's just bit twiddling. How "powerful" can they be?!

useful (not
very),

I find them very useful. They make my GUI library a bit more elegant.

correct (maybe not with the off-by-one errors)

Well forget that part because it's part of the "top secret" stuff.

and standards
based

I have found both the C and C++ standards to be suboptimal (not very good
actually). I mean, if you're stuck in having to use it is one thing, but
it's really easy to do much better for almost any given project than the
standard stuff.

(you seem to avoid standard headers and hide C behind obscure
macros).

What you don't seem to want to recognize is that C is obscure and the
macros fix a teeny tiny bit of that obscurity, and I'm totally fine with
that as I am not trying to convince anyone to use my code, but why all of
you in 3 part harmony want to sell me on "the standard way of doing
things" when you don't have one ioda of an idea of what I am working on,
escapes me.

So are these the best set of bitset macros in world?

Fine. Point me to some better ones then. I will use them if I find them
better than the ones I have.

 

[Brian]

I thought you had demonstrated through your narcissistic approach and
disregard for standards that you weren't part of software team?

Well that you feel the need to resort to insult is too bad. Good luck
with that attitude.

 

[Ian Collins]

Well that you feel the need to resort to insult is too bad. Good luck
with that attitude.

No insults, just an honest appraisal.

On 09/16/10 09:09 PM, Brian wrote:

"I have found both the C and C++ standards to be suboptimal (not very
good actually). I mean, if you're stuck in having to use it is one
thing, but it's really easy to do much better for almost any given
project than the standard stuff."

You just proved me right.

 

[Brian]

Yes, but there's a distinction between abstracting and obfuscating.
I'm all for idiosyncracy and even cleverness; but it's useless if
not tempered by pragmatism. Unless you're directly invoking
fundamental archetypes, the right brain needs lots and lots of
context to deliver informed intuitions. Uninformed intuitions
are worse that poor logic because the error is so much more difficult
to extract.

Nice try but no cigar. C is overly clever and hence cryptic. It is not
pragmatic to use cryptic constructs if one doesn't have to. Do the test.
Teach a noob the standard raw syntax and the macro'd syntax. The flaw in
the language can be concealed and should be (for those who like clean
readable code). That the old timers have their brains wired to decidely
cryptic constructs is no reason to perpetuate the cryptics.

Besides 'and' is 3 characters while '&&' is only 2.
That's a 33.3% savings in both time and space.

Not very relevant except that it is much harder to type && than 'and'. It
is so minor compared to the comprehensibility of issue.

And one fewer dimensional layer means an infinite
difference towards simplicity.

Once you analyse the intended purpose of the dogma,
it no longer rules you, you rule it. Then you may apply it or not
as the situation demands.

No dogma for me please. I don't care what standard anyone else uses and
they shouldn't care what my standards are.

 

[Brian]

No insults, just an honest appraisal.

Well you know what they say about "appraisals" from 5 year olds.

On 09/16/10 09:09 PM, Brian wrote:

"I have found both the C and C++ standards to be suboptimal (not very
good actually). I mean, if you're stuck in having to use it is one
thing, but it's really easy to do much better for almost any given
project than the standard stuff."

You just proved me right.

You are really, really childish to not respect anyone else's opinion but
your own and to then "throw sticks and stones". Is that really working
for you somewhere?

 

[Ian Collins]

No insults, just an honest appraisal.

On 09/16/10 09:09 PM, Brian wrote:

"I have found both the C and C++ standards to be suboptimal (not very
good actually). I mean, if you're stuck in having to use it is one
thing, but it's really easy to do much better for almost any given
project than the standard stuff."

You just proved me right.

And again:

"No dogma for me please. I don't care what standard anyone else uses and
they shouldn't care what my standards are."

 

[Nick Keighley]

On 16 Sep, 09:16, "Brian" <BWeird!@internet.> wrote:

[...] I don't usually post code because it's all really "top
secret"

you program missiles?!

but I think it [bit manipulation] should be
fixed once and then used "forever" rather than dealt with at every
line of code for that is a waste of human effort and money.

yes, this is correct. A set of bit handling abstractions *is* a good
idea if your code is doing a lot of bit manipulation. Where did you
get the idea that anyone was disagreeing. Where we part company is if
your macros are powerful (they aren't, they are trivial),

It's just bit twiddling. How "powerful" can they be?!

well I guess you posted em for a reason. I assummed there was some
implied significance. I was thinking of "bit streams" where you can
write multiple bits.

I find them very useful. They make my GUI library a bit more elegant.

fair enough

Well forget that part because it's part of the "top secret" stuff.

ah, the missiles. These are not the missiles I am looking for...

I have found both the C and C++ standards to be suboptimal (not very good
actually). I mean, if you're stuck in having to use it is one thing, but
it's really easy to do much better for almost any given project than the
standard stuff.

you build on the standard stuff when you can. Then your extension/
abstraction is portable. In what sense is either standard "sub-
optimal"?

What you don't seem to want to recognize is that C is obscure and the
macros fix a teeny tiny bit of that obscurity,

I admit C looked pretty strange when I started to use it. You get used
to it. You'd be much better off persisting with the standard syntax
rather than hiding it. You'll be able to read other peoples' code and
they'll be able to read yours.

and I'm totally fine with
that as I am not trying to convince anyone to use my code,

so why post it? Were you expecting a gasp of universal astonishment at
your amazing code?

but why all of
you in 3 part harmony want to sell me on "the standard way of doing
things" when you don't have one ioda of an idea of what I am working on,
escapes me.

my rule is if there is a standard way of doing something and a non-
standard way of doing it then choose the standard way. Note this
doesn't exclude the use of libraries and other abstractions built on
top of the standard language and library.

Fine. Point me to some better ones then. I will use them if I find them
better than the ones I have.

google

 

[Uno]

Surely you are joking! Give each to a student in programming 101 without
any instruction and see the results. You don't need to have the car
engine exposed to drive the car. Low-level cryptics are not important,
productivity is. Abstraction rules (else use machine language directly).

Nobody's joking, and don't call me Shirley.

I find C's bitshifting austere for my needs.