K
Kelsey Bjarnason
He do seem to think that learning C magically imparts a deep knowledge of
C++, don't he?
Weird stuff.
He do seem to think that learning C magically imparts a deep knowledge of
C++, don't he?
Weird stuff.
R
Richard Bos
CBFalconer said:
No, it requires knowledge of C++. It was a question about the behaviour
of the posted code, which was C++ code; it was not a question about the
potential difference in behaviour between that code and similar C code.
Richard
F
Flash Gordon
Richard Bos wrote, On 18/09/07 07:13:
Yes, I meant what Richard has just posted.
Yes, I meant what Richard has just posted.
C
Charlie Gordon
Kelsey Bjarnason said:
Not at all !
Knowing absolutely everything about C (I wonder who on earth would dare
pretend that), and having never even peeked at C++ shows a weird but
absolute will of self-confinement. That may not be the exact current
meaning of obtuse, but it shows both close- and strong-mindedness, which
together hint at blunt lack of intelligence.
Come on, most of us know enough C++ to have made up our minds about staying
with C for a number of applications where the latter is inappropriate. We
may disagree on what these applications are, if not all. But making this
choice out of sheer prejudice is being obtuse.
C
Charlie Gordon
Kelsey Bjarnason said:
I could not find which.
The standard partly retreated on this issue, making sizeof(L'a') ==
sizeof(wchar_t)
Can you elaborate ?
Not really: C programmer is much more restrictive than "someone knowing
absolutely everything about C". For such a person to not know anything
about C++ requires a strong will of not knowing.
R
Richard Heathfield
Charlie Gordon said:
I'd just like to add my two cents here, if I may.
On those rare occasions when I feel obliged to say something about C++ in
this group, I almost invariably qualify it with protestations of ignorance
of the finer details of that language.
This is *not* because I haven't ever studied C++. I have. And I have
written a great many programs in C++ over the years, and I'm perfectly
sure that I know more about C++ than almost anyone I've ever met in person
(the most notable exception I can think of is Sarah Thompson, last heard
of working at NASA, but there are a few others about the place, too).
In fact, I think it would be fair to say that I have about as deep and
thorough a knowledge of C++ as I had of C when I started using this
newsgroup regularly about eight or nine years ago.
Those who were here eight or nine years ago will no doubt recall just how
flawed that knowledge was. I have no reason to believe that my current C++
knowledge is any less flawed now than my C knowledge was then, which is
why I always hedge my statements about C++ with riders and qualifiers.
That does not mean I am wholly ignorant of C++, of course. It just means
that I don't want people taking my word for it on a C++ matter when it may
turn out that they know more about it than I do.
I'd just like to add my two cents here, if I may.
On those rare occasions when I feel obliged to say something about C++ in
this group, I almost invariably qualify it with protestations of ignorance
of the finer details of that language.
This is *not* because I haven't ever studied C++. I have. And I have
written a great many programs in C++ over the years, and I'm perfectly
sure that I know more about C++ than almost anyone I've ever met in person
(the most notable exception I can think of is Sarah Thompson, last heard
of working at NASA, but there are a few others about the place, too).
In fact, I think it would be fair to say that I have about as deep and
thorough a knowledge of C++ as I had of C when I started using this
newsgroup regularly about eight or nine years ago.
Those who were here eight or nine years ago will no doubt recall just how
flawed that knowledge was. I have no reason to believe that my current C++
knowledge is any less flawed now than my C knowledge was then, which is
why I always hedge my statements about C++ with riders and qualifiers.
That does not mean I am wholly ignorant of C++, of course. It just means
that I don't want people taking my word for it on a C++ matter when it may
turn out that they know more about it than I do.
C
Charlie Gordon
Richard Heathfield said:
Thank you for this clarification, I feel exactly the same.
K
Kelsey Bjarnason
[snips]
Oh? How about Pascal? Visual Basic? Haskell? Malbolge? Presumably if
one confines oneself to C without looking at these, one is similarly
self-confined, right?
After all, each is a language, separate and distinct from C - like C++ is.
So the argument must hold as well for them as for C++, unless you're now
going to tell us that C and C++ are really the same language, or some such
rot.
Actually, it shows nothing more than focusing on the tools you know, and
possibly the ones you're required to use. Spend too much time dicking
around trying to learn every language or tool you encounter, you won't get
anything done.
You'll also tend to trip over your own tongue, so to speak, as you end up
trying to remember whether a given construct works this way or that way
and in which languages and under what circumstances.
Let's restore some context:
<quote>
char c - '0';
c += sizeof ('0');
what is the value stored in c? There are subtle differences between the
sizeof operator in C and C++, and someone knowing absolutely everything
about C but nothing about C++ would most likely not know the right
answer to the problem I wrote.
</quote>
This is not about "knowing enough C++ to have made up our minds", it is
knowing enough C++ to know the subtle differences between how it operates
and how C operates, which even an expert C programmer is not going to
know.
How does one find out those subtleties? Not by discussing the subject in
a C newsgroup. How does one get help on code which may - or may not, we
simply don't know, that's kinda the point - rely on such subtleties?
Probably by asking in the proper group.
Oh? How about Pascal? Visual Basic? Haskell? Malbolge? Presumably if
one confines oneself to C without looking at these, one is similarly
self-confined, right?
After all, each is a language, separate and distinct from C - like C++ is.
So the argument must hold as well for them as for C++, unless you're now
going to tell us that C and C++ are really the same language, or some such
rot.
Actually, it shows nothing more than focusing on the tools you know, and
possibly the ones you're required to use. Spend too much time dicking
around trying to learn every language or tool you encounter, you won't get
anything done.
You'll also tend to trip over your own tongue, so to speak, as you end up
trying to remember whether a given construct works this way or that way
and in which languages and under what circumstances.
Let's restore some context:
<quote>
char c - '0';
c += sizeof ('0');
what is the value stored in c? There are subtle differences between the
sizeof operator in C and C++, and someone knowing absolutely everything
about C but nothing about C++ would most likely not know the right
answer to the problem I wrote.
</quote>
This is not about "knowing enough C++ to have made up our minds", it is
knowing enough C++ to know the subtle differences between how it operates
and how C operates, which even an expert C programmer is not going to
know.
How does one find out those subtleties? Not by discussing the subject in
a C newsgroup. How does one get help on code which may - or may not, we
simply don't know, that's kinda the point - rely on such subtleties?
Probably by asking in the proper group.
K
Kelsey Bjarnason
[snips]
Which standard? You can't even figure out, apparently, what language is
being discussed.
Which standard? You can't even figure out, apparently, what language is
being discussed.
P
Peter J. Holzer
Since the comment at the start of this subthread was from Charlie, he
doesn't have to figure out what language is being discussed, he knows
it. It is possible, though, that you didn't figure out which language
Charlie was talking about ...
hp
PS: I'd give long odds the language is C.
K
Kelsey Bjarnason
Which one - there's at least three to go with.
B
Ben Bacarisse
Kelsey Bjarnason said:
Are distinct things in your world only ever either the same or
different? Do distinct things ever have similarities and connections
between them? Can these similarities and connections ever vary by
degree?
I know Haskell simply because I am interested in that family of
languages and it's history. The relationship between C and C++ is, I
am sure, well known to you and its seems plausible to me that an
interest in one might be correlated to an interest in the other.
I am trying to find out, in part, if you really see the world in black
and white or if you just like to have a Barney (== a fight).
C
Charlie Gordon
Kelsey Bjarnason said:
Which one - there's at least three to go with.
All of "them" have the same definition of sizeof('a').
C
Charlie Gordon
Kelsey Bjarnason said:
You are so amazingly gifted at playing stupid ;-)
If you followed the conversation, It is obvious from context that you
snipped that the only Standard I even mentionned is C99. It you know shy
sizeof('a') is the same as sizeof(int) in the C language, please enlighten
us! The choice made by the C++ folks makes so much more sense.
Also please tell us why you think the C99 standard defines sizeof(L'a') as
equal to sizeof(wchar_t).
Otherwise, you are just trolling and your posts lead nowhere,
P
Peter J. Holzer
You would have to ask dmr for a definitive answer, but it is consistent
with the integer promotion rules: Whenever an expression has an integer
type smaller than int, it is promoted to int or unsigned int,
respectively. In the case of a constant this promotion would be done by
the compiler anyway, so there is little use for integer constants of
smaller size. Consequently, there are no constants of type char or
short. Only int and long (and long long in C99) and their unsigned
brethren.
(K&R C didn't have float constants either - all floating point constants
were double)
C++ also has a good reason to make the distinction. In C it doesn't make
any difference except in programs deliberately written to show the
difference.
Because the C89 standard did the same? It is a bit inconsistent - I
would have expected something like "a wide character constant has the
type which results from applying the integer promotion rules to type
wchar_t". But it really makes little difference, since even though the
constant may be shorter than int, the integer promotions are applied to
it, making it at least as wide as an int for every operation except
sizeof.
hp
C
Charlie Gordon
Peter J. Holzer said:
I don't buy your "promotional" argument. I think it must be related to
multi-character character constants that were allowed and used back in the
early C days, when people used to pack characters into ints. For instance
login names were originally restricted to 6 characters in order to fit in a
36 bit word. Handy 3 letter abbreviations such as 'dmr' and 'bwk' fit
nicely in 18 bit half words. Parsing such biests without the help or the
need of constant folding involved packing them in a single "character
constant", which of course had to be as large as an int. 6-bit bytes were a
sensible choice on the PDP-10, much less wasteful than 9-bit.
C89 did that because it is the sensible choice, but they could not revert
the awkward historical glitch about char constants, and had to engrave those
as having type int.
P
Peter J. Holzer
While I don't claim to know much about C compilers before the
mid-1980's, I doubt this would ever have worked. AFAIK a char was always
at least 8 bits on all C compilers, and while it is possible that a
multi-character constant used a special 6-bit-encoding instead of just
stuffing 8-bit-chars together, it seems a bit far-fetched.
Also, my copy of K&R I doesn't mention multi-character constants at all.
It's the German translation, though - can anybody check the original?
I do think that the integer promotion rules are a legacy of B (which was
typeless) and possibly also a helped to keep the compiler simple and
small (it only has to deal with expressions of int, long and double
instead of a plethora of types). Making 'A' an int constant is perfectly
consistent with that and makes a lot of sense, while assuming that the
type was chosen as int specifically for a hack of dubious usefulness
makes a lot less sense.
hp
B
Ben Bacarisse
Peter J. Holzer said:
My old K&R (1978) makes no reference to multi-character constants.
Many compilers supported them (I have even used then <blush>) but they
were always regarded non-standard (even before *the* standard) and
non-portable.
D
David Thompson
Not directly, because...
this isn't allowed: 6.7.5.2p4.
The definition must use a specific variable bound (!) like:
char* after (size_t n, int (*vlap)[n] )
{ return (char*) & vlap [1]; }
int main ()
{ int n, vla [n=foo()]; /* or int n = foo(), vla [n]; */
printf ("%d\n", (int) (after (n,&vla) - (char*)&vla) );
/* or HERE IN CALLER can use sizeof vla for bytes,
or sizeof vla / sizeof vla[0] for bound */
return 0; }
which indeed calls foo only once, but must pass the (resulting) bound
explicitly for the callee to know it.
- formerly david.thompson1 || achar(64) || worldnet.att.net