I'm not worthy

[Steve Zimmerman]

I'm not even a billionth of the programmer that a
real expert is (Heathfield, Amdahl, Tisdale, et al),
and I couldn't code the following log function myself,
but I found it interesting, so I am sharing it with
the group. Here is a simple function to calculate
log base 2 of n:

int log2 (int n)
{
int log = 0;

while (n > 1) {
n /= 2;
log++;
}
return log;
}

Am I alone in experiencing this function as exceedingly
pleasant? That's not a rhetorical question; I'm really
wondering. Some of the so-called experts are so spiteful
and backbiting that I suspect their jobs are depriving them
of all the pleasure of the C programming language.

Their loss.

(The quoted function is from _C Programming: A Modern Approach_,
p. 185.)

 

[Nils Petter Vaskinn]

Here is a simple function to calculate
log base 2 of n:

int log2 (int n)

Yeah right. I stopped reading that function when I saw it returning an
int.


NPV

 

[Richard Bos]

int log2 (int n)
{
int log = 0;

while (n > 1) {
n /= 2;
log++;
}
return log;
}

Cute (although I'd write the loop as

for (; n>1; n/=2) log++;

myself.

However, for real code I wouldn't even use this function; I'd use log2()
from the library, on the justification that, though it isn't C89, it is
both in C99 and in my version of DJGPP.
And note that the C99 version clashes with yours, because it takes and
returns a double. Renaming yours log2i() would solve that and be
perfectly logical within the C99 math function naming system (cf.
log2f() and log2l()).

Richard

 

[/dev/null]

However, for real code I wouldn't even use this function; I'd use log2()

In other words, you couldn't care less about portability issues.

Why do you people resist the C99 standard so strongly?

If you keep bitching about the new features of C99, no one will ever use it.

Don't give me any backwards compatibility crap, C99 is just as much a
standard as C89.

I'm suprised you people don't have strokes when people use features that
aren't compatible with K&R C. Why is it OK to shun C99 in the name of
backwards compatibility, but not C89? After all, some machines don't even
support C89, only pure K&R.

 

[Dan Pop]

Why do you people resist the C99 standard so strongly?

If you keep bitching about the new features of C99, no one will ever use it.

That's the point: in the absence of the conforming C99 implementations,
the C99 features are useless. "It's portable because it's a C99 feature
and is also supported by *my* C89 implementation as an extension" is
pure bullshit.

Don't give me any backwards compatibility crap, C99 is just as much a
standard as C89.

There is a "small" difference between them, one is widely implemented and
used, the other isn't.

I'm suprised you people don't have strokes when people use features that
aren't compatible with K&R C. Why is it OK to shun C99 in the name of
backwards compatibility, but not C89?

Because C89 is the currently implemented and used standard and it's been
so for more than one decade (by 1992, practically any platform in current
use had a C89 implementation, most of them had at least two).

After all, some machines don't even support C89, only pure K&R.

How many people are actively developing software for them? The few such
machines that are still in *production* use are running legacy
applications, whose source code, more often than not, has been lost
long ago. Otherwise, the hardware would have been upgraded and the
applications ported to the new platform.

Dan

 

[Jirka Klaue]

Neil Cerutti wrote:
....

void log(void) [...]

If anybody can fix the typos, I'd be great ful.

void my_log(void) /* your_log, actually */

Jirka

 

[Chris Dollin]

Why do you people resist the C99 standard so strongly?

I don't think anyone is resisting the C99 *Standard*.

If you keep bitching about the new features of C99, no one will ever use
it.

Don't give me any backwards compatibility crap, C99 is just as much a
standard as C89.

Sure. But Standard's don't compile code. What we need to use C99 are
C99 compilers, sufficiently common that we can *expect* to port code to
a new platform and have it support C99.

I'm suprised you people don't have strokes when people use features that
aren't compatible with K&R C. Why is it OK to shun C99 in the name of
backwards compatibility, but not C89? After all, some machines don't even
support C89, only pure K&R.

They are no longer common enough to make a difference. (Are there
*any* platforms that only support pre-ANSI C? What are they?)

 

[Eric Sosman]

Why do you people resist the C99 standard so strongly?

Referential error: "people" is plural, but "Dan Pop"
is, er, singular.

 

[Dan Pop]

Show me a modern compiler that *doesn't* support at least some aspect of
C99.

I see: you're either a troll or a complete idiot.

If the C99 feature I use doesn't happen to be supported by modern
compiler X, my application cannot be compiled with that compiler,
even if it implements 99% of C99.

Dan

 

[Arthur J. O'Dwyer]

So what are they doing when they seem to say that we should not use the
C99 standard?

They're not saying that. Even Dan Pop quotes the Standard (or maybe
N869, like I do, 'cause I don't pay for stuff). However, some people
say not to use C99 *features* in actual *programs*, because if you try
to do that, you end up with a bunch of code that doesn't compile
anywhere yet.

Since when is compiled code relevant to this group or the C standard?

It's not really relevant to this group. But good coding practices
are relevant, IMHO, and restricting oneself to the C89/C99 intersection
is very good coding practice, at least until there's a C99 compiler
for all the major platforms. (If both MSVC and GCC supported C99, for
example, I'd feel comfortable using C99 for my code.)

Agreed.

Then we have a chicken and egg problem. People won't start writing C99 code
until there are C99 compilers, and people won't write C99 compilers until
people start using C99 code.

Just like the chicken-and-egg problem that everyone had with Java, and
Perl, and the HTML standards. Right. (Not to mention gas stations,
high-definition TV, and cigarettes.

The way it really tends to work is: People won't start writing C99 code
until there are C99 compilers, and people won't write C99 compilers until
people start wanting to use C99 code. At the moment, precious few
people really *want* to use C99, in my experience. It has a few very
good ideas, but doesn't provide enough of an advantage over C89 for
anyone to really *want* a compiler. And since it's too complicated for
the average weekend hacking session, nobody's going to bash out a compiler
just for the heck of it.

But if they still exist, then shouldn't you still support them irregardless
of the commonality of the platform?

"Irregardless" is not a word. And the person to which you are
responding just said he didn't think there *were* any. You
don't need to support non-existent platforms in production code.

Besides, please remember that K&R C is a *different* *language* from
C89, which is a *different* *language* from C99. C89 simply happens
to be the most popular of the three. You might as well claim that
since some platforms only support Fortran 77, all C programs should
be written in the F77-C89 intersection!

C89 was a necessity when it came out. Demand drove supply.
C99 is a luxury good. Until there is supply, there won't
be any demand.

(Pardon my bad econ.)
-Arthur

 

[Malcolm]

If your chosen platform doesn't fully support C99, then you should not
expect that platform to exist for much longer. As soon as people stop
supporting advancements in technology, everything will stagnate.

I think someone needs to bite the bullet on C99, since it is now four years
and hardly any conforming compilers have been built.

However it is extremely common for C programmers to have access to a C++
compilers, which allows some of the more useful features of C99 to be used,
like inline functions (at the cost of casting your return from malloc(), and
the more serious risk that someone will mess up your nice structured C with
lots of horrible C++ classes).

I'm not sure what is the best way to deal with this situation. Accepting
that C code may be run through a C++ compiler is facing reality, but risks
abolishing the C language as something which is desireably smaller, easier
to learn and implement and less easy to abuse than C++.

 

[Richard Bos]

Why do you people resist the C99 standard so strongly?

It's not "you people", it's "you person".

Richard

 

[/dev/null]

"Irregardless" is not a word.

One entry found for irregardless.


Main Entry: ir·re·gard·less
Pronunciation: "ir-i-'gärd-l&s
Function: adverb
Etymology: probably blend of irrespective and regardless
Date: circa 1912
nonstandard : REGARDLESS

usage Irregardless originated in dialectal American speech in the
early 20th century. Its fairly widespread use in speech called it
to the attention of usage commentators as early as 1927. The most
frequently repeated remark about it is that "there is no such word."
There is such a word, however. It is still used primarily in speech,
although it can be found from time to time in edited prose. Its
reputation has not risen over the years, and it is still a long way
from general acceptance. Use regardless instead.

 

[Dan Pop]

One entry found for irregardless.


Main Entry: ir·re·gard·less
Pronunciation: "ir-i-'gärd-l&s
Function: adverb
Etymology: probably blend of irrespective and regardless
Date: circa 1912
nonstandard : REGARDLESS

usage Irregardless originated in dialectal American speech in the
early 20th century. Its fairly widespread use in speech called it
to the attention of usage commentators as early as 1927. The most
frequently repeated remark about it is that "there is no such word."
There is such a word, however. It is still used primarily in speech,
although it can be found from time to time in edited prose. Its

^^^

reputation has not risen over the years, and it is still a long way

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

from general acceptance. Use regardless instead.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In other words, a word made up and used by the clueless.

Dan