Comparision of C Sharp and C performance

[Seebs]

Nilges bilge doesn't count as 'error', it counts as 'noise'.

The recent one about Haiti is a particularly brilliant example. That's
actual madness, of the sort you see professionals to get treatment for,
not something that people on Usenet can cure for you. Killfile, and trust
that anyone who can't figure out that he's a kook is too far gone to worry
about anyway.

-s

 

[Richard Bos]

Would a rand() implementation that does a decent job of generating
numbers from 1 to RAND_MAX, but that never produces 0, be conforming?

As I read the Standard, marginally not.

(Assume that this can be proven by examining the source code.)
Note that for a large RAND_MAX, this might be good enough for
most purposes.

Of course. Even for a minimal RAND_MAX, it is easily good enough for the
purpose for which I mainly use rand() itself, which is the creation of
random disambiguation markers, randomised file names, and suchlike.

Must rand() be able to return *all* numbers from 0 to RAND_MAX?

As I read the Standard, no, but it must be able to return both extremes.

These are mostly rhetorical questions; I don't think they can be
definitively answered given the wording of the standard.

I agree, and mine are mostly rhetorical answers. But the Standard says
that rand() must return PRNs in the range 0 to RAND_MAX; if it actually
returns PRNs in the range 1 to RAND_MAX-1, I don't think that that is
strictly conforming to that demand, but I agree that this is quibbling.
OTOH, it does not say that it must return _all_ PRNs in that range, so
if it misses a set out, that's conforming. Low quality, but conforming.

Note that the sample implementation in the Standard does return all
numbers between 0 and RAND_MAX, so there is no real excuse for any
implementation not to do the same.

But I think the difference between a rand() that generates numbers
from 1 to RAND MAX and one that just generates 3490 is more
qualitative than quantitative.

Intuitively, a rand() that always returns 3490 is Just Wrong, but
there's no clear dividing line between correct and incorrect
implementations.

Oh, certainly.

Richard

 

[Keith Thompson]

I agree, and mine are mostly rhetorical answers. But the Standard says
that rand() must return PRNs in the range 0 to RAND_MAX; if it actually
returns PRNs in the range 1 to RAND_MAX-1, I don't think that that is
strictly conforming to that demand, but I agree that this is quibbling.
OTOH, it does not say that it must return _all_ PRNs in that range, so
if it misses a set out, that's conforming. Low quality, but conforming.

Ah, but PRNs in the range 1 to RAND_MAX-1 *are* PRNs in the
range 0 to RAND_MAX-1. And if not every number in the range must
(eventually) be returned, then I'm not convinced that the endpoints
are special.

But more than making a specific argument one way or the other,
my point is to demonstrate that the description in the standard
is vague.

If you have specific requirements for pseudo-random numbers,
use something other than rand(). In practice, this is what
programmers do.

 

[spinoza1111]

Ah, but PRNs in the range 1 to RAND_MAX-1 *are* PRNs in the
range 0 to RAND_MAX-1.  And if not every number in the range must
(eventually) be returned, then I'm not convinced that the endpoints
are special.

But more than making a specific argument one way or the other,
my point is to demonstrate that the description in the standard
is vague.

If you have specific requirements for pseudo-random numbers,
use something other than rand().  In practice, this is what
programmers do.

C is the greatest language in the world!

Don't use its basic features!

Use something else!

What the hell is this, Kiki? Zen?

 

[spinoza1111]

I am a relative newcomer to comp.lang.c.  I haven't used C for years,
and I needed a bit of a refresher.  Subscribing to clc seemed like a
useful exercise.  You probably would disagree with my decision to brush
up on C (and that subscribing to clc is a useful exercise), but lets
imagine, for a moment that I am doing so out of a desire to study the
history of computer programming.

From your anecdotes it is quite clear that you value the importance of
such history.

In the few weeks that I have been reading clc I have noticed that you
have, on any number of occasions, brought up these "mistakes" by Seebach
and Richard.  I am sure that these errors were truly egregious, and that
these two characters are the worst sort of people.  However, as far as I
can tell these two errors happened quite some time ago.

Well, Richard "searched" for my postings on the group "Risks to the
public in computer systems" just last month, searching the titles of
posts (each of which digests about ten contributions) for spinoza1111,
found nothing, and on the basis of this claimed that I'd never been
accepted for publication. Of course, if he has the skill set he
claims, he would have searched inside the digests, so he either lied
or doesn't have the basic skill set he claims.

Peter stated that "the 'heap' is a DOS term" several years ago but has
defended this and other false claims, such as the claim that a
statement can be clear and erroneous outside of a formal system.

Peter also revealed that he's without academic qualifications in
computer science which explains his view that teachers of programming
may not refer to "stacks" when illustrating semantics when this is
done harmlessly and in an illuminating way all the time.

However, I refuse to use the "echo chamber". This is constant
repetition that Peter and Richard make errors. You'll notice that I
tend to enumerate the errors themselves.

Whereas in Peter's campaign against Schildt he repeats the (false)
proposition that "Schlidt makes errors", a conclusion that "C: The
Complete Nonsense", Seebach's online document, fails to prove.

Heathfield's dishonesty and Seebach's lack of qualifications are
issues that are not going away.

I believe that it is important to stand up against error, but at some
point harping on the same errors starts to seem quite petty.  This is
not a criticism.  It is merely an observation.

Sure, in the corporation, low-level employees are encouraged to be all
noble and shit, and not "petty", only to find themselves stabbed in
the back by the petty and ignoble.

I would certainly agree that you are quite literate.  In fact, I think
that you missed your calling in life.  Not only are you highly literate,
but you have an absolute flair for arguing your case, even when your
case is clearly wrong.  I was particularly impressed with your arguments
for #DEFINE over #define.  You really should have been a lawyer.

I'm "clear and wrong", which is programmerese for "slick" or just
right. The fact is that Bacarisse, who's a smart guy, looked stupid
when he called me on using upper case in what is as always a rough
draft for the same reason Heathfield looked stupid when he called me
for using an invariant in a for loop. They looked stupid because they
know in their hearts that I am more qualified in C than they, who work
24/7 at their trade to learn, but somehow have a surplus of knowledge
beyond C and can write clearly: this bugs the shit out of them, and
they've been throwing tantrums over this ever since I started posting.

From some people this might seem like denigration, but unlike many
people, I actually like lawyers.  My father and three of my uncles are
an attorneys as was my grandfather before them.

I am not a lawyer, but a law tutor.

I will say that it is a bit of a stretch to compare the people who
disagree with you to the people that supported Hitler.  Clearly that is
a stretch.  Perhaps you could, in the future, compare them to Tammany
Hall, or too some other historical group closely linked with corruption.

The stakes are too high. We don't need another Hitler, and he was
brought to power by the white collar lower middle class using the same
sort of rhetorical strategies used here by Heathfield and Seebach:
constant repetition of the same lies.

I imagine that for some of the people on this list C is the means by
which they make the money that they could then send to Haiti.  I
personally am not in that group, but I imagine that it happens.

Thanks for a thought-provoking contribution.

 

[spinoza1111]

The recent one about Haiti is a particularly brilliant example.  That's

Can't remember what I said about Haiti except I said "send money".
Perhaps I did say somewhere that white people are the cancer of the
human race, and behave in ways we see here because they're pigs? I
don't remember saying that (Susan Sontag said the first part of that),
but I wouldn't put it past me.

We do know how you shitheads treat foreigners. Twice, a Chinese poster
has contributed and twice you mocked his English. So it's dollars to
donuts that you're sitting around the break room at Wind River Systems
blaming the Haitiennes for their troubles and airing your ignorance.
In my experience, playground bullies of the 1950s became neo-Nazis in
the 1970s.

I really need to get a round "tuit" and write a letter to Apress about
your conduct.

 

[spinoza1111]

As I read the Standard, marginally not.


Of course. Even for a minimal RAND_MAX, it is easily good enough for the
purpose for which I mainly use rand() itself, which is the creation of
random disambiguation markers, randomised file names, and suchlike.


As I read the Standard, no, but it must be able to return both extremes.


I agree, and mine are mostly rhetorical answers. But the Standard says
that rand() must return PRNs in the range 0 to RAND_MAX; if it actually
returns PRNs in the range 1 to RAND_MAX-1, I don't think that that is
strictly conforming to that demand, but I agree that this is quibbling.
OTOH, it does not say that it must return _all_ PRNs in that range, so
if it misses a set out, that's conforming. Low quality, but conforming.

Note that the sample implementation in the Standard does return all
numbers between 0 and RAND_MAX, so there is no real excuse for any
implementation not to do the same.



Oh, certainly.

Richard

Oh goody. We can be low quality yet Saved, yea washed in the blood of
the Lamb, as long as we conform to the Standard.

This newsgroup resembles Calvin's Geneva, where people were killed for
saying the wrong thing because men driven mad by the possibility of
eternal damnation.

It's not in the remit of a programming language to provide random
numbers. If you need random numbers you get a quality generator,
preferably one from a site suffixed .edu or .gov. If your random
number generator loses me money, and I'm a Yuppie swine, you don't
think I won't have your ass just because you're Standard?

Besides, an informal test is easy. Just call the candidate rand() from
C Sharp or Visual Basic, and use its numbers to draw a sufficiently
fine matrix of black and white dots. If it looks like "snow" on an old
analog TV, you MIGHT have a decent random number generator. If you see
black lines or ghostly shapes, it's garbage.

 

[Andrew Poelstra]

For the record, if a resume crosses my desk that has "C/C++" printed on it,
it has a significantly greater tendency to summarily land in the trash bin.

And if an employer were to complain about the comma between
C and C++ on my resume, I'd walk out of the interview. FWIW
this has never happened, but perhaps the confusion works as
an idiot filter, and therefore isn't all bad.

 

[Ersek, Laszlo]

What's "C/C++"?

I ask because recently this conflation particularly has been annoying me.
Several times of late I've been pointed to some library--implicitly or even
explicitly held out to be C--only to discover it's in C++.

Google also seems to be transitioning to a predominately C++ shop (where C
may have earlier been used), and they advertise some of their open source
projects as "C/C++" when it's all, plain C++.

I guess this conflation is committed with increasing frequency as one
tends towards programmers who program mainly in more managed
environments. A nice flamewar is always in order, so I'll just say:

- Java guy: what? malloc()? That's C/C++!
- Perl/Python/Ruby/PHP guy: what? SIGSEGV? That's C/C++!
- Haskell/OCaml/Erlang/Lisp guy: what? assignment? That's C/C++!

(Of course I'm mixing up all kinds of stuff. I think I'm being
especially unfair with the FP languages supporting assignment.)

The syntax "C/C++" simply drives me mad. I mostly care about the SUS. I
just grepped the SUSv4 for "C++":

- <tgmath.h>: two mentions in the Rationale.
- pthread_cond_timedwait(): one mention in the Rationale.
- "Thread Cancellation Overview" Rationale: one mention.

That's it, nothing normative. So whenever I face the oft quoted
statement,

"I never saw a project for which C was better than C++ for any reason
but the lack of a good C++ compiler"

(http://www2.research.att.com/~bs/bs_faq.html#C-is-better), then I
always feel tempted to reply with "I know of no standard covering C++
that is feature-rich enough, in itself, to do something useful".

Calling socket() in a C++ language program is a hack that happens to
work on "common implementations". More precisely, it is a non-standard
foreign function interface so thin that people take it for granted, and
then they're in for the big-eyed surprise when the ABI breaks or headers
clash or whatever.

(I sort of "port" and "re-port" a C++ language program from GNU/Linux to
Solaris 9. The latter is SUSv2 certified. I'm having all kinds of fun
with <stdint.h> and <inttypes.h>, and <csignal>, <signal.h>, kill(), and
std::kill(). It is absolutely not the fault of the program I'm working
with. The effective C++ standards simply don't specify 64 bit integer
types AFAICT, so the program can either give up on those types or it can
risk non-portability. From the portability POV, the "C/C++" syntax is
the polite formulation of "**** me with a piledriver". (Pardon my
French.))

lacos

 

[Keith Thompson]

And if an employer were to complain about the comma between
C and C++ on my resume, I'd walk out of the interview. FWIW
this has never happened, but perhaps the confusion works as
an idiot filter, and therefore isn't all bad.

Ok, here's a question: *why* do you have "C/C++" on your resume?

Many people who use that term are exhibiting confusion about the
fact that C and C++ and two different languages. (Yes, they're
closely related, in that one is nearly a subset of the other,
but that relationship is seldom relevant for well-writtenc code in
either language.)

If I saw "C/C++" on your resume, I wouldn't automatically throw it
away, but I'd probably ask you just what you mean by it, and why
you didn't just list "C" and "C++" separately.

 

[Andrew Poelstra]

Ok, here's a question: *why* do you have "C/C++" on your resume?

Check again - I said there was a comma between the two words.

 

[Kenny McCormack]

Ok, here's a question: *why* do you have "C/C++" on your resume?

What part of "comma" don't you understand?

--
(This discussion group is about C, ...)

Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch revelations of the childhood
traumas of the participants...

 

[Andrew Poelstra]

C/C++ means heavy usage of C arrays, malloc/free, cstdlib and less of
stdlibc++ and new/delete and programming style considered
as "proper C++"

I suppose if you read it musically that would make sense:
"I use C with C++ in the base."

But most languages cannot be expressed as chords, so this
seems to be an awfully non-portable notation.

 

[Keith Thompson]

Check again - I said there was a comma between the two words.

[...]

Whoops, my mistake; I should have read more carefully. Please
disregard.

(But I'm not sure why you mentioned it; I can't think of any reason
why anyone would object to a comma between "C" and "C++".)

 

[Kenny McCormack]

Whoops, my mistake; I should have read more carefully. Please
disregard.

(But I'm not sure why you mentioned it; I can't think of any reason
why anyone would object to a comma between "C" and "C++".)

The point being made is that if employers get in the habit of discarding
resumes that say "C?C++", where the ? is some punctuation mark, then some
people who got it right (like Andrew) will suffer.

And since we know that people's reading skills these days are in the
toilet, it would be a bad precedent to let get set.

--
(This discussion group is about C, ...)

Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch revelations of the childhood
traumas of the participants...

 

[Seebs]

Ok, here's a question: *why* do you have "C/C++" on your resume?

I don't think he does. I suspect he has "C, C++" on his resume.
Thus the word "comma".

-s

 

[Andrew Poelstra]

Whoops, my mistake; I should have read more carefully. Please
disregard.

(But I'm not sure why you mentioned it; I can't think of any reason
why anyone would object to a comma between "C" and "C++".)

There's more speculation on this than I expected. So here
was my thinking:
1. The employer would believe the correct term was "C/C++" and
/I/ was the idiot who didn't know the languages well enough
to realize they were the same.

or
2. The employer thought I was trying to look smart by listing
a greater number of languages, when any idiot can clearly
see that code in either looks sorta the same.

or maybe even
3. The employer was a true PHB who had no clue that C or C++ was
related to the buzzword "C/C++", which is what he was looking
for.

As I said, I've never met such a person who was allowed to
hire people. But nonetheless I can imagine one existing.

 

[jamm]

Sorry for arriving to this party a bit late, but here's a white paper
that compared the performcne of C/C++ vs Java vs C#.

http://www.cherrystonesoftware.com/doc/AlgorithmicPerformance.pdf

What I did was take 5 algorithms and write them in C/C++, Java andC3 and
benchmarked them against each other. C/C++ wins hands down.

Hope you find this document useful.

Well I found it interesting, thanks. Of course with benchmarks 'it depends'
applies alot and people will grumble. But it gives an idea. Java performed
better then I thought on a few tests.

Now I see some grumbling about the skill abbreviation "C/C++".. simply means
the person thinks that they can program in both styles using the common C
based syntax. We may call C and C++ different languages, but they are the
closest of any two 'different' languages in existence.

 

[Ben Bacarisse]

Now I see some grumbling about the skill abbreviation "C/C++".. simply means
the person thinks that they can program in both styles using the common C
based syntax. We may call C and C++ different languages, but they are the
closest of any two 'different' languages in existence.

The distance measure is complex. C and C++ share a lot of syntax but
the programming style is very different. The two languages Scheme and
ML could not look more different, but one can usually translate a
program in one into the other with very little "forcing".

You note the different styles involved, so presumably your measure of
closeness is weighted towards syntax. I tend to weight it the other
way so I'd smile more at a resume that had "C, C++, Scheme/ML" than
one that had "C/C++, Scheme, ML" though, in fairness, the smile would
be mostly about the in joke.

 

[jandrm]

The distance measure is complex. C and C++ share a lot of syntax but
the programming style is very different. The two languages Scheme and
ML could not look more different, but one can usually translate a
program in one into the other with very little "forcing".

You note the different styles involved, so presumably your measure of
closeness is weighted towards syntax. I tend to weight it the other
way so I'd smile more at a resume that had "C, C++, Scheme/ML" than
one that had "C/C++, Scheme, ML" though, in fairness, the smile would
be mostly about the in joke.

Actually I meant procedural vs. OOP but with a similar syntax, if that
makes
sense. But I see your point, one could measure in different ways.

cheers