Post #120,559
10/8/03 10:22:43 PM
|
NOT boolean - this is C
its int.
That's C.
Deal with it.
In Java, you can't escape the creepy feeling.
--James Gosling
|
Post #120,575
10/9/03 12:53:53 AM
|
Re: NOT boolean - this is C
I always considered that a good thing, but C gets it wrong too - to me, TRUE should be -1 which is really 0xFFFFFFFF and FALSE is NOT TRUE, which is "turn off all bits in TRUE", which is 0x00000000. I don't understand why this was never standardized. This way there is ONLY one value of both TRUE and FALSE, so you can say NOT TRUE as well as NOT FALSE unambiguously. I always hated the Boolean type but the C way is just as bad.
Note that in an untyped language it makes more sense to have TRUE and FALSE as 1 and 0.
-drl
|
Post #120,596
10/9/03 7:39:39 AM
|
Nah, put on your binary thinking cap. :)
Only the value zero gets special treatment at the machine instruction level. You either have it or you don't. You can branch on it. Anything else requires a comparison first. Besides, you're leaving a rather large gray area between 0x0 and 0xFFFFFFFF that now needs some kind of handling.
Alex
"Don't let it end like this. Tell them I said something." -- last words of Pancho Villa (1877-1923)
|
Post #120,775
10/10/03 11:18:37 AM
|
Yes, yes...agreed
It is C, and C is a poorer C that C++.... (did I actually say that?!?)
It is likely (although by no means certain) that, sooner or later, a C programmer is going to be exposed to C++. When that occurs, there will be a bunch of old behaviors that will have to be changed. Treating the expression inside of an 'if' (or 'while', or the second expression of a 'for') as a boolean expression is one of them. So if you start thinking of the expression inside these as a boolean expression now, that's one less thing you have to do differently when you start playing in C++.
It's not required by the C language; it's just good sense!
jb4
Boy I'd like to see those words on a PR banner behind [Treasury Secretary John] Snow at the podium:
Jobs and Growth: Just Wait.
John J. Andrew, unemployed programmer; see jobforjohn.com
|
Post #120,788
10/10/03 12:20:29 PM
|
Breaking bad habits
Launnching into language war mode, i'd say that the drift towards C++ is probably the hardest habit to break. :-)
I personally think you need to take each language on it's own. C and C++ are not the same language and there are a lot of things which serve you well in C that will have to be unlearnt in C++. The way you handle strings (a pointer to an array of characters vs. a class), the functions that you use (printf vs cout), and the way that you decompose the solution (functions vs. methods) is much different (Macros vs. Templates, the list goes on and on).
As Stroustrap has said in his writings, if you want to learn C++, don't start with C, Smalltalk or any other language. Start with C++. If you want to write C, take what the language gives you.
In C, there really is no disctinction between character values and integers. A character value of '\\0' is just syntactic sugar for the number 0. Any attempt to draw a distinction between character and numbers will have a hard time. In the same vein, there is no concept of boolean in C - there is only 0 and !0. C blends the ideas of numbers, characters, and booleans. The compiler won't care and attempts to conceptualize a distinction between the three will only produce a barrier of understanding about the nature of types within C.
Which brings me to point out that types in C are very different than types in C++. Most of the bad habits of which you speak are related to question of getting into a different mode of typing expressions, variables, etc... In order to transition from C to C++, you have to start being mindful of a totally differing type scheme. It goes well beyond the current question of using the boolean operators to derive a pseudo boolean expression (in C, the boolean operators do not produce a boolean result - they produce a integer value 0 or !0).
Bottom line from my way of thinking is that C is a different language. If you are programming in C, one shouldn't be bothered with what makes sense in other languages like Ada, Smalltalk, Object Pascal or even C++.
|
Post #120,794
10/10/03 12:50:20 PM
|
Good points...
...but...
While I agree with your last statement, there is still a matter of what I will refer to as "laziness". You can write
if (!s[i])
And have it make sense to the compiler. However, it doesn't make sense to the reader ("if not s sub i?" Whazzat?) what you really want to say here is:
if (s[i] != '\\0')
which reads exactly as it is intended to operate ("if s sub i is not equal to the <null> character). The other way is "syntatically correct", but not "semantically correct" form a reader's persepctive. But who cares; I saved a halfadozen keystrokes, and boy am I a kewl programmer! And if u can't figure out what I meant, u shouldn't be reading my program.
Nobody in this business has time for that shit anymore.
jb4
Boy I'd like to see those words on a PR banner behind [Treasury Secretary John] Snow at the podium:
Jobs and Growth: Just Wait.
John J. Andrew, unemployed programmer; see jobforjohn.com
|
Post #120,797
10/10/03 1:14:34 PM
|
Not that I do a tremendous amount of C programming...
but to me "!s[i]" is 1) much more readable and just as understandable from a C mindset and 2) by far the most common idiom I've seen for that sort of thing.
YMMV.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #120,812
10/10/03 2:20:54 PM
|
K&R
I do notice that K&R uses the comparison with '\\0' in all the examples, so I'd probably side with him that it's probably better to do it that way. Usually sticking with the book madee life much simpler.
It's been almost 10 years now since I last did any heavy lifting with C. Best language there was for embedded applications, but I don't have the required patience outside of that arena.
Still, we need to mix up every once in a while and I like hearing from people that care about the craft. :-)
|
Post #120,845
10/10/03 6:32:52 PM
|
My mileage varies. :-)
Sticking an oar in, I know, but I find if(!s[i]) to be less readable than if( s[i] != 0 ). Even now, I just had to refer back to another post to figure out which conditional it was equivalent to! And I've done a lot of C. :-)
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #120,851
10/10/03 6:59:15 PM
|
They are all ugly
Most typically the use would be
if(!*p)
Because the ! operator is typically applied to
1) pointers to check for NULL
2) dereferenced character pointers to check for end of nul
3) parenthesized relational or inequality expressions (what the C++ crowd would call "boolean" expressions).
If applied to an array item I would typically assume the array held pointers.
I have to say that I have C loaded somewhere into my lower nervous system. I haven't even written production C in probably 11 years and it still flows like that trick shot you always used to be able to make as a kid and just realized you still can.
This despite 4 years of hard core pedantically correct C++ use.
C++ is too complicated to fit into a lower nervous system.
In Java, you can't escape the creepy feeling.
--James Gosling
|
Post #120,857
10/10/03 7:19:31 PM
|
Yep.
I actually like the !*s version better myself. But I don't recall ever having seen "s[i] == '\\0'" in the wild.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #120,809
10/10/03 1:50:13 PM
|
The business seems to have plenty of time on its hands
Considering that C and C++ are still endemic. On a general level, why would does one even code in languages based on the C syntax? And why would one use a language where we have to constantly fret over such and ancient concept as memory pointers? The reasons have little to do with maintainability and readibility, having much more to do with flexibility and efficiency. Granted there are best practices and patterns that one should try to abide by, even in the throes of a low level langauge. The current question is whether this particular instance represents an unwarranted shortcut and defies best practices, or whether it is innate to the way one can and should write C code. I don't think your calls that it is indecipherable are true, when one is given the very context of programming in C - and that is the context one should judge the expression - not in some context of another language or paradigm.
if (s[i] != '\\0')
which reads exactly as it is intended to operate ("if s sub i is not equal to the <null> character).
It does not read that way at all. It reads as - is the value at this position equal to a character with the ASCII value of zero. That is very much different that the way you express it. The first obvious problem is what it means to be NULL. The fact is that the end of string terminator is a value - it is not the value null. So in no way are we indicating a null value - i.e. the absence of a value. We're definitely not talking about a null pointer because the pointer is valid to that particular point in the cell. Ok, so null is not the terminology. But what you really mean by the statement is that I want to know whether this value is the same as the value of '\\0'. Well, why do I want to compare it to that value? A detail which must be known to be competent in C is that strings are 0 value terminated. The effect you are trying to accomplish is to find the end-of-string. You do that by searching for the first place in the array that you find the value zero - Not the character 0 - but a value of 0. Bottom line is that you've now got this arcane code written that is intrinsically tied to the internal representation of strings being generated by the compiler. This is not something that's going to be intuitively obvious to the outside observer. if (!s[i])
And have it make sense to the compiler. However, it doesn't make sense to the reader ("if not s sub i?" Whazzat? The way I read it is "if there is not a character" which to my way of thinking is clearer way to express that you are looking for a place in the array where you cease to have characters - i.e. the end-of-string. This is no more intuitively obvious to the outside observer than is the previous construct, but it is something that the average C programmer must grasp. The more frequent use of this construct can be found in Todd's piece, where instead of using the syntactic sugar of the array notation, you use the pointer notation: if (!*s) but it's the same effect. I would venture to guess that this type of expression is a common idiom within C string handling. As long as we're speaking of best practices, the more mundane best practice in any language is to keep knowledge of things in a single place. So instead of harping on the syntactical notation of finding the end-of-string, the better practice is to not give a dang about how one finds the end of string - leave it to a single function and be done with it. There should be one and only one place in the code that even has the knowledge of the internal representation of strings - call it an end_Of_String function. All routines that want to find the end of a string should call that function - not embed logic about using a zero terminator. The only reason this is not done in practice is that people don't want the overhead of a function call. But then you get into the argument of whether knowledge of the ways strings are handled is core to programming in C. And to that end, I think that knowledge of (!*s) is something you must know how to write as well as read.
|
Post #120,847
10/10/03 6:39:40 PM
|
Disagree with several of your premises
First: if (s[i] != '\\0')
which reads exactly as it is intended to operate ("if s sub i is not equal to the <null> character).
It does not read that way at all. It reads as - is the value at this position equal to a character with the ASCII value of zero. That is very much different that the way you express it.
Say what!?! There is absolutely no difference there at all. Perhpas you misread the part that says "the <null> character". Look at your ASCII chart, Chris. You'll see that "the character with the ASCII value of zero" is "the <null> character". The fact is that the end of string terminator is a value - it is not the value null. So in no way are we indicating a null value - i.e. the absence of a value. We're definitely not talking about a null pointer because the pointer is valid to that particular point in the cell. No we're not talking about the null pointer, we're talking about the <null> character with is entirely different. if (!s[i])
And have it make sense to the compiler. However, it doesn't make sense to the reader ("if not s sub i?" Whazzat?
The way I read it is "if there is not a character" which to my way of thinking is clearer way to express that you are looking for a place in the array where you cease to have characters - i.e. the end-of-string.
Oh, but there is a character! that's the entire point here...there is a character: It's called the <null> character (among other things), and it occupies code point 0. And since, as you and others have correctly point out, that C is a low-level language, this piece of subtlety must be grokked by all C programmers, or they will mose assuredly be lost. I don't know where you get the idea that "there is not a character"; in C, there is always a character, so long as a char pointer is not NULL (and in some implementations, there is even a character under those conditions). This is an underlying premise of C (and one of the things that "always leads to errors", according to some "pundits"). You have a pointer, then it points to something unless it points to NULL (the NULL pointer, that is; not the <null> character). This is no more intuitively obvious to the outside observer than is the previous construct, but it is something that the average C programmer must grasp. Flat wrong, and this statement indicates a severe hole in your understanding of C. The average C programmer must grasp that there is always a character, and that somebody somewhere (actually, two somebodies: One named Brian, and another named Dennis) imbued one of the values that a character can hold with special meaning in a certain context. If you want to play in that context, you, too, must understand that and use that specialy character value in the way that Brian and Dennis meant it to be used. (Or you could write your own RTL, and do it another way...wait--a third somebody named Bjarne did exactly that....) jb4
Boy I'd like to see those words on a PR banner behind [Treasury Secretary John] Snow at the podium:
Jobs and Growth: Just Wait.
John J. Andrew, unemployed programmer; see jobforjohn.com
|
Post #120,854
10/10/03 7:15:05 PM
|
Dude
the thing you have to get past with C is THERE IS NO HIGHER CONCEPTUAL MODEL FOR THE LANGUAGE.
Stop trying to give it one. C is processor independent assembler. Period. If you don't see MOV STO ADD JMP instructions in your head (for any sufficiently abstract machine code) when you write C then you're not going to be very good at it.
Furthermore, by forcing non-C idioms into your code you just annoy the piss out of the veterans who view your added "clarity" as NOISE.
In Java, you can't escape the creepy feeling.
--James Gosling
|
Post #120,863
10/10/03 7:34:32 PM
|
Which reminds me - C++ is why our hardware sucks (new thread)
Created as new thread #120862 titled [link|/forums/render/content/show?contentid=120862|Which reminds me - C++ is why our hardware sucks]
In Java, you can't escape the creepy feeling.
--James Gosling
|
Post #120,865
10/10/03 7:38:05 PM
|
rofl
This reminded me of the situation with relativity when it first emerged - people were trying to make mechanical models of light propagation that were just all balled up, then along comes E and says - "knock it off! It ain't that way, peeps!"
-drl
|
Post #120,877
10/10/03 10:31:25 PM
|
Heh
We're studying assembler now in the course I'm taking.
The very early part of the course was pretty boring (to me, at least), but we're getting to the good parts now.
--\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca] [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Kingston Ontario Canada [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
|
Post #120,981
10/12/03 11:42:07 AM
|
Dude...
If you'd read my post, you'd see that that's exactly what I was saying. It's Chris that's trying to ad some level of abstraction to C by coming up with this "the <null> character is the absence of a character" stuff, not me. My premise, stated explicitly for all (including you) to read was: There is always a character, that the <null> character is a character just like any other, and that the Founding Fathers gave that character a specific meaning in a specific context. Reading is a skill. Furthermore, by forcing non-C idioms into your code you just annoy the piss out of the veterans who view your added "clarity" as NOISE. Listen, Todd, I'll put my C experience up against anybody's on this forum, including yours. My "veteran" status is well documented. I don't do anything to explicitly piss off anybody (and, I don't resort to ad hominem insults designed to piss of other people, either!). If you want to write what I refer to as "UNIX-style" code -- terse, hard to read, keystroke-miserly -- you go right ahead; I'll continue to use flourishes like clear logical flow, block-structuring, abundant whitespace, clear variable names, and all the keystrokes I deem necessary (and not one extra). And if that pisses you off, Mr. Highly-revered Veteran, then that's your problem, not mine. jb4
Boy I'd like to see those words on a PR banner behind [Treasury Secretary John] Snow at the podium:
Jobs and Growth: Just Wait.
John J. Andrew, unemployed programmer; see jobforjohn.com
|
Post #120,995
10/12/03 4:03:23 PM
|
Whoa, JB gets feisty!
I don't think he was insulting you. You're both the shit in my book.
-drl
|
Post #120,999
10/12/03 6:42:01 PM
|
Non-sequitur
clear logical flow, block-structuring, abundant whitespace, clear variable names... I don't think anybody is arguing for unclear illogical flow, whatever the opposite of block structuring is, no whitespace, or cryptic variables names. The discussion was on the preferred technique for testing for string termination and null pointers. Stay on topic please. Oh, and "you" was meant as the plural non specific "you" - as in "you all people who prefer the newer Java/C++ way".
In Java, you can't escape the creepy feeling.
--James Gosling
|
Post #121,017
10/12/03 10:39:06 PM
|
OK, then apology accepted........;-)
(and the opposite of block structuring is oftern referred to as "spaghetti"...)
jb4
Boy I'd like to see those words on a PR banner behind [Treasury Secretary John] Snow at the podium:
Jobs and Growth: Just Wait.
John J. Andrew, unemployed programmer; see jobforjohn.com
|
Post #120,795
10/10/03 12:56:42 PM
|
I'd have to agree
I mean, C looks like it's all about bit-twiddling from what I've seen of it so far. Which is cool; I can completely see the utility of that approach.
Here's an example. I've got a friend in the bio dep't at Queen's that wants to check a bunch of data output by a molecular modeller. He wants to take the atom's locations in space and group them according to how close they are to each other, paying particular attention to hydrogen and oxygen atoms.
This means comparing each atom's location to every other atom's location, which means that you're looking at O(n^2) at best, and the data sets can be big.
He wrote something in VB (gack!), and another friend is writing something for him in perl. I don't think it will perform well in either of those languages (well, we already know it's crap in VB; after running for ~24 hours it had processed 400 records out of a set of ~3000, though I bet I could optimise his algorithm for him). Tossing all the data into arrays and running pointers over them will probably end up being a lot faster, esp. if I can really pare down the operations to be performed, which is going to largely consist of a bunch of 3d math.
As for dealing with boolean -> 1|0 vs boolean ->!0|0, I've already done OO languages with that concept firmly in place; object rexx has the .true and .false objects in the .environment directory, for example. I can see why C does it the way it does, and I can see the advantage and disadvantage. In a lot of ways, types in C look like a bit of sugar; it's really about how many bits are in the type, not the kind of information within it, and there can be good things about numbers being characters and vice versa. If you're coming from something like java or orexx, you have things to unlearn as well.
--\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca] [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Kingston Ontario Canada [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
|
Post #120,813
10/10/03 2:30:03 PM
|
Used to be a Fortran thing
Still lots of scientific stuff using Fortran. I don't know that C ever managed to equal the speed with which arrays can be processed.
VB and Java have a lot of overhead that can be dispensed with - GC & boundary checking being the most obvious. For many, if not most, efficient programming can be had in these languages, but it does require attention to detail.
One thing I've found is that speed is a tricky problem. Inefficiency and volume of code are not necessarily in direct correlation. You can have routines that are very inefficient but unless they are at the heart of the speed problems, they don't cause a significant degradation. Then again, you can have a routine that is fairly tight be the culprit because it is directly in the path of bottleneck.
|
Post #120,839
10/10/03 5:59:21 PM
|
Re: Used to be a Fortran thing
Very true about speed - my APL mumerical codes tend to be as fast as the C codes, because the primitive operations like inverting a matrix are lightning fast in APL (100x100 matrix is nearly instantaneous on a 300 Pentium).
C has always sucked as an idiom for math, and more or less still does. The one reason I maintain an interest in C++ is that is makes a better idiom for math.
-drl
|
Post #120,855
10/10/03 7:16:11 PM
|
Yep -FORTRAN for math libs rulez
Pity about Raytheon paying a couple friends of mine to rewrite their FORTRAN math lib in C++.
Don't think it ever worked as well as before.
In Java, you can't escape the creepy feeling.
--James Gosling
|
Post #120,864
10/10/03 7:35:43 PM
|
Re: Yep -FORTRAN for math libs rulez
It's the old bugbear, copying of values. For bizapps this can be minimized, but in numeric codes, a naive approach can result in implicit copying of enormous blocks of floats, so the program spends most of its time doing stupid busywork.
-drl
|
