gbadev.org forum archive

i have read through the tutorial in the beginners FAQ thread

however i would like to find more information on C coding, particularly something like a full in-depth look at ALL C commands, fuctions, etc, and how they should be structured and used - like a huge indepth glossary with explanations, and example of correct structure

i do not mind paying for this at all! but where should i look for something like this? thanks

I always recommend the C Primer Plus. It's a big fat book that's actually fun to read.

does this book cover C++ aswell? if it defines every single C function and capability, then its for me :)

if im going to program a GBA game, would it matter wether its C or C++ ?

i plan to practice my initial knowledge by programming a DOS text/character-based recreation of the mobile phone game Snake. I did this with BASIC when i was very young (younger than 10) and it is pretty straight forward. but i need to know MORE C/C++ functions and how to use them, than are specified in the shortened C tutorial in the beginers FAQ thread

It does not cover C++. I would recommend starting with C because it's a smaller language, and the new features of C++ don't make that much sense until you understand the problems they were meant to solve.

Others will disagree, usually on the basis that you should learn things the "right" way from the beginning. To that I say: start at the beginning.

i agree. starting with basics and working your way up is always best

im gonna go buy that book tomorrow, and leave the programming for tonight i think

Are you sure? Many people who write C++ books state the opposite to that. They even sometimes say that it might be bad for someone to learn C first if you intend to use C++. I learned from a C++ book and it was much easier to step down than it would have been to step up. C++ books cover all the basics anyway and often make clear differences between how C syntax would work in certain cases. Then if you have a C++ book at hand you're not shelling out an extra $75 AUD (about $40 USD) for another book to then re-teach you what you already know for the first 10 chapters. Unless you're serious about learning C and intend to use it over C++ then go for a C++ book.

As I said, people will disagree. There are books meant for moving from C to C++, and when the time comes I highly recommend "Thinking in C++" by Bruce Eckel. It does an excellent job of explaining exactly what problem is solved by each feature added to C++, giving the reader the ability to make an informed decision about whether its use is appropriate in each situation.

Edit: BTW, what is this "are you sure" stuff? If a beginner was sure, that would only imply that they are not aware of the fact that they are a beginner!

Hey I thought I'd chime in.

for a C Beginner, I recommend "C for Dummies" Vols I and II.

Depending on your skill level you may want to start with Vol II. Vol I covers the extreme programming basics: arrays, strings, operators, if-then, loops, etc.

Vol II is more advanced topics explained in depth and easily understandable. advanced strings & arrays, a good chapter on pointers, structures, modularization, etc.

The author explains it so any dummy can understand it. I think it's why they named it that.

I already knew C, but I found them both at a book outlet store (in an outlet mall), so I thought I'd pick them up for reference. I learned a few little tricks I didn't already know. Amazon probably has them cheap too.

sajiimori wrote:

Edit: BTW, what is this "are you sure" stuff? If a beginner was sure, that would only imply that they are not aware of the fact that they are a beginner!

I was talking to you.

I can't recommend any really good C/C++ books - initially I learned from the error messages in the borland turbo C++ compiler. I do not recommend this as a good way to learn a language - it takes forever, and you may still not understand why certain things do or do not work.

I vote for learning C before C++. I believe that it is simpler, easier to understand, and it is a good precursor to learning C++. In fact, I think that a good way to go (for someone with significant time) might be to learn a better Object Oriented language like Java, so you get used to OOP, then learn C to get used to the syntax, then C++. Also, I strongly reccomend practicing a little C code in windows before you get too heavily into the GBA. Having a convenient debugger that's built right in to your IDE can make a big difference. Turbo C can actually be had for free here:
http://bdn.borland.com/museum/

I realise that you want to do GBA coding, so advice to the contrary is unlikely to sink in. As such, let me just say that IMO the following is the perfect first gba program. It will serve you well:

/**************************************/
static dprint_asm(char *s)
{
asm volatile(
"mov r0, %0;"
"swi 0xff;"
:
: "r" (s)
: "r0");
}

int main(void){
dprint_asm("Hello World");
while(1){}
}
/*****************************************/

The dprint_asm function is one of the most important learning tools you will ever come across when learning to code for the GBA - it is the simplest, easiest way to spit out debug info. Don't worry about understanding it yet. Just know that it spits text into the debug window in your emulator.

Anyway, that's just my opinion. I already did my CS degree before getting into the GBA, so take it with a grain of salt. . .

--Neil

Quote:

I was talking to you.

Oh, well I am sure of my own experience. I learned C very well first, and then appreciated the features of C++ all the more when I learned them. And then I discovered the limitations of C++ and moved on to Python, Lisp, Scheme, Lua, and most recently Haskell.

It's been an extremely rewarding experience, building up from QBasic.

Krakken wrote:

Are you sure? Many people who write C++ books state the opposite to that. They even sometimes say that it might be bad for someone to learn C first if you intend to use C++.

I would have to disagree with the people that say that.

I used to do some Computer Science tutoring at college, for the intro to programming class. We had two professors teaching it: one started the students straight into classes/objects/etc. from almost day one, but the other started procedurally and built up to classes.

I had to help numerous students from the first professor's class throughout the semester. Many of them were having major problems understanding and completing the assignments. I noticed fairly quickly that the vast majority of their problems stemmed entirely from a complete lack of understanding of basic flow of execution, functions, parameters, conditionals, etc. A few of them were so lost I ended up having to refer them back to the instructor, otherwise I would have had to completely duplicate that professor's efforts and come up with a complete lessen plan of my own.

The other class by contrast (the one that started with procedural concepts and built up to classes/objects) had hardly any students coming in for help. The few that did come in were only in for minor help, often just for double-checking, or for quick two-minute problems that I was usually able to coax them into answer correctly for themselves. Not once did I ever see one of them have any problems understanding object-oriented concepts.

I would agree with the C++ book authors that switching to an OO style of thinking can be difficult after becoming deeply entrenched in procedural-style over years of experience. But it's been my experience that OO-concepts are things that *must* be built on top of the procedural basics. After all, how can you understand a member function if you don't understand a function?

sajiimori wrote:

Quote:

I was talking to you.

Oh, well I am sure of my own experience. I learned C very well first, and then appreciated the features of C++ all the more when I learned them. And then I discovered the limitations of C++ and moved on to Python, Lisp, Scheme, Lua, and most recently Haskell.

It's been an extremely rewarding experience, building up from QBasic.

That's cool, it's just not everyone's the same. I never really had a problem learning C++ first off but maybe that's just me. I'm just throwing in my own recommendation. Either may be better for ThUg4LiFe; it's up to him to decide which he prefers. :)

I agree it may be harder than starting off with learning C but not by very much. If you think you can handle it, go for C++. If you have no previous programming experience at all, maybe C is a better option for you.

I'm going to have to chime in and say go with C first. If you're just a beginner and want to get stuff working right away, you probably don't want to confuse yourself with such things as polymorphism or OO methods.

For me, I learned C first and later read up on C++ but since I was beginner, I didn't see immediate need for the advance concepts that C++ provides. It was just more stuff to process in my head when learning the language. Later, I worked on larger apps and realized I needed to group code and data together somehow and found OO concepts really helped in that regard.

Of course, you may differ, but I think if you want to get into coding right away and don't care about "correctness" in coding and best practices, go for C. In my opinion, do what's fun when you're first learning, 'cause that'll keep you going. (Not that C does not allow you to code correctly. It does, but it's true that OO is natural and easier to use for certain applications, like GUIs.)

I Learnt C first, for two (well, 3) reasons:
I read into GBA development alot and found (at least thought) that most people used C, and the many tutorials out there seemed to be in C, so I thought that it was the only way to go.
I bought a book on C++ very early on, and by reading the 1st (and what i thought was the only) page of the introduction, and it seemed perfect. Then, when I took it home and opened it, it said that this book was 'to step up from C to C++ and Object Ori......' So, I had to learn C first to use that book; and I was going to use that book, I was 12 and it cost ?10.. that was 4/9 (or so..) of my monthly money, and i wrecked a few bags in the time getting it home.
The third bad reason, is that I couldn't find very good (or new..) C++ books in my library, so I got two C books out, one of which I found awful, the other of which was old, but Ansi, and easy to read, by an English author (not that American authors aren't as good or anything, just it used a lot of real life scenarios about a boy at universitie (college) and him going out etc. to work out how to build the pseudocode and put it into steps etc. and I didn't really want too many American anecodotes or something I wouldn't realize) and No one else wanted it for three months, so I could renew it three times (maximum) and then take it back,having finished it. I take long times because of long school, huge homeworks and tiredness on Saturdays and Sundays when I program.

But, I agree with both the sides, because from C you can step up, but won't neccesarily have the correct programming style, so who knows, just go with your personal preference, borrow a few books from a library.

i think i will go with C

i feel i already have a good grasp of how the lanugage works.. all the things talked of in the C tutorial in the beginners FAQ. also, the OVERALL structure is similar to Basic IMO but the individual codes/functions and their individual structures are obviously completely different

i learnt all the forms of Basic i know from self-teaching, trial and error, and using the list of functions and observing the error messages - in the case of VisualBasic. Basic was a lot easier as the structure is very, well, Basic and almost looks like normal english language IMO! i dont think it would be good to learn C like this though either - due to the complexity

all the things talked about in the C tutorial in the beginners FAQ i didnt really have too much trouble understanding. its all the AVAILABLE functiona and codes i am now interested in using so i want a nice thorough, descriptive, book which features hopefully a list of all commands available and descriptions on how to use them

ive read though all the posts here and im sure everyone has their reasons for their opinion - but i am going to start with C; and learn C++ in there is a need to

i assume that using C++ would be benifical as in easier to program than C ONCE you understand it - and would also make shorter simpler codes than C to perform troublesome C tasks? am i right? thus allowing more to fit on a GBA cart

* LordGraga waves at Thug *

Yeah, go for the C, C++ for GBA seems like an overkill to me :P

Quote:

Yeah, go for the C, C++ for GBA seems like an overkill to me :P

Nah, it's still nice to have the extra features when you become a good enough programmer to be hitting the "ceiling" of what C provides.

(Since that could almost be flamebait if interpreted in a negative way, I'll just say that it's not inevitable that a programmer will feel limited by C when they get good... but you definitely won't hit that ceiling until you get good enough.)

Edit:

Quote:

i assume that using C++ would be benifical as in easier to program than C ONCE you understand it - and would also make shorter simpler codes than C to perform troublesome C tasks? am i right? thus allowing more to fit on a GBA cart

You can often make your source code shorter (i.e. fewer syntactic elements) with judicious application of C++ features, but there is no correspondence between moving to C++ and getting shorter compiled output.

In fact, some have complained that C++ makes their executables larger, but that's usually due to careless use of features that involve automatic code generation. It can also be larger if you statically link in the C++ standard library, which is larger than that of C.

Also, code isn't usually a big space consumer on GBA games -- graphics and sound are the bigger concerns.

sajiimori wrote:

Quote:

Yeah, go for the C, C++ for GBA seems like an overkill to me :P

Nah, it's still nice to have the extra features when you become a good enough programmer to be hitting the "ceiling" of what C provides.

(Since that could almost be flamebait if interpreted in a negative way, I'll just say that it's not inevitable that a programmer will feel limited by C when they get good... but you definitely won't hit that ceiling until you get good enough.)

Yeah, that's total flamebait, dude. You definitely do not need all the features of C++ for many applications. I'm sure you can find ways of shoehorning your app to make it use C++ features, but there are always methods of getting by without it. Whether or not it's because C is limited is a matter of opinion.

It is silly to argue that one is better than the other, period. C++ provides you with extra tools to do different things. That's it.

I agree with everything you just said, and I don't see how it conflicts with what I said.

The idea is difficult to express without it sounding bad, but it is not bad. In retrospect, the mistake in my previous post is very subtle: I said "...it's still nice..." which is an absolute statement, but it should be conditionalized on whether the programmer feels limited by C.

The mistake is apparent when you imagine a programmer who is good enough to potentially feel restricted by C and yet does not find it nice to have C++ features (e.g. possibly Dan), and compare to the programmer who is also good enough to feel restricted by C and does find C++ features nice (e.g. possibly me if I'm even that good).

So, being good is a prerequisite of feeling restricted by C, but it is not a causative factor. I still stand by that.

I learned C++ 'first', and never learned C. I had no problem understanding the language. The main reason I went with C++ is because to me OOP is much clearer and easier.

sajiimori wrote:

The mistake is apparent when you imagine a programmer who is good enough to potentially feel restricted by C and yet does not find it nice to have C++ features

It's interesting that you express it this way, because I actually feel restricted often when using C++, as though I need to write my code and engineer my program in a certain style if I want to be able to take advantage of those features.

That's what inconveniences me: the built-in assumed methodology.

Dan.

That's an interesting psychological issue. Do you think you'd get that restricted feeling if somebody edited all your makefiles to use g++ but didn't alter any of your code?

(Let's assume that your code happens to not do anything that's illegal in C++, which I'm sure you'll agree is not that far-fetched, unless you're one of the few C programmers that doesn't use prototypes.)

sajiimori wrote:

That's an interesting psychological issue. Do you think you'd get that restricted feeling if somebody edited all your makefiles to use g++ but didn't alter any of your code?

No, but then I'd have written some pretty awful C++ code. :P

Dan.

I don't understand how using a different compiler can turn good code into bad code. (I'm assuming you think your code is good to begin with. If you thought you could only write good code in C++, I imagine you'd be using it.)

If I'm understanding you correctly, the thing that changes is not your code but only what others expect of you. I mean, if you are truly as mentally free as you tell others to be, then you should be able to choose to not use C++ features and still be confident that your code is good.

In fact, you do this every time you write something in C.

sajiimori wrote:

I don't understand how using a different compiler can turn good code into bad code.

It doesn't turn it into bad code. It's still good C code, just bad C++ code.

It would compile successfully as Objective C code as well, but I wouldn't necessarily call it good Objective C code either.

Dan.

It's not bad code, but it's bad C++ code? Let me try to ignore my instinct that the sentence is meaningless, so I can ask you this: What would make it bad C++ code (according to your views, not the expectations of others), and how did you come to that conclusion?

I think he means that just because it's correct C++ syntax, a C program might be a poor C++ program if it doesn't really use the capabilities that C++ provides.

sajiimori wrote:

It's not bad code, but it's bad C++ code? Let me try to ignore my instinct that the sentence is meaningless

... What's meaningless about it? "code" != "C++ code".

Quote:

What would make it bad C++ code (according to your views, not the expectations of others), and how did you come to that conclusion?

The choice of language is not reflected in the code if you can't tell it apart from regular C code. If you present me with C++ code that I cannot distinguish from C code and tell me that it was written in C++ rather than C, then according to my views either the language was poorly selected or the code was poorly written.

Dan.

Quote:

If you present me with C++ code that I cannot distinguish from C code and tell me that it was written in C++ rather than C, then according to my views either the language was poorly selected or the code was poorly written.

What if, during the course of development, I never encountered a problem that I felt warranted the use of a C++ feature? Would that mean I had been making a mistake the whole time by using g++ to compile? If so, why?

To backtrack a bit, isn't it true that the program in question is written in C++, if only incidentally, and even though it is also written in C? If so, then why does calling it C++ code imply that a mistake was made, during either the choice of language or the writing of the code?

If there was a mistake, is the resulting program any worse off?

sajiimori wrote:

Quote:

If you present me with C++ code that I cannot distinguish from C code and tell me that it was written in C++ rather than C, then according to my views either the language was poorly selected or the code was poorly written.

What if, during the course of development, I never encountered a problem that I felt warranted the use of a C++ feature? Would that mean I had been making a mistake the whole time by using g++ to compile? If so, why?

I'm not going to split hairs with you over which compiler options you use. Objective C code is compiled by calling GCC as well. That's not the point; it never has been.

Quote:

To backtrack a bit, isn't it true that the program in question is written in C++, if only incidentally, and even though it is also written in C? If so, then why does calling it C++ code imply that a mistake was made, during either the choice of language or the writing of the code?

I'm not sure what you're trying to get me to say here. I'll put it to you very simply: if you write a program in C++ that doesn't use any of the language features that C++ offers versus C, then it's probably a better C program than it is a C++ program.

It seems like you want me to say C and C++ are the same thing because C++ is (ostensibly) a superset of C. Do I really need to explain why that isn't the case?

Quote:

If there was a mistake, is the resulting program any worse off?

No better or worse off than if it had been coded in assembly or Fortran or Haskell (suitable compiler permitting). I never said it would be.

But don't bring me a reasonably complex program written in C++ code completely devoid of any classes, namespaces, private/protected members, virtual functions, typed constants etc. but all of the C equivalents to those (where applicable) and tell me it's good C++ code.

Or would you call an entire progam written in one gigantic asm() statement a good C program?

Dan.

I think people need to think beyond the scope of their language when labelling code as good / bad. With C++ being a superset of C, then what is true in C is true in C++ (superset rules).

Superset rules asside, if the code in question is good; then it is good, regardless of whether you save it as .c or .cpp. Classes and constants are a feature of C++, and its use makes you no more wiser or ignorant.

Having said that there's nothing wrong with your opinion of compiling in C when no C++ features are used, unless doing so makes no difference to what comes out.

Quote:

I'll put it to you very simply: if you write a program in C++ that doesn't use any of the language features that C++ offers versus C, then it's probably a better C program than it is a C++ program.

It sounds simple enough initially, but I am arguing that the content of that statement disappears on closer inspection.

Quote:

It seems like you want me to say C and C++ are the same thing because C++ is (ostensibly) a superset of C.

We apparently agree that they are not the same thing, and that C++ is (ostensibly) a superset of C.

Quote:

But don't bring me a reasonably complex program written in C++ code completely devoid of any classes, namespaces, private/protected members, virtual functions, typed constants etc. but all of the C equivalents to those (where applicable) and tell me it's good C++ code.

Yeah, I'm trying to get you to tell me why not.

Quote:

Or would you call an entire progam written in one gigantic asm() statement a good C program?

Actually I wouldn't call it a C program at all, because C doesn't include asm() statements.

But let's say it did. Or better yet, let's say it's a C program that doesn't use any structs, because that is an example of choosing to use only a subset of your available features, which is what I would be doing if I wrote a C++ program that only used features available in C. Assume that it is otherwise written the way you would write it yourself.

Bad C program? Good C-- program, where C-- is C without structs? Both? If it is bad in C, then why? Is it because the programmer didn't use the language to its fullest?

Use it for what? To make the program better. Not to make it a better C program (because we are currently defining what that means), but to make it a better program, period.

Program quality is independent of language.

Props, keldon. But...

Quote:

With C++ being a superset of C, then what is true in C is true in C++ (superset rules).

No. When using C, one might say "This is the best solution given the available features," and that may cease to be true when moving to C++. That is, a better solution may become available given a wider selection of features.

Interestingly, the same cannot be said of moving from C++ to C. Those who wish to complete that thought may do so on their own terms, because the natural conclusion is flamebait if made explicit.

sajiimori wrote:

Quote:

But don't bring me a reasonably complex program written in C++ code completely devoid of any classes, namespaces, private/protected members, virtual functions, typed constants etc. but all of the C equivalents to those (where applicable) and tell me it's good C++ code.

Yeah, I'm trying to get you to tell me why not.

Because the code is needlessly complex. In the same way I could simulate a while loop with gotos, I don't because it unneccessarily complicates something that the language already provides for me.

Quote:

Actually I wouldn't call it a C program at all, because C doesn't include asm() statements.

Please. You established the precedent here by talking about compiling with G++ instead of GCC. Don't pick nits with me over what's an official part of the C language and what's a GNU extension to it.

Quote:

Use it for what? To make the program better. Not to make it a better C program (because we are currently defining what that means), but to make it a better program, period.

Program quality is independent of language.

I don't know what you're going on about. You seem to want to debate over philosophies of why coders should do things certain ways, when all I've been saying is that a C++ program that uses strictly C conventions rather than C++ features to accomplish the same thing is a better C program than it is a C++ program. Nowhere in there is there a statement valuing the overall or absolute measure of the program.

Dan.

Quote:

Because the code is needlessly complex.

Then all C code is needlessly complex, because it could be made simpler by using C++ (assuming compiler availability). Edit: To put it more forcefully, it means there's no such thing as "reasonably complex" C code -- all complex C code is unreasonably so.

Quote:

...a C++ program that uses strictly C conventions...is a better C program than it is a C++ program. Nowhere in there is there a statement valuing the overall or absolute measure of the program.

I think it's no statement at all. It carries no meaning unless you introduce the concept of absolute program quality.

My previous post contains the entirety of the argument, so I won't repeat it unless you have a specific question.

Quote:

...a C++ program that uses strictly C conventions...is a better C program than it is a C++ program. Nowhere in there is there a statement valuing the overall or absolute measure of the program.

I think it's no statement at all. It carries no meaning unless you introduce the concept of absolute program quality.

Sure it does. A good C program is not the same thing as a good C++ program is not the same thing as a good assembler program is not the same thing as a good Objective C program etc. That's all there is to it.

I have nothing further to add either. The only point I was ever interested in making is that the features in C++ can be inherently restrictive to the way you program. There is no value to me in wasting pages trying to prove something that should be as trivial as saying that the standards and expectations for what high-quality code looks like is different for different languages.

Dan.

sajiimori wrote:

Then all C code is needlessly complex, because it could be made simpler by using C++ (assuming compiler availability). Edit: To put it more forcefully, it means there's no such thing as "reasonably complex" C code -- all complex C code is unreasonably so.

"Assuming compiler availability" is a big one. Did you mean to say that the only "reasonably complex" C code is a C++ compiler written in C because it helps bootstrap a C++ environment from a C environment? Even so, "assuming library availability" should enter into it as well, as the new language features in C++ need library support, which often isn't practical on some smaller architectures tuned for C.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Quote:

That's all there is to it.

You keep repeating your assertion, but I still haven't heard you define what it means for the same code to be good in language X but not good in language Y, when it meets the exact same requirements (that is, it is "no worse off" either way).

Quote:

...expectations...

That reminds me, you never did answer my question about whether it's all about other people's expectations of you. Is that what it comes down to?

Quote:

"Assuming compiler availability" is a big one.

It certainly is, but it is nonetheless a requirement for the statement to be true. That means people who use C for lack of a suitable C++ implementation are not creating needlessly complex software (at least, not for that reason).

Quote:

Even so, "assuming library availability" should enter into it as well, as the new language features in C++ need library support, which often isn't practical on some smaller architectures tuned for C.

I'll take the easy answer and say C++ is not available on a platform if it is impractical to implement it. There is a better answer but I don't have time right now.

sajiimori wrote:

Quote:

That's all there is to it.

You keep repeating your assertion, but I still haven't heard you define what it means for the same code to be good in language X but not good in language Y, when it meets the exact same requirements (that is, it is "no worse off" either way).

If all you care about is functional requirements, there may very well not be any difference. If you care about things like readability, maintainability, verifiability and infrastructure it makes a tremendous difference. You know very well that the definition of "good code" does not exist in the bubble of solely what instructions are executed on the machine.

Would you be impressed with the quality of code for a GBA game that uses exact memory addresses everywhere instead of constants? It meets the exact same requirements.

Quote:

...expectations...

That reminds me, you never did answer my question about whether it's all about other people's expectations of you. Is that what it comes down to?

It's part of it, but not the largest part. I'm not going to select a language if I don't intend to use its features or follow its programming methodology; I'm going to choose the one that best suits it.

Dan.

Dan, I do think you have a good point; but I do think a better argument is needed.

Quote:

It's part of it, but not the largest part. I'm not going to select a language if I don't intend to use its features or follow its programming methodology; I'm going to choose the one that best suits it.

Isn't asm code is going against a programming methodology of any language, by taking a low level methodology? And if so, is that a bad thing?

Shouldn't your programming methodology mirror your design methology, or reflect on it? Maybe not, since OO design does not imply OO programing. It works scaling down, but not up.

keldon wrote:

Quote:

It's part of it, but not the largest part. I'm not going to select a language if I don't intend to use its features or follow its programming methodology; I'm going to choose the one that best suits it.

Isn't asm code is going against a programming methodology of any language, by taking a low level methodology? And if so, is that a bad thing?

I don't follow this statement at all. How can you be going against the methodology of any language by taking a methodology?

Quote:

Shouldn't your programming methodology mirror your design methology, or reflect on it?

Perhaps. It's irrelevant to my argument either way; I'm not talking about design.

Dan.

Quote:

If all you care about is functional requirements, there may very well not be any difference. If you care about things like readability, maintainability, verifiability and infrastructure it makes a tremendous difference.

I am including things like readability, maintainability, verifiability and infrastructure in my definition of "requirements".

Quote:

I'm not going to select a language if I don't intend to use its features...

What's the harm in using a language that has some features you don't use if you are no worse off by doing so?

Quote:

...or follow its programming methodology

...which just goes back to the expectations of others.

poslundc wrote:

I don't follow this statement at all. How can you be going against the methodology of any language by taking a methodology?

But is that not what happens when you take the C methodology within the C++ environment?

poslundc wrote:

Quote:

Shouldn't your programming methodology mirror your design methology, or reflect on it?

Perhaps. It's irrelevant to my argument either way; I'm not talking about design.

Dan.

Ok, sorry.

sajiimori wrote:

What's the harm in using a language that has some features you don't use if you are no worse off by doing so?

Well, if you're strictly talking about correctness as a C program alone and as a portable C program, you don't want to start allowing extra C++ features by using a C++ compiler. It's going to allow C++ extensions to be valid, even though you are trying to program in C only. A C compiler will disallow any C++ extensions right off the bat. You could argue that if you start using C++ in a strict C program, it's your fault, but if you can get a machine to force you to do the right thing and it'll reduce the likelihood of human error, then all the better.

Why would you program in C only? Well, maybe you want strict portability with another platform that has no or poor C++ support, but does have good C support. Whatever reason, by using a C++ compiler, you're now allowing C++ extensions to be compiled without warnings.

Quote:

Well, if you're strictly talking about correctness as a C program alone and as a portable C program...

I'm not.

Quote:

Well, maybe you want strict portability with another platform that has no or poor C++ support, but does have good C support.

I have always been assuming that a suitable C++ implementation is available on all target platforms. I understand that my comments do not apply to the many (but decreasing) situations where that condition is not met.

sajiimori wrote:

I have always been assuming that a suitable C++ implementation is available on all target platforms. I understand that my comments do not apply to the many (but decreasing) situations where that condition is not met.

Even if there were a suitable C++ implementation on all platforms, you may still want to limit yourself to C syntax only for whatever reason (perhaps you are more comfortable with it) and in that case, using a C++ compiler for your C code would be detrimental as it would still allow C++ extensions to be compiled.

Quote:

Even if there were a suitable C++ implementation on all platforms, you may still want to limit yourself to C syntax only for whatever reason (perhaps you are more comfortable with it) and in that case, using a C++ compiler for your C code would be detrimental as it would still allow C++ extensions to be compiled.

If you are initially uncomfortable using a C++ feature, and subsequently use it anyway, you must have overcome your discomfort. In this scenario, what is being detrimented (if that's a word)?

You guys know I've only been posting in this thread to get my 1000th, right?

Does that mean we can drop it yet? ;)

Dan.

Hey, you can give up anytime you want! =P

I've nothing to defend... the argument is a perfect circle.

I still say that C++ has a natural tendency to impose restrictions on the methodologies a programmer uses when coding with it. I've not been convinced of otherwise by anything said here.

Dan.

I guess you want me to spoon-feed you arguments so you can sit back and wait for something interesting? Maybe next time you'll indulge us with some actual backup for your statements.

sajiimori wrote:

I guess you want me to spoon-feed you arguments so you can sit back and wait for something interesting? Maybe next time you'll indulge us with some actual backup for your statements.

Ouch. Scathing. I'm tempted to fire back with it seems like you're so intent on picking apart the semantics of what constitutes a language and dismissing statements that you are unwilling to accept as meaningless that it's become impossible for you to see the point in front of your face.

Just tempted.

Dan.

poslundc wrote:

I've nothing to defend... the argument is a perfect circle.

I still say that C++ has a natural tendency to impose restrictions on the methodologies a programmer uses when coding with it. I've not been convinced of otherwise by anything said here.

I think I understand what you're saying, but allow me to clarify. Are you saying that the additional features of C++ often (not always) leads a programmer to use features of the language that they may not necessarily need simply because they're there and maybe be easier to use? They may be easier to use initially, but their complexity may make maintenance a bit more difficult. If this is what you're saying, I think I agree with you.

With C++, it's easy to start looking at everything as objects and creating classes for everything. The downside to this is it often leads to the unnecessary creation of frameworks. I've fallen into that trap a few times before.

The problem you're solving may be a simple one, but once you start creating classes for everything, there is further complexity in all the additional infrastructure that you have to build around it to support the methodology *correctly*. For instance, if you have a private member variable that you want other objects to modify or read, but don't want to allow direct access to the variable, you have to create methods to manipulate it in a "protected" way. You might cheat and just make the variable a public one, but in a way, you're not correctly adhering to proper OO techniques. For large systems, this methodology may be a godsend as it allows better modular programming and it makes working in teams easier as you can well-define the framework and forget about internal details. But for small systems, it complicates things that could be easily done using a procedural language.

Again, the above is not always the case. Your mileage may vary, etc. etc.

Also, Joel Spolsky did a great article on this sort of thing: http://www.joelonsoftware.com/articles/fog0000000018.html

Quote:

With C++, it's easy to start looking at everything as objects and creating classes for everything. The downside to this is it often leads to the unnecessary creation of frameworks. I've fallen into that trap a few times before.

If you free yourself the way Dan tells people to, you won't have that problem. You will be able to focus on finding the best solution to your problem, without feeling pressure to conform to any particular paradigm.

The C++ compiler provides you with extra features, but the temptation to use them won't cause you any distress, any more than the temptation to use a C++ compiler sitting on your hard drive.

Isn't that right, Dan? Oh wait, you said you feel restricted by C++. I must be misunderstanding you.

sajiimori wrote:

If you free yourself the way Dan tells people to, you won't have that problem. You will be able to focus on finding the best solution to your problem, without feeling pressure to conform to any particular paradigm.

The C++ compiler provides you with extra features, but the temptation to use them won't cause you any distress, any more than the temptation to use a C++ compiler sitting on your hard drive.

Isn't that right, Dan? Oh wait, you said you feel restricted by C++. I must be misunderstanding you.

Apparently, you still are.

You maintain that by the technicality that most any C program can be compiled in the C++ compiler, that programming in C++ doesn't affect how a program is written, and a person programming in C++ can choose to eschew all of its features and write a vanilla-C program and still have it considered to be good C++ code, so long as it's good C code as well. I think that's bogus.

I invite you to prove me wrong. Find me an open-source program on the net of reasonable* size that claims to be written in C++ and not C, but doesn't use classes anywhere, and I'll send you a dollar.

In the meantime, I'm happy for you that you live in a world where the tool you use does not affect your approach to a project, and you can saw through a board with your screwdriver.

* - reasonable: >1 source file, >1 author, some RCS system.

Dan.

poslundc wrote:

I invite you to prove me wrong. Find me an open-source program on the net of reasonable* size that claims to be written in C++ and not C, but doesn't use classes anywhere, and I'll send you a dollar.

That's bogus. Show me a rectangle with 4 equal length sides and I'll tell you it's a square. When in fact, it is both. (Perhaps that's a far-reaching analogy, but I was hard pressed to come up with something while sick).

Do you consider using C++ to be just the language definition? Well, since that includes C, anyone programming in C can claim they are programming in C++. Or perhaps you only consider programming C++ to be actually using the C++ extensions (classes, templates, overloaded functions, etc). If your definition is the last, then your above challenge is impossible. Too bad your definition would be wrong (if that is in-fact your definition).

As for "an open-source program on the net of reasonable size that ... doesn't use classes anywhere", there are plenty. Lua was the first to come to mind. But I'm sure you'll argue that it is written in just plain C. And I'll quickly rebutt that as long as I compile it into my C++ game it must be C++, too.

This is a rather pointless debate, though. But I'm sick and just surfing the web today, and felt like typing something before going back to bed :)

Jeff
_________________
massung@gmail.com
http://www.retrobyte.org

jma wrote:

That's bogus. Show me a rectangle with 4 equal length sides and I'll tell you it's a square. When in fact, it is both. (Perhaps that's a far-reaching analogy, but I was hard pressed to come up with something while sick).

Do you consider using C++ to be just the language definition? Well, since that includes C, anyone programming in C can claim they are programming in C++. Or perhaps you only consider programming C++ to be actually using the C++ extensions (classes, templates, overloaded functions, etc). If your definition is the last, then your above challenge is impossible. Too bad your definition would be wrong (if that is in-fact your definition).

I'm not arguing that C++ isn't a superset of C.

You can make the technical argument that anyone programming in C is also programming in C++, and it is logically defensible. They're also programming in Objective C and C99 for that matter, and god-knows-what-other supersets you can conceive of. Sure, you can make the case for it, but then it's no longer meaningful to say that they're programming in any of those languages.

Am I really the only one that sees this? To use your analogy, would you fault someone for preferring not to use the less descriptive name "rectangle" if they can use the more specific name "square"?

Quote:

As for "an open-source program on the net of reasonable size that ... doesn't use classes anywhere", there are plenty. Lua was the first to come to mind. But I'm sure you'll argue that it is written in just plain C. And I'll quickly rebutt that as long as I compile it into my C++ game it must be C++, too.

You conveniently ommitted the part where I said claims to be written in C++ and not C. From the Lua "about" page:

Quote:

Lua is implemented as a small library of C functions, written in ANSI C, and compiles unmodified in all known platforms.

If what you say is true, why didn't the authors say it was written in C++? Should they also say that it's written in Objective C in case I decide to compile it into my Objective C project?

Holy Hannah, what a ridiculously pedantic argument.

Dan.

Don't forget what I said earlier:

jma wrote:

perhaps you only consider programming C++ to be actually using the C++ extensions (classes, templates, overloaded functions, etc). If [that is] your definition..., then your above challenge is impossible.

However,

poslundc wrote:

Holy Hannah, what a ridiculously pedantic argument.

No doubt, but it gives me a little something to do other than sleep while at home today (sniffle, cough, sneeze)... :)

What makes me chuckle when reading through a thread like this is how people can waste so much of their own time arguing a point against someone that they will most likely never meet -- let-alone never work with. These discussions are good to have in a work environment, because they can directly affect the final product.

I'd be curious to take a poll of who here is a...
a) hobbyist
b) student
c) professional developer
d) professional game developer

And actually see where each of these opinions come from. I'd be willing to bet serious money that each of these groups generally feels the same way about issues such as this.

Jeff
_________________
massung@gmail.com
http://www.retrobyte.org

while this debate continues..

is there a GOOD IDE program i can get to help me learn/write code? or am i best off just using the text editor and doing it all myself

jma wrote:

What makes me chuckle when reading through a thread like this is how people can waste so much of their own time arguing a point against someone that they will most likely never meet -- let-alone never work with.

Well, if you care only about the practical applications of arguments you could get rid of half the Internet and no one would miss it. (The other half would be porn.)

Quote:

These discussions are good to have in a work environment, because they can directly affect the final product.

I'd be curious to take a poll of who here is a...
a) hobbyist
b) student
c) professional developer
d) professional game developer

And actually see where each of these opinions come from. I'd be willing to bet serious money that each of these groups generally feels the same way about issues such as this.

I'm a professional developer and a hobbyist game developer. *shrug*

Dan.

i hope my question at the bottom on the last page dont get overlooked ;)

ThUg4LiFe wrote:

i hope my question at the bottom on the last page dont get overlooked ;)

Well, I don't think the IDE is really going to help you if you're just learning. It's definitely useful for debugging if it allows you to step through code and watch variables and such, but it's not going to teach you good programming practices.

The best thing for you to do is go through some tutorials and try writing some simple test programs to get a feel for the language.

Allen

ThUg4LiFe, I really like Visual Studio but it costs money. For no money I'd go for ConTEXT and make. (I hook up F9 to compile, F10 to run, F11 to clean.) I don't like the free IDEs I've seen.

Quote:

You maintain that by the technicality that most any C program can be compiled in the C++ compiler, that programming in C++ doesn't affect how a program is written, and a person programming in C++ can choose to eschew all of its features and write a vanilla-C program and still have it considered to be good C++ code, so long as it's good C code as well. I think that's bogus.

I invite you to prove me wrong.

You want me to prove that C code can be considered good C++ code? I consider my good C code to be good C++ code. QED. (Your requirement regarding an open source project is totally unrelated to the theorem.)

Quote:

In the meantime, I'm happy for you that you live in a world where the tool you use does not affect your approach to a project, and you can saw through a board with your screwdriver.

A nonsensical analogy as you well know.

Quote:

Sure, you can make the case for it, but then it's no longer meaningful to say that they're programming in any of those languages.

It means their code is valid in that language. Is it meaningless to say that a square is also a rectangle? Perhaps it's redundant for those who already know that all squares are rectangles, but it isn't any less meaningful for it.

Quote:

To use your analogy, would you fault someone for preferring not to use the less descriptive name "rectangle" if they can use the more specific name "square"?

You're backpedaling. All along you've been implying that you would fault somebody for saying "rectangle", not just that we shouldn't blame people for saying "square" (which I don't).

(Actually, you would have been saying that the shape is a worse example of a rectangle than a square, but that would probably be holding you too accountable for somebody else's analogy.)

Last edited by sajiimori on Wed Nov 03, 2004 2:23 am; edited 1 time in total

Ive just spent a load of money of C/C++ books so i wouldnt wanna fork out again for Visual Studio unless i had to, or unless it was really worth it. I could try out ConTEXT

ThUg4LiFe wrote:

Ive just spent a load of money of C/C++ books so i wouldnt wanna fork out again for Visual Studio unless i had to, or unless it was really worth it. I could try out ConTEXT

You do not need any IDE to learn how to program. Just write some code and build it at the command line. If you're a beginner, you're gonna be futzing around with the IDE more than trying to understand the code.

The IDE is an Integrated Development Environment. It's a nice tool to edit your files, but you don't need it. I wrote Project Hazuki using Emacs for text editing and a unix shell to build. That's it. I didn't even use a debugger.

sajiimori wrote:

Quote:

I invite you to prove me wrong.

You want me to prove that C code can be considered good C++ code? I consider my good C good to be good C++ code. QED.

*throw up hands* You win. Remarkable proof. It shouldn't be difficult when you chop a quote off entirely from its context.

Quote:

(Your requirement regarding an open source project is totally unrelated to the theorem.)

No, it's not. You're just choosing the strictest and least meaningful interpretation possible of the theorem to try and disprove. Obviously if I'm using a qualitative term like "good" and a measurement term like "consider" it can't have any significance in absolute terms. This is not boolean algebra and I am not trying to be PVS. Try proving me wrong in the real world, instead of nitpicking the semantics of it.

Quote:

In the meantime, I'm happy for you that you live in a world where the tool you use does not affect your approach to a project, and you can saw through a board with your screwdriver.

A nonsensical analogy as you well know.

If you're looking strictly at C and C++, then perhaps a better analogy would be a single screwdriver and a drill with interchangeable bits. You can use the drill to do the work of the screwdriver, but the drill imposes selection of which type of screw-head to use, and may also expect you to do things you wouldn't be expected to do with the screwdriver, like drill pilot holes and stay close to a power source.

Quote:

To use your analogy, would you fault someone for preferring not to use the less descriptive name "rectangle" if they can use the more specific name "square"?

You're backpedaling. All along you've been implying that you would fault somebody for saying "rectangle", not just that we shouldn't blame people for saying "square" (which I don't).

Yes, your description is more accurate than mine, and it actually reveals to me a more fundamental difference of interpretation: rectangles are a superset of squares, but we define squares in terms of being constrained versions of rectangles. C++ is a superset of C, but do you choose to define a C program as a constrained C++ program (in which case the analogy works), or a C++ program as an extended C program (in which case the analogy is flawed)?

I find it more prudent to go with the second, because there is a temporal relationship (C came first, and the developments of languages (programming and otherwise) are traced through their ancestors), and because we also currently define other languages as extensions of the C language.

The former position - the one I think you have been pushing in this thread - is a technically correct one but doesn't carry the informational weight that the first one does. Yes, all C programs are technically C++ programs, but it is not very practical to try and define a language in terms of what's not there.

Dan.

ThUg4LiFe wrote:

Ive just spent a load of money of C/C++ books so i wouldnt wanna fork out again for Visual Studio unless i had to, or unless it was really worth it. I could try out ConTEXT

I use ConTEXT for all of my Windows-based GBA programming and am quite happy with it.

A good IDE can make your life a lot simpler, but they generally aren't geared towards being learning tools.

Dan.

thanks for the advice. i dont want to use it to learn. thats what the books are for! but i want it to help me along the way with the actual programming i come to be doing soon, just to make my life easier and such. ive already downloaded ConTEXT and it should do the job, its just down to me to keep learning now

i sometimes feel like there is a lot that some books ant tutorials dont want to tell you, and i am still bewildered about how to do some things. i havent even looked at using graphics yet so that will probably make a big difference. but even just with text/characters.. there was basic operations i had no idea how to accomplish with C - such as the format (not format type (char, decimal and so on) but justification or postioning on the screen etc); i had no idea how this is done but i think i may have found out by searching through one book

im assuming theres a way i can view the contents of all the header files which come as standard??? because as i said i feel there is particular features that the books choose to leave out

Quote:

It shouldn't be difficult when you chop a quote off entirely from its context.

I explained why it was chopped off in the parentheses. Hey, I'm not trying to trick you here. I know I can't.

Quote:

You're just choosing the strictest and least meaningful interpretation possible of the theorem to try and disprove.

Proof is a precise thing, so you can't blame me for treating your theorem with precision. My advice is to abandon this silly idea of proof.

Quote:

If you're looking strictly at C and C++, then perhaps a better analogy would be a single screwdriver and a drill with interchangeable bits.

Not good enough. You must specify that the drill has a bit that is exactly the same as the head of the original screwdriver, and furthermore you must be able to use this drill in virtually the exact same way as the original screwdriver without any loss of dexterity.

Quote:

C++ is a superset of C, but do you choose to define a C program as a constrained C++ program (in which case the analogy works),

I could.

Quote:

or a C++ program as an extended C program (in which case the analogy is flawed)?

Right, that's no good. A program that uses C++ features is not a C program at all.

Quote:

I find it more prudent to go with the second, because there is a temporal relationship (C came first, and the developments of languages (programming and otherwise) are traced through their ancestors), and because we also currently define other languages as extensions of the C language.

I understand, but you're confusing the relationship between C and C++ with the relationship between C code and C++ code. I would be inclined to define C++ as an extension to C, but I would not define a program that uses C++ features as an extension of a C program.

Eh. You can probably live without the IDE. In my opinion, it made life a lot easier when I was getting started. I just like being able to trace through my code when I'm getting unanticipated results. There are, of course other ways to approach things. You can set up debugging without an IDE (not recommended for beginners, in my opinion), or you can use print statements to trace your code. I just found that when learning - and this is not an issue that is particularily related to any one language - my programs frequently did not run as anticipated.

Anyway, as you've probably noticed, there are strong partisans on both sides of the C/C++ issue; sooner or later, you'll probably learn both. I think you already said you're going for C, and that's cool. I would say that at this point, you should ignore the discussion for a while and just try out any compiler that takes your fancy. Check out some existing source code, modify it, see how it works, etc. Post again if it doesn't work out.

--Neil

ThUg4LiFe wrote:

i sometimes feel like there is a lot that some books ant tutorials dont want to tell you, and i am still bewildered about how to do some things. i havent even looked at using graphics yet so that will probably make a big difference. but even just with text/characters.. there was basic operations i had no idea how to accomplish with C - such as the format (not format type (char, decimal and so on) but justification or postioning on the screen etc); i had no idea how this is done but i think i may have found out by searching through one book

Well, C is just a language. It doesn't define things such as graphics or sound. Those are platform-dependent and often come in the form libraries, which contain pre-defined function calls. Even basic things like drawing a line are not part of the C standard. I believe all programming languages are like this.

ThUg4LiFe wrote:

im assuming theres a way i can view the contents of all the header files which come as standard??? because as i said i feel there is particular features that the books choose to leave out

You're probably referring to the C standard library. There are books on just the standard library. Those provide you with the most common functions you'll need to build up your app, such as math functions (sin, cos, etc.) or streaming input and output. The header files differ with each compiler, but you should be able to read up on your compiler docs to find out where the header files are. These won't be as useful as a listing of the C standard lib, however.

sajiimori wrote:

Quote:

You're just choosing the strictest and least meaningful interpretation possible of the theorem to try and disprove.

Proof is a precise thing, so you can't blame me for treating your theorem with precision. My advice is to abandon this silly idea of proof.

I never said it was a theorem. I simply said that clinging to the technicality that C programs can be compiled as C++ programs doesn't make good C code equal to good C++ code.

Saying "I invite you to prove me wrong" with the relevant challenge in the same paragraph was an attempt to get you to look at in from a practical, real-world perspective, but you just reversed it right back into a matter of absurdly boolean logic.

I still have yet to hear you answer me on whether a well-written C program that uses things like long function-name prefixes instead of methods and namespaces, auxillary structs with enums and function-pointers to keep track of types instead of templates, and function-pointer tables instead of virtual vunctions ought to be considered a well-written C++ program.

Quote:

If you're looking strictly at C and C++, then perhaps a better analogy would be a single screwdriver and a drill with interchangeable bits.

Not good enough. You must specify that the drill has a bit that is exactly the same as the head of the original screwdriver, and furthermore you must be able to use this drill in virtually the exact same way as the original screwdriver without any loss of dexterity.

Fine. I'll even give you that the screwdriver is gonna probably be a heck of a lot slower and require more energy than the drill to do the same amount of work. None of that matters. The point is the same one I made earlier: it's still a different tool, and it still will cause you to approach your project from a different perspective.

Quote:

I understand, but you're confusing the relationship between C and C++ with the relationship between C code and C++ code. I would be inclined to define C++ as an extension to C, but I would not define a program that uses C++ features as an extension of a C program.

Fine, I can agree with that. The perspective is still important when evaluating the analogy, though, because when we compare rectangles and squares we tend to consider the square to be a more constrained version of a rectangle rather than thinking of the rectangle as a relaxed version of the square, whereas when comparing C++ to C it's this second interpretation that is more meaningful.

Dan.

Many language standards include definitions related to multimedia. Some are intended to be general-purpose (like Java, which includes AWT and SWING in its standard), and some are intended specifically for graphics (PostScript, Flash).

allenu wrote:

ThUg4LiFe wrote:

im assuming theres a way i can view the contents of all the header files which come as standard??? because as i said i feel there is particular features that the books choose to leave out

You're probably referring to the C standard library. There are books on just the standard library. Those provide you with the most common functions you'll need to build up your app, such as math functions (sin, cos, etc.) or streaming input and output. The header files differ with each compiler, but you should be able to read up on your compiler docs to find out where the header files are. These won't be as useful as a listing of the C standard lib, however.

This is also where it's useful to distinguish between a tutorial, guide, etc. and a reference. A reference ought to cover all of the features but usually won't present them in an order that's useful if you don't already know what you're looking for, whereas a tutorial or guide may leave some out in order to facilitate an environment you can learn more effectively from.

Keep in mind that if you are doing GBA programming, pretty much all of those libraries go out the window anyway.

Dan.

Quote:

I never said it was a theorem.

Good, then let's forget about proof. If you later decide to reintroduce the idea of proofs to our discussion, then bring a well-defined theorem with you. Then we can discuss the kinds of tests that would put it under the greatest scrutiny, rather than dictating one to me like a homework assignment.

Quote:

I still have yet to hear you answer me on whether a well-written C program... ought to be considered a well-written C++ program.

(Omitted things that are necessarily true about all C programs.) If by "well-written" you mean "good", I think I already answered "yes". If you mean something else by "well-written" (such as "takes maximal advantage of all available features") then you'll have to be more specific.

Quote:

The point is the same one I made earlier: it's still a different tool, and it still will cause you to approach your project from a different perspective.

If your tools cause you to do things, then you are not as free as you tell others to be. If you are prepared to acknowledge that, then we have a resolution. The resolution is that you feel restricted by having more tools available to you, and that you should probably delete your C++ compiler so it won't restrict you by being available. More importantly, you should stop telling people to free themselves from object-orientation, because you are not free yourself.

Somehow I doubt you're willing to accept that resolution, so we should talk about what it means for your tools to cause you to do things.

sajiimori wrote:

Many language standards include definitions related to multimedia. Some are intended to be general-purpose (like Java, which includes AWT and SWING in its standard), and some are intended specifically for graphics (PostScript, Flash).

AWT and SWING are standard libraries, but are not part of the language definition.

The line is not so clear, but you can at least accept PostScript and Flash (which are both computationally complete). ^_^

sajiimori wrote:

Quote:

I never said it was a theorem.

Good, then let's forget about proof. If you later decide to reintroduce the idea of proofs to our discussion, then bring a well-defined theorem with you. Then we can discuss the kinds of tests that would put it under the greatest scrutiny, rather than dictating one to me like a homework assignment.

Spare me; I'm not interested in quibbling over meta-semantics. You say a good C program should also be considered a good C++ program. The challenge was very simply to find a practical example where the creator also does, by finding a program that doesn't use any of the C++ features where the creator still chooses to call it a C++ program. I don't think one exists. Any that do are most likely the extreme exception. (But I'll still send you the dollar.)

Quote:

I still have yet to hear you answer me on whether a well-written C program... ought to be considered a well-written C++ program.

(Omitted things that are necessarily true about all C programs.) If by "well-written" you mean "good", I think I already answered "yes". If you mean something else by "well-written" (such as "takes maximal advantage of all available features") then you'll have to be more specific.

Would I be correct in assuming that by "good" you at least mean "meets requirements"? Because you stated earlier that you considered requirements to include readability, maintainability, verifiability and infrastructure.

Do you really consider a C++ program that uses those C techniques instead of the C++ features to be sufficiently readable and maintainable for you to call it well-written?

If you had an underling program a C++ module for your project where he did this, would you be okay with it on account of it performing correctly? Would you not at all question if he even knew how to program in C++?

What if he used gotos instead of while loops?

Quote:

If your tools cause you to do things, then you are not as free as you tell others to be.

I'm certainly not free of the effects of my tools. That's why I try to choose the appropriate tool for the project, and choose the appropriate language for the program. Perhaps the difference between you and me is that I'm at least aware of the influence the tools have on the code I write.

Quote:

If you are prepared to acknowledge that, then we have a resolution. The resolution is that you feel restricted by having more tools available to you, and that you should probably delete your C++ compiler so it won't restrict you by being available.

I don't feel restricted by having more tools available to me. That's doesn't even remotely resemble anything that comes from the analogy. I don't know where you got that from.

Quote:

More importantly, you should stop telling people to free themselves from object-orientation, because you are not free yourself.

I'm free of it whenever I use a language that doesn't shoehorn me into its methodology. Kind of the point of what I've been saying up 'til now.

Dan.

sajiimori wrote:

The line is not so clear, but you can at least accept PostScript and Flash (which are both computationally complete). ^_^

I merely wanted to point out that a language definition does not usually include a description of how to do basic things like draw pixels or play sound. Those can be a part of a standard library, but they're not part of the language definition. I thought it was useful to point out to our C programming beginner.

I suppose PostScript and Flash do include these, but they're obviously more geared towards displaying graphics and text and are not general-purpose languages. Sorry if that was not clear.

Quote:

I don't think one exists.

I don't really care either way.

Quote:

Would I be correct in assuming that by "good" you at least mean "meets requirements"? Because you stated earlier that you considered requirements to include readability, maintainability, verifiability and infrastructure.

Yes.

Quote:

Do you really consider a C++ program that uses those C techniques instead of the C++ features to be sufficiently readable and maintainable for you to call it well-written?

Still waiting on that definition of "well-written".

Quote:

If you had an underling program a C++ module for your project where he did this, would you be okay with it on account of it performing correctly?

If it meets my requirements of readability, maintainability, verifiability and infrastructure, yes. Depending on the situation, I might be concerned about consistency with the style of the rest of the project, or with the abilities of my other team members to easily understand traditional C idioms (though I would fire them if they couldn't and I had the authority edit: and the means to find better ones).

Neither of these concerns affects the quality of the code (whether you call it C or C++) -- they merely reflect my requirements for the project.

Quote:

Would you not at all question if he even knew how to program in C++?

I might, if I thought there were some reasonably clear ways that he could have applied C++ features to improve the absolute quality of his code. Also, I would be concerned if he failed to meet my requirements, and I thought he would have been able to meet them had he known his tools better.

Quote:

What if he used gotos instead of while loops?

His code probably wouldn't be as good. Also, it is unlikely to meet my requirements, because if I am able to provide my programmers with better tools then I will probably expect better code from them in return.

Quote:

I don't feel restricted by having more tools available to me.

You said you feel restricted by C++, which increases your selection of tools and nothing more (insofar as it is a superset of C).

Quote:

I'm free of it whenever I use a language that doesn't shoehorn me into its methodology.

If compiling with a C++ compiler (which means using C++) shoehorns you into a methodology, why doesn't having a C++ compiler on your hard drive do the same? Both give you the opportunity to use C++ features. At what point do you get shoehorned?

Quote:

Kind of the point of what I've been saying up 'til now.

The closest thing I've heard to a point so far is: "I don't compile my C code with C++ compilers because if I anticipate that the compiler will accept C++ features when I run it, I will be tempted to use them. This effect, which the compiler has on me, will shoehorn me into the methodology of the designer of C++ and the community surrounding it."

I'm not exaggerating or trying to make a straw man. That's seriously what I hear so far, and I'm listening to the best of my ability.

I'll try to make this brief, and this is probably the last response I'll be able to get in today:

sajiimori wrote:

Quote:

Do you really consider a C++ program that uses those C techniques instead of the C++ features to be sufficiently readable and maintainable for you to call it well-written?

Still waiting on that definition of "well-written".

Let's say that you would uphold it as a model for other C++ programmers to code by.

Quote:

Would you not at all question if he even knew how to program in C++?

I might, if I thought there were some reasonably clear ways that he could have applied C++ features to improve the absolute quality of his code.

I'm not sure what you mean by absolute quality. We've established that the C techniques compile into (more or less) the exact same instructions that the C++ ones do.

Quote:

What if he used gotos instead of while loops?

His code probably wouldn't be as good. Also, it is unlikely to meet my requirements, because if I am able to provide my programmers with better tools then I will probably expect better code from them in return.

But the gotos do the exact same thing as the whiles, and perform just as well. Just like the tables of function pointers, name-prefixed functions, etc. do the exact same thing and perform just as well as their C++ counterparts. I need help understanding why using the former reduces the quality of their code and using the latter doesn't.

Quote:

I don't feel restricted by having more tools available to me.

You said you feel restricted by C++, which increases your selection of tools and nothing more (insofar as it is a superset of C).

I said that I feel restricted when using C++, not by having it in my selection of tools. World of difference.

[quote]

Quote:

I'm free of it whenever I use a language that doesn't shoehorn me into its methodology.

If compiling with a C++ compiler (which means using C++) shoehorns you into a methodology, why doesn't having a C++ compiler on your hard drive do the same? Both give you the opportunity to use C++ features. At what point do you get shoehorned?[quote]

The physical compiler has nothing to do with it. It's the conventions and design of the language, and the assumptions that were being made when the language was designed. Do you not see the absurdity in trying to reduce everything to what happens at compile-time?

Quote:

The closest thing I've heard to a point so far is: "I don't compile my C code with C++ compilers because if I anticipate that the compiler will accept C++ features when I run it, I will be tempted to use them. This effect, which the compiler has on me, will shoehorn me into the methodology of the designer of C++ and the community surrounding it."

Dude, you're the only one who talks about compilers in this thread. Everything I say tries to steer the matter away from them, and show that they are totally irrelevant to my point. Have a look back over it and see for yourself. We have a serious problem if this is what you are hearing me say.

Dan.

poslundc wrote:

Let's say that you would uphold it as a model for other C++ programmers to code by.

I would not uphold my code as a model for other coders to go by unless they were solving the same problem.

poslundc wrote:

But the gotos do the exact same thing as the whiles, and perform just as well. Just like the tables of function pointers, name-prefixed functions, etc. do the exact same thing and perform just as well as their C++ counterparts. I need help understanding why using the former reduces the quality of their code and using the latter doesn't.

Out of scope argument.

Both arguments have valid points, but to say a C++ program must make use of C++ features otherwise it is C is no different from saying, (I believe) that a C++ program is Java if it uses classes and not structs, and no goto's; which is more in scope of the argument than comparing it with using direct memory references instead of variable names.

Quote:

I'll try to make this brief, and this is probably the last response I'll be able to get in today:

No problem -- brief is good. ^_^ Man, before I got the hang of online debate (if I ever did), I was in some threads where each post was a series of 2-sentence replies to each sentence of the previous post... and as programmers we all know how that number will grow! x_x

Quote:

Let's say that you would uphold it as a model for other C++ programmers to code by.

Progress! By that, the code is piss-poor C++. That's why I asked earlier if it was about expectations. It makes a world of difference if you evaluate code based on what other people like.

Edit: Oh, it turns out I was reading too fast. My real answer is: Given perfect programmers (don't jump just yet), I wouldn't provide a model at all. They would be able to determine the best features of the language to apply to every problem.

What about imperfect programmers? It depends on how imperfect they are, I suppose. Really sucky programmers might need a lot of hand-holding and outlawing of "troublesome" features (pointer math, templates, globals, whatever) to get them to write reasonably un-sucky code. Slightly better ones might just need some "best practice" kinds of guidelines (like OO), where they can apply them without thinking and get decent results (though it may be overkill or otherwise suboptimal).

And so on. Note that no model will describe the work of the perfect programmer, because he is free. Models are imperfect by definition.

So, "well-written" by this definition can imply many levels of actual quality.

Edit again: I'd better clearly answer the original question. I guess I might provide a model consisting mostly of C features if I had a team of expert C programmers who would explode if they had to use C++ features. It's a bit hard to imagine, but then again I've never had my own team of programmers.

Quote:

I'm not sure what you mean by absolute quality.

D'oh... have I been taking it for granted that we both believe in absolute code quality? I thought for sure you believed in it, because earlier you distinguished between absolute quality and quality in the context of a particular language. You said going from one language to another didn't change how good a program was on its own.

Quote:

I need help understanding why using the former reduces the quality of their code and using the latter doesn't.

There's no distinction, actually. If you miss an opportunity to apply a feature to make your code better (in the absolute sense), then it is not as good as it could be (and going in reverse it reduces the quality).

So, you're wondering why I said it might be ok if some code didn't use C++ features when those features were available? Well, maybe there was no clear opportunity for improvement, or maybe it was good enough as it was. (I would expect the latter to be more common.) Still, I'm not saying that it isn't worse off for not using C++ features.

Quote:

I said that I feel restricted when using C++, not by having it in my selection of tools. World of difference.

This is related to the "which compiler" thing. So, you feel restricted not by programming in C++, but by applying C++ features that aren't available in C?

Quote:

Dude, you're the only one who talks about compilers in this thread.

I have to. You want to say that using C++ means more than using a capable compiler, but then you also say that C++ code can be written that is also valid C, but it would be bad C++.

Basically, your idea of "using C++" is loaded with the expectations of others, and I can only try to go back to which language(s) you're actually writing in. We could have stopped long ago by saying it's all about expectations, but it took a long time to arrive at that and even then you say there's more to it.

I guess we could resolve it by saying that "writing C++" is not the same as "using C++". That's a subtle distinction, and you could probably forgive me for not noticing it 6 pages ago.

Yes, "using C++" (in the sense of absolutely requiring that C++-only features are used) is restrictive, because you literally lose some options. Specifically, all C programs are outlawed.

if C did not exist; then what would a C++ program be written using none of the features C++ has that C has not? =D

keldon wrote:

poslundc wrote:

Let's say that you would uphold it as a model for other C++ programmers to code by.

I would not uphold my code as a model for other coders to go by unless they were solving the same problem.

Then you would make a lousy engineer.

Quote:

poslundc wrote:

But the gotos do the exact same thing as the whiles, and perform just as well. Just like the tables of function pointers, name-prefixed functions, etc. do the exact same thing and perform just as well as their C++ counterparts. I need help understanding why using the former reduces the quality of their code and using the latter doesn't.

Out of scope argument.

Both arguments have valid points, but to say a C++ program must make use of C++ features otherwise it is C is no different from saying, (I believe) that a C++ program is Java if it uses classes and not structs, and no goto's; which is more in scope of the argument than comparing it with using direct memory references instead of variable names.

First of all, this has absolutely nothing to do with what I'm saying in the quote, and has only glancing relevance to anything I have said. I'm talking about code quality, not what language it's labelled under. I find heavy irony in you dictating to me that my argument is out of scope.

Second of all, if you want to be technical, a C++ program stripped of any of the features that distinguish C++ from C is be definition a C program, as well as a C++ program, and also an Objective C and C99 program for that matter if you want to be pedantic about it.

Dan.

sajiimori wrote:

Edit again: I'd better clearly answer the original question. I guess I might provide a model consisting mostly of C features if I had a team of expert C programmers who would explode if they had to use C++ features. It's a bit hard to imagine, but then again I've never had my own team of programmers.

At this point I forget why I asked the question in the first place, so I'm prepared to let the matter drop.

Quote:

I'm not sure what you mean by absolute quality.

D'oh... have I been taking it for granted that we both believe in absolute code quality? I thought for sure you believed in it, because earlier you distinguished between absolute quality and quality in the context of a particular language. You said going from one language to another didn't change how good a program was on its own.

I'm going to let this one go as well, because I think the stuff it pertains to gets covered in other sections of this message.

Quote:

I need help understanding why using the former reduces the quality of their code and using the latter doesn't.

There's no distinction, actually. If you miss an opportunity to apply a feature to make your code better (in the absolute sense), then it is not as good as it could be (and going in reverse it reduces the quality).

So, you're wondering why I said it might be ok if some code didn't use C++ features when those features were available? Well, maybe there was no clear opportunity for improvement, or maybe it was good enough as it was. (I would expect the latter to be more common.) Still, I'm not saying that it isn't worse off for not using C++ features.

(My emphasis.) This is what has me confused. If the code is worse off, then what are we arguing about? That was my basic premise: is that the code when considered in a C++ environment is worse than when considered in a C environment (where the C++ features are irrelevant and moot).

Quote:

I said that I feel restricted when using C++, not by having it in my selection of tools. World of difference.

This is related to the "which compiler" thing. So, you feel restricted not by programming in C++, but by applying C++ features that aren't available in C?

Yes, but I consider those two (that I hilighted) to be essentially synonymous because when I'm not applying the C++ features I don't consider myself to be programming in C++ any more than I consider myself to be programming in Objective C, although both are technically true.

Quote:

Dude, you're the only one who talks about compilers in this thread.

I have to. You want to say that using C++ means more than using a capable compiler, but then you also say that C++ code can be written that is also valid C, but it would be bad C++.

Yeah... now you're hearing me correctly (the second part anyway). As for the first part, the compiler you're using doesn't factor into whether valid code is well-written code.

Quote:

Basically, your idea of "using C++" is loaded with the expectations of others, and I can only try to go back to which language(s) you're actually writing in. We could have stopped long ago by saying it's all about expectations, but it took a long time to arrive at that and even then you say there's more to it.

I'm not sure if it's just a matter of "expectations of others" or not. This is why I bring up the goto example in C. I make the claim that in the language C++, using <insert any example I've used previously> when you could use <insert complementary C++ feature> is what I would consider to be poor coding.

You seem to say that it only matters if others expect a certain style of C++ coding from you, but then by same token I say if that's true, then it should also hold that using gotos instead of while loops in plain C (or C++ for that matter) isn't poor coding because they are functionally equivalent. While loops are meant to automate and supplant the use of gotos the same way classes are meant to automate and supplant what you get when you combine a number of various C features.

Quote:

I guess we could resolve it by saying that "writing C++" is not the same as "using C++". That's a subtle distinction, and you could probably forgive me for not noticing it 6 pages ago.

Yes, "using C++" (in the sense of absolutely requiring that C++-only features are used) is restrictive, because you literally lose some options. Specifically, all C programs are outlawed.

It's fine if you want to put it that way, but that has less to do with my original point about the restrictive nature of C++, which is that when you use the OO features (which most people do by default when programming C++) in shoehorns you into a certain style of both thinking and coding.

Yes, coding in C++ doesn't exhaustively imply you have to use those features... it's just what most everyone does.

Dan.

Last edited by poslundc on Wed Nov 03, 2004 3:47 pm; edited 1 time in total

poslundc wrote:

keldon wrote:

poslundc wrote:

Let's say that you would uphold it as a model for other C++ programmers to code by.

I would not uphold my code as a model for other coders to go by unless they were solving the same problem.

Then you would make a lousy engineer.

How? My code for a program that needs some features and not another is not a good model to go by, but is not necessarily not great code. Because if that is a model to go by then all coders are to use the features I have used and not the ones I have not. Maybe I misunderstood your idea; but what you use in a language is entirely down to your problem. Do you read from a file, or define the data in code? When doing a FSM it would be quite nice to use Goto's, but you may wish to model it as a while loop with a switch statement instead.

Quote:

Second of all, if you want to be technical, a C++ program stripped of any of the features that distinguish C++ from C is be definition a C program, as well as a C++ program, and also an Objective C and C99 program for that matter if you want to be pedantic about it.

OK. Now the question is again in a world where C does not exist, does code fitting such a description constitute as good C++ code? If no, then do you say C++ code must be completely OO based? With/without structs?

To add a perspective to the argument, consider another language completely, that has features that C++ has and your answer may be less biased to the fact that C exists.

Explain your irony?

keldon wrote:

poslundc wrote:

keldon wrote:

poslundc wrote:

Let's say that you would uphold it as a model for other C++ programmers to code by.

I would not uphold my code as a model for other coders to go by unless they were solving the same problem.

Then you would make a lousy engineer.

How? My code for a program that needs some features and not another is not a good model to go by, but is not necessarily not great code. Because if that is a model to go by then all coders are to use the features I have used and not the ones I have not. Maybe I misunderstood your idea; but what you use in a language is entirely down to your problem. Do you read from a file, or define the data in code? When doing a FSM it would be quite nice to use Goto's, but you may wish to model it as a while loop with a switch statement instead.

(My emphasis.) This condition is incorrect, and applies a very narrowly constrained definition to modelling. Modelling does not imply direct copying of features, code, or anything else for that matter; it implies the conformance to a displayed standard, technique or process.

Quote:

Second of all, if you want to be technical, a C++ program stripped of any of the features that distinguish C++ from C is be definition a C program, as well as a C++ program, and also an Objective C and C99 program for that matter if you want to be pedantic about it.

OK. Now the question is again in a world where C does not exist, does code fitting such a description constitute as good C++ code?

Not in my opinion.

Quote:

If yes, then do you say C++ code must be completely OO based? With/without structs?

No, and I can't say I've said that at any point.

Quote:

To add a perspective to the argument, consider another language completely, that has features that C++ has and your answer may be less biased to the fact that C exists.

How about Visual BASIC? VB has a goto statement, but it also has a while loop feature. If a programmer uses a goto statement where they could have used a while loop, I consider it to be bad VB code.

Quote:

Explain your irony?

You told me that my argument was out of scope, then proceeded to explain how I had just said something that had no discernable connection to what I had just said, and you had even quoted. That is ironic.

Dan.

My comment about C++/Java is mostly geared to what you are saying in regards to using goto's loops and that quote fitted it. But you still said at it at some point so it's more being ingnorant than finding irony :-\ Out of scope, in my opinion, is comparing the use, and non-use of classes, to the use of goto's and absolute addresses. And is simply out of scope. Or maybe calling it out of scale would be better.

Quote:

If yes, then do you say C++ code must be completely OO based? With/without structs?

No, and I can't say I've said that at any point.

Never said you had. But your original argument is that if you can't distinguish a C++ code from C code then it is bad C++ code and should not be called C++ code. If that statement is correct then code must contain elements of C++, which are not in C to be considered C++. If so then code must be OO based, or using other features that C can not.

Also if you agree with the first question, then at least the idea behind the second question must be in some part true. As those features (amongst others) distinguish C from C++.

Quote:

How about Visual BASIC? VB has a goto statement, but it also has a while loop feature. If a programmer uses a goto statement where they could have used a while loop, I consider it to be bad VB code.

My question was geared at the features C++ has that C does not. And was geared that way because most features that C has are very basic features, and can be duplicated in assembler using macros (which is where I believe scale comes into play).

The comparison of loops-to-goto's does not compare to structs-to-classes, in my opinion.

Maybe if we stop trying to prove ourselves right we may get somewhere. We probably just have a bad understanding, through poor communication of the boundaries or full meaning of each others ideas.

A lot of what Dan's saying about loops/goto's make complete sense, and we can all agree with/understand those opinions. But with them being used as arguments, this discussion is running slower than wheelchairs over gravel.

There's no need to take hostility to anybody who does not completely agree with what you are saying. And where someone says they agree with some of your premises but not your idea of its implications; maybe your implication is a little flawed or needs a different approach to make sense. I.E. Bible is ancient (agreed), has many proven facts near impossible to have been known at that time (agreed) therefore God Exists (not agreed). Obviously yours is not so flawed, but where we are disagreeing seems to be at that point.

keldon wrote:

Never said you had. But your original argument is that if you can't distinguish a C++ code from C code then it is bad C++ code and should not be called C++ code.

No, my original argument was that programming in C++ tends to make you think and program in a certain way that coding in plain C does not.

Quote:

If that statement is correct then code must contain elements of C++, which are not in C to be considered C++. If so then code must be OO based, or using other features that C can not.

FWIW, this is close to something I would be in agreement with but not quite. I would not say that plain C code cannot be considered C++ code, but that less information is gained by labelling it as C++ code than if it's labelled C code. For that reason, I find C to be a much more meaningful label for it.

Edit: I believe this common-sense approach is in agreement with the rest of the world, since people don't label their programs as C++ programs if they only use C features in it, the same way they don't label them as Objective C programs, etc.

Quote:

How about Visual BASIC? VB has a goto statement, but it also has a while loop feature. If a programmer uses a goto statement where they could have used a while loop, I consider it to be bad VB code.

My question was geared at the features C++ has that C does not. And was geared that way because most features that C has are very basic features, and can be duplicated in assembler using macros (which is where I believe scale comes into play).

The comparison of loops-to-goto's does not compare to structs-to-classes, in my opinion.

They are apples and apples. The language provides a feature to streamline the process of a simpler or more archaic language feature.

Even what I said about modes of thinking is true in the comparison. Using while loops instead of gotos causes you to think differently when designing. I remember when I was a kid programming in oldschool line-number BASIC that didn't have a "while" construct. I approached the concepts of branching and looping from a different mindset I typically do when coding in C today. I'm not saying it's better or worse, but I believe I'm a better and more versatile programmer for my awareness of the difference.

Dan.

I see your point more; but having said that what if those features of C++ were not wanted, and were in fact worse to use? By definition it's a C program, but does that make it bad C++. Wouldn't it be worse C++ code be if we forced its features when not needed? This is why I remove C from the picture when thinking of it. Because with C we can still choose not to use C++ when its extra features are not needed; but without the concept of C what do you say then? (not a personal just a rhetorical question)

I also do not agree that the newer C++ features will definately make everything easier. It's an alternative that has many benefits, but has its weaknesses too. In fact in a recent project, the problem was because it had to be created completely in OO using Java. Had we taken the procedral approach we could have had it done in 5 minutes FLAT !!!

EDIT: Then again C++ (I believe) was not designed to be as OO oriented as Java is. So its expected style (which Java does have) is not OO, or Structured/Procedral, but instead a possibly of any combination of the two providing it works and is a good solution. (Not sure on this one, but something on similar lines).

keldon wrote:

I see your point more; but having said that what if those features of C++ were not wanted, and were in fact worse to use? By definition it's a C program, but does that make it bad C++. Wouldn't it be worse C++ code be if we forced its features when not needed?

How many angels can fit on the head of a pin? I think you already realize that this line of questioning isn't very productive. C++ doesn't exist in a bubble; it evolved out of a language currently still in heavy use, and what's more was conceived under the premise of being an extended feature set to the original C. There may exist C code that works as B code, but it isn't practical to consider it B code because no one uses B, no one would ever think to call it B code, and there aren't other B offshoots that it could also be mistaken as.

Quote:

I also do not agree that the newer C++ features will definately make everything easier.

Please; I never said anything remotely close to this or even implied it. You really need to be more accurate because at this point you are arguing with a fictional opponent.

Dan.

poslundc wrote:

Please; I never said anything remotely close to this or even implied it. You really need to be more accurate because at this point you are arguing with a fictional opponent.

Dan.

Never said you did; and the problem we're having is you're seeing me as an opponent. Why? Because I did not see correctness in your logic? Can you not disagree with someone but not be opposed to them? If not team work is an impossible task. And is it not possible for us both to be wrong in some or all places?

Would I be correct in saying you see C++ only as C with extended features? I am not concerned with the history of C/C++ to be honest. Tell that to the grandchildren, or the discovery channel; it would have far more impact there than it would on your code.

It makes more sense that a program compatible with C is not C++, than it is bad C++. In fact if it was not C++ to begin with then it can not be C++ :D

Quote:

If the code is worse off, then what are we arguing about? That was my basic premise: is that the code when considered in a C++ environment is worse than when considered in a C environment (where the C++ features are irrelevant and moot).

It's not considering it in a C++ environment that makes the code worse. It's just worse, period.

Quote:

Yes, but I consider those two (that I hilighted) to be essentially synonymous...

First it's "world of difference", then it's "essentially synonymous"?

Quote:

You seem to say that it only matters if others expect a certain style of C++ coding from you, but then by same token I say if that's true, then it should also hold that using gotos instead of while loops in plain C (or C++ for that matter) isn't poor coding because they are functionally equivalent.

Gotos are not equivalent to while loops. I don't know why you keep going back to program behavior rather than accepting my broad definition of "requirements".

Quote:

It's fine if you want to put it that way, but that has less to do with my original point about the restrictive nature of C++, which is that when you use the OO features (which most people do by default when programming C++) in shoehorns you into a certain style of both thinking and coding.

Actually, you didn't say "most people" -- you said you feel restricted. If you go back to my original reply, you'll see that I found it an interesting psychological issue that you feel restricted to using OO features, even though you don't seem to like OO. I still think it's pretty weird, but I'm pretty much over it.

I still think you should stop telling people to be free of paradigms, if you are controlled by your tools and not the other way around.

keldon wrote:

poslundc wrote:

Please; I never said anything remotely close to this or even implied it. You really need to be more accurate because at this point you are arguing with a fictional opponent.

Never said you did; and the problem we're having is you're seeing me as an opponent. Why? Because I did not see correctness in your logic? Can you not disagree with someone but not be opposed to them? If not team work is an impossible task. And is it not possible for us both to be wrong in some or all places?

(My emphasis.) Your words were: "I also do not agree that the newer C++ features will definately make everything easier." Since you are not agreeing with someone, it implies someone has made a statement to that effect for the disagreement to occur. Since you have been responding exclusively to me for the past half-dozen posts or so, and the preceding paragraph was a response to me as well, I can only assume that that someone is me.

I don't really care if you're my opponent or not. If you challenge my conclusions - which you have repeatedly in this thread - I'm going to respond as needed. There's nothing remotely wrong with you challenging them, of course, but don't be surprised by my defending them either. I'm not arguing for the sake of arguing; in fact I only appeared in this thread in the first place because I was (kind of) called out. I've already done C vs. C++ to death.

Quote:

Would I be correct in saying you see C++ only as C with extended features?

No.

Quote:

It makes more sense that a program compatible with C is not C++, than it is bad C++. In fact if it was not C++ to begin with then it can not be C++ :D

I'd be lying if I said I understood that chain of reasoning... :P

Dan.

sajiimori wrote:

Quote:

If the code is worse off, then what are we arguing about? That was my basic premise: is that the code when considered in a C++ environment is worse than when considered in a C environment (where the C++ features are irrelevant and moot).

It's not considering it in a C++ environment that makes the code worse. It's just worse, period.

But such code is considered to be well-written C code, isn't it? Or is all C code bad code?

Quote:

Yes, but I consider those two (that I hilighted) to be essentially synonymous...

First it's "world of difference", then it's "essentially synonymous"?

Um, I said it was a world of difference between using C++ and having it in a selection of tools. Then I said that I find programming in C++ and applying C++ features that aren't available in C to be essentially synonymous.

How is this to be construed as flip-flopping, exactly?

Quote:

Gotos are not equivalent to while loops. I don't know why you keep going back to program behavior rather than accepting my broad definition of "requirements".

While loops can be simulated with ifs and gotos the same way C++ features can be simulated with C features. The only reason I keep returning to this point is to show that just because two styles of coding are functionally equivalent doesn't mean they both amount to well-written code.

You keep saying that it only matters in terms of what others expect from you, but I don't think that's necessarily the case: there are certain expectations inherently built into the language in addition to those expected by your peers.

Quote:

Actually, you didn't say "most people" -- you said you feel restricted.

Mainly because you brought me up as a case study. :P

Quote:

I still think you should stop telling people to be free of paradigms, if you are controlled by your tools and not the other way around.

I would if I felt I was the exception and not the rule. And until you provide me with more compelling evidence that isn't the case, I'll keep my own counsel on what I tell people, thank you very much.

Dan.

poslundc wrote:

While loops can be simulated with ifs and gotos the same way C++ features can be simulated with C features. The only reason I keep returning to this point is to show that just because two styles of coding are functionally equivalent doesn't mean they both amount to well-written code.

Ah, I think I get what you're saying. Consider, for example, C code written that simulates some OO techniques:

Code:

typedef struct tagSOMESTRUCT {
/* various member variables here */
} somestruct_t;

void somestruct_init( somestruct_t *pSomestruct )
{
}

int somestruct_read( somestruct_t *pSomestruct, /* some parameters */ )
{
}

int somestruct_write( somestruct_t *pSomestruct, /* some parameters */ )
{
}

int somestruct_update( somestruct_t *pSomestruct, /* some parameters */ )
{
}

The above might be good in the C sense but poor C++ because in C++ there are better ways to do the above (namely, classes). Of course, the above is an incredibly contrived example, but I think you get the point.

poslundc wrote:

Quote:

It makes more sense that a program compatible with C is not C++, than it is bad C++. In fact if it was not C++ to begin with then it can not be C++ :D

I'd be lying if I said I understood that chain of reasoning... :P

Dan.

It's no surprise; the grammar could be read in many ways. I just read it wrong myself until I began to try to retype it to make it make sense.

Okay, let me have a try at rewriting it.

It makes much more sense saying a C program is not C++ than it does saying it is bad C++. But if it was not C++ to begin with, then it could not be bad C++ :D (I missed out bad the first time around).

Quote:

Since you are not agreeing with someone, it implies someone has made a statement to that effect for the disagreement to occur

It is possible to declare a negated premise.

Quote:

But such code is considered to be well-written C code, isn't it? Or is all C code bad code?

All C code that could be improved by using C++ features is worse than it could be, assuming availability of a suitable C++ implementation. So it is bad (or at least worse), not relative to the language, but relative to better code.

Quote:

Um, I said it was a world of difference between using C++ and having it in a selection of tools. Then I said that I find programming in C++ and applying C++ features that aren't available in C to be essentially synonymous.

You're right, my bad. I just got confused by "Yes, but I consider those two (that I hilighted) to be essentially synonymous..." because you technically can't have it both ways. I understand now though.

Quote:

The only reason I keep returning to this point is to show that just because two styles of coding are functionally equivalent doesn't mean they both amount to well-written code.

Great, but I don't know where I ever disagreed with that. I've never brought up functional equivalence.

Quote:

...there are certain expectations inherently built into the language...

And if I say that this is logically impossible considering that C++ is a superset of C, you'll say "oh sure, that's technically true, but why don't you look at the real world?" And what do you mean by that? Expectations.

Quote:

I would if I felt I was the exception and not the rule.

Alright, so you're warning people to not use C++ because most people (including you) get sucked into the OO vortex. I guess I was just confused because you used the term "free", when that view is such the opposite of freedom.

sajiimori wrote:

Quote:

But such code is considered to be well-written C code, isn't it? Or is all C code bad code?

All C code that could be improved by using C++ features is worse than it could be, assuming availability of a suitable C++ implementation. So it is bad (or at least worse), not relative to the language, but relative to better code.

Would you then say that all C code could be made positively better by using C++ features wherever the two are functionally equivalent?

Quote:

The only reason I keep returning to this point is to show that just because two styles of coding are functionally equivalent doesn't mean they both amount to well-written code.

Great, but I don't know where I ever disagreed with that. I've never brought up functional equivalence.

It stems from the issue of whether good C code can be bad C++ code. It may be legacy at this point.

Quote:

...there are certain expectations inherently built into the language...

And if I say that this is logically impossible considering that C++ is a superset of C, you'll say "oh sure, that's technically true, but why don't you look at the real world?" And what do you mean by that? Expectations.

I also mean that the extensions to C that were implemented for C++ were designed to make it much easier (and therefore desireable) to do certain things, which has a consequence of making it less easy (and therefore less desireable) to do other things that previously required a comparable level of effort. There are most definitely politics behind the structure of a language!

Quote:

I would if I felt I was the exception and not the rule.

Alright, so you're warning people to not use C++ because most people (including you) get sucked into the OO vortex. I guess I was just confused because you used the term "free", when that view is such the opposite of freedom.

You're gonna have to do better than that. Show me the quote where I've said anything remotely like this in this or any other recent thread.

All I ever do is advocate the smart selection of the correct tool for the problem, and not to assume that OO is a panacea that is best equipped for solving every problem out there.

Dan.

keldon wrote:

It makes much more sense saying a C program is not C++ than it does saying it is bad C++. But if it was not C++ to begin with, then it could not be bad C++ :D (I missed out bad the first time around).

I prefer not to call vanilla-C programs C++ programs; this has been one of my themes in the thread. This is why I initially made the point that if you're going to look at a C program and think of it a C++ program it's probably going to make for a pretty lousy one.

Quote:

It is possible to declare a negated premise.

OK; it didn't come across as that.

Dan.

Quote:

Would you then say that all C code could be made positively better by using C++ features wherever the two are functionally equivalent?

No, but intuitively I'd say most can, just because C++ adds a lot of features and chances are at least one of them can make even a slight improvement in at least one part of the program.

Quote:

I also mean that the extensions to C that were implemented for C++ were designed to make it much easier (and therefore desireable) to do certain things, which has a consequence of making it less easy (and therefore less desireable) to do other things that previously required a comparable level of effort.

That is flat-out false. Anything that was easy in C is just as easy in C++, insofar as superset yada yada.

Quote:

You're gonna have to do better than that. Show me the quote where I've said anything remotely like this in this or any other recent thread.

We've essentially established that you believe that it is the application of C++ features that is restricting, not in the technical sense but in the real-world sense that most people become restricted, including yourself.

So by telling people to stay free, you are telling them to not use C++. You can't just warn them not to get sucked in by OO, because you believe that using C++ implies that they will be, if they are like you and most other people.

sajiimori wrote:

Quote:

I also mean that the extensions to C that were implemented for C++ were designed to make it much easier (and therefore desireable) to do certain things, which has a consequence of making it less easy (and therefore less desireable) to do other things that previously required a comparable level of effort.

That is flat-out false. Anything that was easy in C is just as easy in C++, insofar as superset yada yada.

No, it isn't false. And something doesn't have to be easy in C, it just needs to be easier in C++ to alter the dynamic of the language. If you don't believe this then we'll have to disagree on it because I'm sick of trying to explain it.

[quote\

Quote:

You're gonna have to do better than that. Show me the quote where I've said anything remotely like this in this or any other recent thread.

We've essentially established that you believe that it is the application of C++ features that is restricting, not in the technical sense but in the real-world sense that most people become restricted, including yourself.[/quote]

Yes.

Quote:

So by telling people to stay free, you are telling them to not use C++.

No. I am only telling them to stay free of the assumption that the paradigm is correct.

Quote:

You can't just warn them not to get sucked in by OO, because you believe that using C++ implies that they will be, if they are like you and most other people.

I did not say that using C++ implies they'll get sucked in by OO. Please either produce a quote that backs this up or drop it.

Dan.

Quote:

No, it isn't false.

Example of something easy in C that becomes harder in C++? And I don't want any of this "not technically right but real world" stuff where the C++ version absolutely has to use C++-only features. And no technicalities regarding C++ not being an exact superset.

Quote:

And something doesn't have to be easy in C, it just needs to be easier in C++ to alter the dynamic of the language.

It alters the best available solution sometimes, because more options are available. Anything else is a matter of your tool-makes-you-do-bad-things problem, which I don't have, personally. I'm willing to grant that most people might have that problem.

Quote:

I am only telling them to stay free of the assumption that the paradigm is correct.

You can't say that without either telling them not to use C++, or being a hypocrite because you say C++ keeps you from being free of the paradigm.

Quote:

I did not say that using C++ implies they'll get sucked in by OO.

By "sucked in" I mean brainlessly using OO, and you've consistently stated that using C++ tends to do that to you and to most other people. That's what you've been saying from the start, isn't it? Sorry, no time for quote digging now.

sajiimori wrote:

Quote:

No, it isn't false.

Example of something easy in C that becomes harder in C++?

That's not what I said. I said: "the extensions to C that were implemented for C++ were designed to make it much easier (and therefore desireable) to do certain things, which has a consequence of making it less easy (and therefore less desireable) to do other things that previously required a comparable level of effort".

This is talking about choosing between two alternatives in either language, not choosing between doing it in one language or the other.

An example would be: a function table used within a struct (a C implementation of virtual functions) is about as much effort to code as, say, a dispatch function that examines a field within the struct and chooses which function to call based on it, which would essentially accomplish the same thing.

In C++, however, it's much easier and cleaner to create virtual functions than it is to set up a custom struct and dispatch routine. So the language favours one technique over another.

Quote:

And something doesn't have to be easy in C, it just needs to be easier in C++ to alter the dynamic of the language.

It alters the best available solution sometimes, because more options are available. Anything else is a matter of your tool-makes-you-do-bad-things problem, which I don't have, personally. I'm willing to grant that most people might have that problem.

(My emphasis.) You have a way of colouring everything I say as a negative influence. The language is biased, not "bad". It influences you to approach problems a certain way. What's bad is not being aware of that influence, and not making sure you're using the right tool for the right problem. I think I've probably said that 100 times now, but you still insist that I say it makes you do bad things. It doesn't make you do BAD things. It just makes you do THINGS. That's what I find restricting.

Quote:

I am only telling them to stay free of the assumption that the paradigm is correct.

You can't say that without either telling them not to use C++, or being a hypocrite because you say C++ keeps you from being free of the paradigm.

Sure I can. The solution is to use the paradigm judiciously, where it fits the problem.

Quote:

I did not say that using C++ implies they'll get sucked in by OO.

By "sucked in" I mean brainlessly using OO, and you've consistently stated that using C++ tends to do that to you and to most other people. That's what you've been saying from the start, isn't it?

No. I've been saying that it favours the path of OO. Whether it's done brainlessly or not is up to the programmer.

Dan.

Quote:

That's not what I said.

It's hard to parse what you said, but if you aren't saying that making tables of function pointers becomes "less easy" (not just less desirable) in C++ then I'll drop it.

Quote:

You have a way of colouring everything I say as a negative influence. The language is biased, not "bad". It influences you to approach problems a certain way. What's bad is not being aware of that influence, and not making sure you're using the right tool for the right problem. I think I've probably said that 100 times now, but you still insist that I say it makes you do bad things. It doesn't make you do BAD things. It just makes you do THINGS. That's what I find restricting.

I know, that's the heart of the matter. But remember, the perfect programmer will be able to choose the right features to solve each problem, and he won't be influenced by any implied methodology of the language.

If your language makes you do things, then you are further from that ideal. You'll be PUI (programming under the influence) and your judgement will be impaired by a percieved inherent methodology. That's bad! There will inevitably be cases where you choose the wrong thing due to the influence.

Quote:

The solution is to use the paradigm judiciously, where it fits the problem.

By saying that the tool affects you, you are also saying that you can't apply it judiciously. If you were free to use your best judgement, you wouldn't feel restricted, right?

Quote:

The solution is to use the paradigm judiciously, where it fits the problem.

Well, it's a little more brainless with every bit of control the tool gains over your thought process, until you are (dum dum duhhhh) a slave to the system! ;)

sajiimori wrote:

I know, that's the heart of the matter. But remember, the perfect programmer will be able to choose the right features to solve each problem, and he won't be influenced by any implied methodology of the language.

These are the words of a technological determinist. I imagine you generally view tools as being perfectly neutral, and their users as the only factor that determines how they are employed. (I'm not sure, but I think you may have even said something to that effect in this thread.) You certainly are not alone in this philosophy, but it is not one that I ascribe to. I am more of a social constructivist, and do not readily believe in the separation of a technology and its application. The differences between and reasonings behind these philosophies is something far more complicated than I imagine either of us feels like getting into at the moment, so I'm prepared to agree to disagree on this matter if you are.

Quote:

The solution is to use the paradigm judiciously, where it fits the problem.

By saying that the tool affects you, you are also saying that you can't apply it judiciously. If you were free to use your best judgement, you wouldn't feel restricted, right?

You can exercise good judgement in the selection of the tool you use. You can't prevent the tool you use from affecting your technique. Again, it's probably not worth getting into... see above.

Dan.

Quote:

The differences between and reasonings behind these philosophies is something far more complicated than I imagine either of us feels like getting into at the moment, so I'm prepared to agree to disagree on this matter if you are.

Yeah.

I'm sure people really are affected by their tools. One should strive to escape that, in order to work towards perfection.

I must be doing ok in that regard, because my coding style is quite different than any of my coworkers, and that of the C community at large. The fact that I am using C doesn't prevent me from applying the techniques I've picked up from C++, Lisp, Lua, and Haskell literature, insofar as C will allow me to do so.

Well, happy coding. ^_^

sajiimori wrote:

Example of something easy in C that becomes harder in C++?

Never thought I'd be posting something meaningful in a C vs. C++ flamewar, but C99 still has a few incompatibilities vs. C++98 that may either make things harder to express in C++98 or affect interoperability:

C99 has arithmetic on 64-bit integers. Does C++98 have 'long long' or any of the other new types that <stdint.h> of C99 introduced?
C99 programs may choose not to #include <iso646.h> and <stdbool.h>, but C++ treats their constants as well as many other words as builtin keywords, possibly breaking e.g. some virtual machines that use 'and' and friends as symbols.
Does 'clog' compute logarithms or write to standard error output? C++ makes this a bit ambiguous.
Complex numbers are a template class in C++98 but a builtin in C99. How does one pass complex numbers between C and C++?
Unlike C++98, C99 supports variable length arrays on the stack. C++ always puts them on the heap, which can lead to fragmentation.
It's harder to predict the size of an enumeration constant in C++, making it harder to line up precomputed data with a struct layout.
C++ does not allow initializing a char array to a string literal without a nul terminator.
Many environments' runtime libraries have only C bindings, making problems with C++ calling conventions. For instance, specifying a C++ member function as a callback becomes complicated, and the lack of automatic reinterpret_cast<void *> causes problems when people try to use, say, GBFS from a C++ program.

Some features aren't in C++98, but GCC likely may let you use them anyway:

The syntax for compound literals (aka anonymous structs) differs between C99 and C++98; some would claim that C99's is more flexible.
C99's preprocessor allows empty arguments.
C99 supports an indefinite-length array as the last member of a struct.
C99 has hexadecimal floating-point literals.
C99 has the __func__ identifier, which resolves to a string literal containing the name of the current function. Assert macros may find it useful.
C99 has the 'restrict' qualifier for pointers, a hint to the compiler to use dirtier tricks when optimizing array code.
C99 has a syntax for preprocessor macros that take a variable number of arguments.

Or do you consider such differences mere technicalities?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Quote:

Or do you consider such differences mere technicalities?

For the purposes of this discussion (and of most of my actual code), yes. ^_^

Edit:

Quote:

C99 has arithmetic on 64-bit integers. Does C++98 have 'long long' or any of the other new types that <stdint.h> of C99 introduced?

I dunno, but you could always make a class for it and overload the arithmetic operators.

Quote:

C99 programs may choose not to #include <iso646.h> and <stdbool.h>, but C++ treats their constants as well as many other words as builtin keywords, possibly breaking e.g. some virtual machines that use 'and' and friends as symbols.

Same goes for all new C++ keywords, including: class, public, private, protected, new, delete, virtual, explicit, try, throw, catch, template, friend, namespace, operator, and this.

Quote:

Does 'clog' compute logarithms or write to standard error output? C++ makes this a bit ambiguous.

Until you actually read your docs.

Quote:

Complex numbers are a template class in C++98 but a builtin in C99. How does one pass complex numbers between C and C++?

By writing converters? In C++ you can even make the conversion automatic.

Quote:

Unlike C++98, C99 supports variable length arrays on the stack. C++ always puts them on the heap, which can lead to fragmentation.

I didn't think C++ ever automatically put anything on the heap. Or are you talking about generic containers like vector?

Quote:

It's harder to predict the size of an enumeration constant in C++, making it harder to line up precomputed data with a struct layout.

sizeof() should work fine, and it's a compile-time constant. Worst-case scenario is you cast an int to the enum type. Small price to pay for typesafe enums.

Quote:

C++ does not allow initializing a char array to a string literal without a nul terminator.

I thought string literals always had null terminators...? I'm not entirely caught up on C99. In any case, I don't imagine I'm gonna be typing in a significant amount of raw binary data by hand any time soon. It would be a little tedious.

Quote:

Many environments' runtime libraries have only C bindings, making problems with C++ calling conventions.

extern "C" and wrapper classes do the trick nicely. I'd rather not have all those void pointers floating about anyway -- it's better that they stay in the low-level libraries. The higher level you get, the less likely you are to be thinking in terms of arbitrary memory addresses.

sajiimori wrote:

Quote:

C99 has arithmetic on 64-bit integers. Does C++98 have 'long long' or any of the other new types that <stdint.h> of C99 introduced?

I dunno, but you could always make a class for it and overload the arithmetic operators.

And how the heck do you expect the compiler to optimize that? Processors have carry flags used for adding multiword integers (such as a 64-bit type on a 32-bit CPU), but C gives you no access to the carry flag. And how do you expect it to infer use of ARM7's 'smull' or 'umull' instructions?

Quote:

Unlike C++98, C99 supports variable length arrays on the stack. C++ always puts them on the heap, which can lead to fragmentation.

I didn't think C++ ever automatically put anything on the heap. Or are you talking about generic containers like vector?

The only variable-length arrays in C++ are vector and new[], both of which go to the heap. C++ doesn't have auto types of variable size.

Quote:

C++ does not allow initializing a char array to a string literal without a nul terminator.

I thought string literals always had null terminators...?

The following code works in C but not C++:

Code:

char codec_type[4] = "divx";

In C++ you have to do this, which proves "a little tedious" after a few tries:

Code:

char codec_type[4] = {'d','i','v','x'};

Quote:

extern "C" and wrapper classes do the trick nicely.

Doesn't adding a wrapper class for each datatype stored in a GBFS file bloat your code, which becomes important if you have to fit code and data into 192 KB (size of EWRAM minus some space for a heap)?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Quote:

And how the heck do you expect the compiler to optimize that?

I dunno. I wasn't really thinking about it. If I needed some really fast 64 bit code, I imagine I'd write it by hand. BTW, does GCC use those special ARM instructions when using "long long"?

Quote:

In C++ you have to do this, which proves "a little tedious" after a few tries:

Right, I was implying that if I had a significant amount of raw binary data to enter into arrays, I'd probably autogenerate it anyway.

Quote:

Doesn't adding a wrapper class for each datatype stored in a GBFS file bloat your code, which becomes important if you have to fit code and data into 192 KB (size of EWRAM minus some space for a heap)?

You mean like for multiboot? Well, you could inline everything if you want... but discussing it further is not really of interest at the moment.

gbadev.org forum archive

C/C++ > learning C/C++

#28389 - ThUg4LiFe - Sat Oct 30, 2004 6:20 pm

#28391 - sajiimori - Sat Oct 30, 2004 6:26 pm

#28392 - ThUg4LiFe - Sat Oct 30, 2004 6:34 pm

#28393 - sajiimori - Sat Oct 30, 2004 6:41 pm

#28394 - ThUg4LiFe - Sat Oct 30, 2004 6:44 pm

#28402 - Krakken - Sun Oct 31, 2004 1:16 am

#28403 - sajiimori - Sun Oct 31, 2004 1:22 am

#28408 - expos1994 - Sun Oct 31, 2004 2:41 am

#28411 - Krakken - Sun Oct 31, 2004 3:17 am

#28413 - nmcconnell - Sun Oct 31, 2004 3:42 am

#28414 - sajiimori - Sun Oct 31, 2004 4:05 am

#28418 - Abscissa - Sun Oct 31, 2004 4:54 am

#28421 - Krakken - Sun Oct 31, 2004 5:37 am

#28431 - allenu - Sun Oct 31, 2004 9:35 am

#28434 - Fatnickc - Sun Oct 31, 2004 9:49 am

#28441 - ThUg4LiFe - Sun Oct 31, 2004 12:12 pm

#28442 - Lord Graga - Sun Oct 31, 2004 12:18 pm

#28447 - sajiimori - Sun Oct 31, 2004 7:44 pm

#28453 - allenu - Sun Oct 31, 2004 9:05 pm

#28454 - sajiimori - Sun Oct 31, 2004 9:57 pm

#28458 - AlexL - Sun Oct 31, 2004 10:52 pm

#28461 - poslundc - Sun Oct 31, 2004 11:21 pm

#28462 - sajiimori - Sun Oct 31, 2004 11:33 pm

#28468 - poslundc - Sun Oct 31, 2004 11:57 pm

#28470 - sajiimori - Mon Nov 01, 2004 12:33 am

#28473 - poslundc - Mon Nov 01, 2004 12:58 am

#28476 - sajiimori - Mon Nov 01, 2004 1:18 am

#28478 - allenu - Mon Nov 01, 2004 1:37 am

#28479 - poslundc - Mon Nov 01, 2004 1:45 am

#28480 - sajiimori - Mon Nov 01, 2004 2:42 am

#28482 - poslundc - Mon Nov 01, 2004 3:30 am

#28483 - keldon - Mon Nov 01, 2004 3:40 am

#28484 - sajiimori - Mon Nov 01, 2004 4:58 am

#28492 - poslundc - Mon Nov 01, 2004 3:03 pm

#28497 - sajiimori - Mon Nov 01, 2004 7:28 pm

#28502 - poslundc - Mon Nov 01, 2004 8:03 pm

#28503 - tepples - Mon Nov 01, 2004 8:11 pm

#28505 - sajiimori - Mon Nov 01, 2004 9:31 pm

#28508 - poslundc - Mon Nov 01, 2004 10:13 pm

#28510 - keldon - Mon Nov 01, 2004 11:59 pm

#28511 - poslundc - Tue Nov 02, 2004 12:18 am

#28512 - sajiimori - Tue Nov 02, 2004 12:30 am

#28513 - keldon - Tue Nov 02, 2004 12:37 am

#28514 - allenu - Tue Nov 02, 2004 12:53 am

#28515 - sajiimori - Tue Nov 02, 2004 1:02 am

#28516 - allenu - Tue Nov 02, 2004 1:09 am

#28517 - sajiimori - Tue Nov 02, 2004 1:29 am

#28518 - sajiimori - Tue Nov 02, 2004 1:57 am

#28519 - poslundc - Tue Nov 02, 2004 2:00 am

#28520 - sajiimori - Tue Nov 02, 2004 2:09 am

#28521 - poslundc - Tue Nov 02, 2004 2:12 am

#28522 - sajiimori - Tue Nov 02, 2004 2:34 am

#28523 - poslundc - Tue Nov 02, 2004 3:06 am

#28524 - allenu - Tue Nov 02, 2004 3:54 am

#28525 - sajiimori - Tue Nov 02, 2004 4:57 am

#28536 - poslundc - Tue Nov 02, 2004 2:16 pm

#28541 - jma - Tue Nov 02, 2004 5:21 pm

#28543 - poslundc - Tue Nov 02, 2004 5:45 pm

#28548 - jma - Tue Nov 02, 2004 6:24 pm

#28551 - ThUg4LiFe - Tue Nov 02, 2004 7:13 pm

#28552 - poslundc - Tue Nov 02, 2004 7:13 pm

#28553 - ThUg4LiFe - Tue Nov 02, 2004 7:25 pm

#28555 - allenu - Tue Nov 02, 2004 8:01 pm

#28556 - sajiimori - Tue Nov 02, 2004 8:41 pm

#28559 - ThUg4LiFe - Tue Nov 02, 2004 9:21 pm

#28560 - allenu - Tue Nov 02, 2004 9:24 pm

#28562 - poslundc - Tue Nov 02, 2004 9:36 pm

#28563 - poslundc - Tue Nov 02, 2004 9:39 pm

#28565 - ThUg4LiFe - Tue Nov 02, 2004 10:06 pm

#28566 - sajiimori - Tue Nov 02, 2004 10:07 pm

#28567 - nmcconnell - Tue Nov 02, 2004 10:08 pm

#28569 - allenu - Tue Nov 02, 2004 10:15 pm

#28570 - poslundc - Tue Nov 02, 2004 10:36 pm

#28571 - sajiimori - Tue Nov 02, 2004 10:38 pm

#28573 - poslundc - Tue Nov 02, 2004 10:43 pm

#28576 - sajiimori - Tue Nov 02, 2004 11:04 pm

#28577 - allenu - Tue Nov 02, 2004 11:10 pm

#28578 - sajiimori - Tue Nov 02, 2004 11:17 pm