is C appropriate for intro to computers?

This comment came up in another thread:

Quote:

---

Originally Posted by lugnut

It just seems there ought to be a simpler way to do pointer arithmetic. Most of this is just trying to beat the compiler.

---

That's so true. I was thinking about posting a little rant in this General section about what I think of the current computer courses, based on the questions and issues people appear to have...

The sentiment above by a student illustrates this completely. Are students to learn idiosyncrasies of C and get bogged down in it, apparently, or would they be better served to learn algorithms, meticulousness and attention to detail, logic, deductive logic, systematic approaches, and a more generic approach to solving problems using computers? Perhaps C isn't the best tool for introducing programming.

I'm an oldgeezer/oldtimer.... I was taught programming using BASIC (which was designed to be a teaching tool, coincidentally). In high school we learned how to iterate Pi using series, solve area and volume problems (early methods equivalent to integrals). For example: what's the most efficient ratio of a cylinder to minimize surface area for a given volume - i.e. how would you design a pop can if material costs were all the same for sides or top.

Language idiosyncrasies were few. If any. Simple IF, PRINT, FOR/NEXT. I don't recall anyone needing remedial help with syntax issues. More likely they were asking about why the results were off... or why one had to convert from degrees to radians.

C doesn't seem appropriate because too many "pointer" issues, memory allocation, integer vs.. float, plus bracket and indenting distractions miss the point of making computer literate people entirely.

Maybe it's because we used to call it "computer science" in the mid 70s. Where's the science nowadays in tracking down some segmentation fault or core dump?

That's my opinion.

I would agree that pointer issues and memory allocation don't belong in a first programming class. I would also doubt that there are many first programming classes out there that get into pointers and memory allocation (except for perhaps learning scanf, but that's not pointers so much as operator&). The students we've seen here (and that we've all seen in real life too, I would guess) who can't process order-of-operations for a formula are going to be equally sunk in BASIC as anything else. (Or those who can't find the big box of source code in their textbook. Or those who can't grasp the flow of a program from top to bottom. Or ... you get the idea.) Would VB be a better learning language than C? I don't know -- I don't really know VB.

Integer vs. floating-point seems like a pretty important distinction to make, if they're going to use a typed programming language. It helps to get used to limited-precision in floating-point too (I know some CIS faculty here who get really upset at Excel when they type in 0.93 and it ends up being 0.9299999999999999999997).

(And to be honest, I don't know that that was a student posting -- dealing with data headers and going back and forth with EBCDIC doesn't sound like a typical academic project.)

Well, the point is that you adapt to the language and not the other way around. This is an issue that will follow throughout their entire careers. They will have to learn the odds and ends of every language they end up using. And no language is without these. So they might be better off understanding programming is not what you see on the movies. This is also, after all, part of the tutorship you should go through during the learning days. Master Yoda would expect no less. And there should never be a reason to make learning how to program any easier of a task. It's my take the wold needs better programmers... like in, real quick before it blows up.

Instead of fighting against the language rules, the students are better off understanding them and ripping the benefits. On the case of pointers, these are fundamental to a correct understanding of C. And what is at stake is learning how to program, which entails problems. Programming is 99% about frustration. Meanwhile it's true that algorithmic is fundamental, but I'm sure that's covered somewhere else and is no less true that pointers teach of memory allocation, deallocation, code correctness and programming languages pitfalls. A correct and sound understanding of pointers and all the little delicacies around them is, my friend, a big huge gun you are carrying there blazing away at the competition. You might even get laid!

Seriously though, I find pointers fascinating. Once the student gets to now them a little better, they'll immediately see the power and will not only forgive them, but understand why the complexity. Because power doesn't come cheap. And BASIC... is cheap ;)

I don't know if there are many schools that teach C as the very first language for a student? These days I'd imagine Java or VB would be a lot more popular.

The first language I taught myself is BASIC, and I think that was probably a good thing since I learned about using concepts like IF, FOR & WHILE as well as Functions. Then later when I taught myself C/C++ it wasn't completely alien to me and I could focus more attention to new concepts like pointers.

We started with several weeks of just learning what base-2 system is all about. Logic - tables, simple boolean, some rules... then gates (AND, OR), designing adders, comparators, shift registers, counters... all on paper. Then we migrated to the school's computer using BASIC. I think those fundamentals may not be taught today. Else we wouldn't be seeing all those questions about what's binary, and how's all that hex stuff anyways.

Then later on, post secondary, there were classes in a variety of computer languages for that time...

Write an equation parser, factoring & simplifying algebraically, and finally write a program to do derivatives algebraically, in SNOBOL.

Write a simplified airline reservation system in COBOL.

Write a bucket sort algorithm in LISP.

Write some sort of simple game such as Xs and Os in PL1.

Those all seem to me to be pretty sophisticated compared to the "read a movie title and then print it out" stuff I see on the question boards.

In many ways, computer science was more a field of general excitement and exploration a few decades ago. Now we're stuck with a handful of popularized languages, dictated to us because of market momentum and your company's lock-step lemming mentality.

Maybe programming is 99% frustration nowadays. But it didn't used to be. I wouldn't have lasted 30 years in this biz if it had.

It depends on what you want to do. I wouldn't argue that what you learned is bad for embedded systems.
However, for computer software, it's pretty much useless.
Again, if you're into embedded, C is probably a good choice.
If you're into computer software, C is a very bad choice. C++, Java, C#, etc would be better candidates.

I think the focus was more towards an enthusiastic student who says "I wanna get into computers"... so a wide variety of approaches, depth of knowledge (from physical layout of gates to abstract advanced data structures), and several very different languages were thrown at the student.

With those basics he is well equipped to learn any specialized language for whatever tasks. From interfacing hardware and writing low-level machine language drivers to fixing billing systems and diagnosing graphics library bugs.

Today the focus is on teaching a very specific language only. And somehow the student is supposed to glean a "general" computer literacy from that. Is that a bad thing? Maybe not if a future job's requirement fits that knowledge perfectly.

Add it to the list of complaints towards today's programming courses.

Quote:

---

Originally Posted by Elysia

Add it to the list of complaints towards today's programming courses.

---

Well, not in Greece. Here the logic is to learn the way of programming than a specific language. That is good, but it requires you to learn by yourself the details of the language.

If you want to program with OOP then Java and C# are better than C/C++. If you want something without OOP then C is the best. Now, C++ for me has all the features of C and most of the features of Java. In a way if you know C then you could learn C++ for the OOP features and have one language for basic and advance things. From C++ it is really easy to learn Java. The other way around though isn't that simple.
So in a way, if you want to learn EVERYTHING starting from C and moving on is good. If you don't need the features of C then why bother with C/C++?
If you want to understand how the computer works and what is the connection with the programming language then C/C++ are essential.

Quote:

---

Originally Posted by C_ntua

If you want to program with OOP then Java and C# are better than C/C++.

---

Better is subjective.
Java and C# are not necessarily better than C++.

Quote:

---

If you want something without OOP then C is the best.

---

Also subjective.
C isn't quite the world's best language.

It depends on how you see it...

Every now and again we rehash this subject with a few banalities about how impossible it is to teach CS students, software engineers, what have you. I hope everyone finds out what makes their mornings bright and sunshinie again, because I think we're placing an disproportionate amount of responsibility on ourselves, and language X.
https://cboard.cprogramming.com/showthread.php?t=105405
https://cboard.cprogramming.com/showthread.php?t=103387

Not everyone that visits here have the same goal of styling themselves as "programmer": I'm fairly certain that there is some programming involved in engineering degrees, and few engineers write software. I've long supported focusing on your skills in education because that is what will get you hired. I'm not going to shed any tears because I have to help someone with C on my own time.

Is C a good language to start learning to program with? Probably not, but at one point we did because the other ones didn't exist, and there is no perfect language to teach to. But, and this might be the only relative thing in this post, I don't think we make enough use of other choices, like pascal. And likewise, I really don't think schools are teaching C first to CS students, but who knows about other disciplines?

Quote:

---

Originally Posted by Elysia

Also subjective.

---

So is this:

Quote:

---

Originally Posted by Elysia

If you're into computer software, C is a very bad choice.

---

So if someone says it's bad for computer software, then it's objective, if someone says it's good for computer software, it's subjective... :rolleyes:

The only objective answer is - try them out and see which fits you best.

It's all subjective!
I'm simply saying that C is usually not a very good choice for computer software in general. That's not to say you can't or shall not use it. It's up to each and every individual. So long as you know the phrase "use the right tool for the right job."
Besides, it is my individual crusade to rid the world of C :D

Recently, while reviewing reviews of Accelerated C++, I chanced upon an essay that posits that Learning to Program: It Starts with Procedural (warning: PDF file). One of the conclusions of that essay is that as a first programming language, "for those likely to go on with C++ or Java, the choice is C", though such a first course "can avoid those details of the procedural language rendered obsolete by the modern extensions, e.g. C's memory management and stream I-O functions".

The author also argues that "C++, in all its size and complexity, is utterly unsuited to learning beginning programming, but its C-like subset is a practical vehicle, especially for those likely to pursue serious full-time programming".

And do you have any thoughts to add to that? Do you agree with the author?

Quote:

---

Do you agree with the author?

---

Yes, since it is clear that procedural programming is introduced as the first programming paradigm in pretty much any introductory text, whether it uses C, C++, Java, Scheme, etc. I disagree with the conclusion that languages that support other programming paradigms directly should be ruled out as a first programming language, since the author has not established that it is more difficult to teach procedural programming with such languages.

I think for intro to computers, variety is more important than specializing on a particular programming language, or even programming at all. But for intro to programming or programming 101, sure, I think C is fine.

I clearly misinterpreted the initial post. I assumed university level students. In my time there where no programming classes until university and only those who had any prior ad hoc knowledge of programming languages would seek out these courses.

So, I ask exactly where is the problem? Because many programmers today were shaped out of any kind of tutorship and method. Some started out in BASIC (a good part at least those from my generation), but today there's 15 year old kids doing C or C++ that can run circles around my code and yet never touched one line of BASIC. Clearly, there's no issue with pointers in C that stopped these children from teaching themselves.

Pointers in C are no harder than trigonometry in math. And they never force the student to concentrate in tasks non related to programming. On the contrary, they have the real potential of making it very clear to the student the hurdles of the programming task, like achieving code correctness and getting to understand the pitfalls of the programming language as a tool.

What is this we want exactly? A programming pop culture? Everything made easy and prep-packed in a nice and cute manner, and with it breed a generation of incompetent programmers that were never really given a chance to understand what it means to be a programmer? Because after they happily and blissful sign in for a 5 year course at their universities, they will realize they had been lied to.

EDIT: It occurred to me... I'm not defending C or C++ over any other language for the purposes of teaching, or anything like that. For all that matter I would be equally glad they were taught BASIC. I'm solely arguing against this notion that just because a language introduces some form of attrition, it suddenly doesn't make a good tool for learning process. And I'm arguing this ridiculous idea that school should be made easy and fun.

Well, generally there are a lot of opinions about the matter. For me in the end every language based on C is like C with additional features.
A more appropriate question is to say if they should start with C or Haskell (or ML). Or maybe Prolog, since all of the above really use different logic.

>>Besides, it is my individual crusade to rid the world of C

I knew you had something more than just a grudge against C. Almost any chance you get you mention some problem of C, or how much better C++ in in a particular aspect.

Quote:

---

Originally Posted by lruc

>>Besides, it is my individual crusade to rid the world of C

I knew you had something more than just a grudge against C. Almost any chance you get you mention some problem of C, or how much better C++ in in a particular aspect.

---

That's my crusade too. ;)

Quote:

---

Originally Posted by lruc

>>Besides, it is my individual crusade to rid the world of C

I knew you had something more than just a grudge against C. Almost any chance you get you mention some problem of C, or how much better C++ in in a particular aspect.

---

When I get a chance, I do. Otherwise it wouldn't be much of a crusade, would it?
Of course I also disagree that you should learn C before delving into C++ (if you want to learn C++ as a ground).
Since C++ is an extension of C, usually you would learn everything about pointers, memory management and all that while learning C++, making C obsolete. It also avoids the pitfalls in C that should never have existed (implicit function calls being one of the most severe).
Of course, that can be argued, but it's my humble opinion.

>> It also avoids the pitfalls in C that should never have existed (implicit function calls being one
>> of the most severe).

Um, it may be your opinion, but non-main functions are explicitly called. I do believe you are making up problems now. The issue I think you mean is prototypes being implicitly being included, such as for printf, or C assuming functions return int when they're not declared. The first part is caused by the C run-time, which does depend on certain libraries. The second is well reported by the compiler but it's not a bad thing to expect more I suppose. Don't start making up a problem, though.

Quote:

---

Originally Posted by nonoob

I think those fundamentals may not be taught today.

---

I just started an Introduction to Object-Oriented Programming at uni (prerequisite for other comp. sci. courses), and we were taught some fundamentals (base-2, dec to bin conversion, von Neumann arch, etc), but not quite as much as what you listed. I would imagine it varies from school to school.

Quote:

---

Originally Posted by citizen

And likewise, I really don't think schools are teaching C first to CS students, but who knows about other disciplines?

---

In the course I mentioned above, we're using Java which probably isn't a bad choice, since most in the class are having a relatively tough time as is, without having to do their own memory management or understand anything above the most basic understanding of what OO is.

A friend of mine on the other hand is doing Engineering, and I believe they're required to do an introductory programming course that starts them off in C or C++ (I don't recall which - probably C compiled as C++).

Quote:

---

Originally Posted by citizen

>> It also avoids the pitfalls in C that should never have existed (implicit function calls being one
>> of the most severe).

Um, it may be your opinion, but non-main functions are explicitly called. I do believe you are making up problems now. The issue I think you mean is prototypes being implicitly being included, such as for printf, or C assuming functions return int when they're not declared. The first part is caused by the C run-time, which does depend on certain libraries. The second is well reported by the compiler but it's not a bad thing to expect more I suppose. Don't start making up a problem, though.

---

Not making things up. The problem I'm referring to is the ability to call functions with a prototype, in which case C will assume that the prototype is int function(...), which is NOT a good thing!

Btw, I see you've seen an anime I know of! Zero no Tsukaima or Zero's familiar. Hehe.

Quote:

---

Originally Posted by Elysia

Not making things up. The problem I'm referring to is the ability to call functions with a prototype, in which case C will assume that the prototype is int function(...), which is NOT a good thing!

---

Right. So that's not an implicit function call, that's an assumption being made about an explicit function call. An implicit function call would look like this (C++ example):

Code:

---

a = b + c; //implicit function call operator+(), and operator=()

---

So what do you want to call it?

Quote:

---

Originally Posted by Elysia

So what do you want to call it?

---

I would call it "making assumptions about missing prototypes".

Alright, so until some better name or official term shows up, I'll just say that C has the ability to make assumptions about missing prototypes which is a very bad thing.

Why? Doesn't this simply mean that it is poor form to not declare your functions?

If the behavior is unspecified (and you have a lot of that on C++ too) the general rule of thumb is... don't do it.

I have a question. Is g++ the same fast as gcc? If not there will always be a reason to use C over C++. I found this http://shootout.alioth.debian.org/gp4/cpp.php for example.
But in any case, why wouldn't they two compilers be the same? And why have two compilers and not an upgraded one with a flag -Conly.

Quote:

---

Originally Posted by C_ntua

I have a question. Is g++ the same fast as gcc? If not there will always be a reason to use C over C++. I found this http://shootout.alioth.debian.org/gp4/cpp.php for example.
But in any case, why wouldn't they two compilers be the same? And why have two compilers and not an upgraded one with a flag -Conly.

---

The C implementation and C++ implementation of those tests are different code, they work differently. If you compiled the C example with g++ instead of gcc it would come out exactly the same.

Quote:

---

Originally Posted by Mario F.

Why? Doesn't this simply mean that it is poor form to not declare your functions?

If the behavior is unspecified (and you have a lot of that on C++ too) the general rule of thumb is... don't do it.

---

Of course you shouldn't do it, but should a compiler actively allow it? I think not.
The compiler should complain and avoid undefined behavior. It's very easy to hide this little warning.
So IMO, it's a very good thing C++ forbid this nonsense, since it IS bad practice not to use headers.

Quote:

---

Originally Posted by C_ntua

I have a question. Is g++ the same fast as gcc? If not there will always be a reason to use C over C++. I found this http://shootout.alioth.debian.org/gp4/cpp.php for example.
But in any case, why wouldn't they two compilers be the same? And why have two compilers and not an upgraded one with a flag -Conly.

---

It would not be a reason to use C over C++, since language-wise, they are pretty much equal in performance, some places where C perform better, some places where C++ perform better.
Note that a poor C++ compiler may produce slower code than the equivalent C compiler, but that is hardly the language's fault and the solution is to get a BETTER compiler.

Quote:

---

Originally Posted by Doodle77

The C implementation and C++ implementation of those tests are different code, they work differently. If you compiled the C example with g++ instead of gcc it would come out exactly the same.

---

Or at least, for 99% of the cases, that would be true. There are some subtle differences between gcc and g++ that SOMETIMES cause a small difference.

But in essence the Doodle77 statement is correct: The two pieces of code compared here are not identical - they use the same basic algorithm, but it's implemented in different ways.

Compare:
http://shootout.alioth.debian.org/gp...&lang=gpp&id=3
http://shootout.alioth.debian.org/gp...otide&lang=gcc
and you can see that the code is not very similar at all [it is of course similar in the aspect that it's implementing the same functionality - but in the detail, it is quite different]. I don't see any obvious "big hit" on the performance, but C++ tends to offer subtle ways to "hide" performance hits - a possible candidate is that the C version uses realloc to allocate a 10K larger chunk of memory inside the initial fgets() loop - which is done differently in the C++ version.

--
Mats

Quote:

---

Originally Posted by Elysia

Of course you shouldn't do it, but should a compiler actively allow it? I think not.
The compiler should complain and avoid undefined behavior. It's very easy to hide this little warning.
So IMO, it's a very good thing C++ forbid this nonsense, since it IS bad practice not to use headers.

---

I don't even know where to start dismantling this opinion of yours.

Code:

---

// C
int main() {

    int foo = 12;
    bar(foo);

    return;

}

void bar(int foo) { ; }

---

Visual Studio complains starting on warning level 3 with default project setup.
Didn't test it on gcc, but seen my share of "Implicit declaration of function..." warnings. So not sure what do you mean. The compiler complains.

Meanwhile...

Code:

---

// C++
int main() {

    int foo[5] = {1,2,3,4,5};
    int bar[5];

    int i = 0;
    while (i < 5)
        bar[i] = foo[i++];

}

---

Doesn't sound a blip on warning level 4.

So back to your argument:

>> So IMO, it's a very good thing C++ forbid this nonsense, since it IS bad practice not to use headers.

So it is evaluation order dependency and yet I got no warning. In fact the C++ standard says I don't have to have a warning. It's undefined behavior... as it is the result of implicit declaration of functions in C. More, implicit declaration results in a warning, whereas evaluation order dependency doesn't. And on some circumstances the compiler couldn't even if it wanted too. Which is "worst"? Don't answer.

One last small little unimportant thing of absolutely no consequence at all: C99 removed implicit declaration of functions. So... yeah.

Classic error:

Code:

---

// C
int main() {

    int* foo;
    foo = (int*)malloc(sizeof(int));

    return;
}

---

Yes, Visual Studio is actually kind enough to warn me. Are other compilers just as nice? No.
And just to clarify: I didn't include the proper header.

And what does the C++ sample have to do with anything?
No, it's not good that it doesn't warn, but it doesn't warn regardless if it's C or C++ code, does it?
My point is that C++ actually improved on something - it removed something very nasty and dangerous from C. That doesn't mean C++ is always better in everything.

*opens mouth to say something but gives up...*

Quote:

---

Originally Posted by Mario F.

Doesn't sound a blip on warning level 4.

---

Why would it?

Quote:

---

Originally Posted by Elysia

Yes, Visual Studio is actually kind enough to warn me. Are other compilers just as nice? No.
And just to clarify: I didn't include the proper header.

---

Which compiler did not give a warning?

Quote:

---

Originally Posted by robwhit

Which compiler did not give a warning?

---

I do not know. I only tried with Visual Studio.
But the FAQ does mention that it hides warnings, so obviously it can mask it on certain compilers.

<my two cents>I like C.*</my two cents>


* My two cents are actually an arcade token and a plastic button. So actual monetary may vary depending on the exchange rates.

It saddens me to see that someone likes C*.
* Individual opinion.

Well, if you interpret that as a regular expression, then C.* includes C, C++ and C#.

Yeah, it's great to see C++ among them, but it's still a regular expression, meaning C is among them, which I don't have to clarify my feelings for. And further among them is C#, another language for which I have no love, although perhaps not as much dislike as for C.

Quote:

---

Originally Posted by Elysia

I do not know. I only tried with Visual Studio.
But the FAQ does mention that it hides warnings, so obviously it can mask it on certain compilers.

---

The cast does mask the implicit declaration. However, there is really no use for an implicit declaration, except for cutting corners, which really isn't needed, I'd guess.

It's an easily detected error that pretty much all compilers recognize, and if it doesn't, you could just use a static checking tool instead, or compile it with another compiler. It's a problem that's fixed with a compiler switch, providing a way to not have that problem and write in fully conforming code otherwise. I don't see what's so impractical about this.

Quote:

---

Originally Posted by robwhit

The cast does mask the implicit declaration. However, there is really no use for an implicit declaration, except for cutting corners, which really isn't needed, I'd guess.

---

That's the point.
It's not needed. It's bad practice.
So why is it allowed?

It was put in C89 for compatibility with legacy code. It's not in C99, as Mario said. If you don't want it in C89, then disallow it with a compiler switch, or use a static code checker, or both.

Yeah, I get it was there for a purpose, but that doesn't mean I agree with it.
BUT it is good to know that it isn't there in C99. C99 actually seems to fix a number of small issues, mainly implicit function types and the whole ordeal with calling functions without prototypes.

Are you adverse to using a compiler switch to fix that problem in C89?

I just don't see why you always rag on C, Elysia. I mean I do realize that I do write a lot of C++ code and all, and perhaps I am just fond of C because it was what some of my proudest projects were written in. But either way I don't see what difference it makes. At least I don't like C#. Everytime someone says they like C# a sun microsystems angel loses its wings.

Quote:

---

Originally Posted by robwhit

Why would it?

---

What's your point exactly?

Quote:

---

Originally Posted by Elysia

mainly implicit function types and the whole ordeal with calling functions without prototypes.

---

Note that those are the same thing.

Quote:

---

Originally Posted by Mario F.

What's your point exactly?

---

That that code is legal and that it shouldn't trigger a warning like you implied.

Quote:

---

Originally Posted by robwhit

Note that those are the same thing.That that code is legal and that it shouldn't trigger a warning like you implied.

---

Actually I didn't try to imply it would. I did say however it was undefined, which it is. The point was exactly that undefined behavior shouldn't necessarily trigger warnings.

I don't see how it's undefined.

Err... the compiler is free to choose which side of the assignment it evaluates first, rob.

EDIT:

Quote:

---

Originally Posted by C++ Standard ISO-IEC 14882-2003(E) - 5 Expressions, &#167

Except where noted, the order of evaluation of operands of individual operators and subexpressions of individual
expressions, and the order in which side effects take place, is unspecified.53) Between the previous
and next sequence point a scalar object shall have its stored value modified at most once by the evaluation
of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored.
The requirements of this paragraph shall be met for each allowable ordering of the subexpressions of a full
expression; otherwise the behavior is undefined. [Example:
i = v[i++]; // the behavior is unspecified
i = 7, i++, i++; // i becomes 9
i = ++i + 1; // the behavior is unspecified
i = i + 1; // the value of i is incremented
—end example]

---

Ah yes I was confused. I thought the post-increment operator would only take effect after the sequence point was encountered, but I was confusing things.

It took me a while to see the undefined behavior also.

Code:

---

bar[i] = foo[i++];

---

Could you perhaps explain it to me then? Because neither example attempts to modify i more than once. That would be the only place undefined behavior could occur.

bar[i] = foo[i++];
i++ evaluates to i for both sides, bar[i] is assigned, and after the sequence point is encountered, the increment occurs. Am I wrong? i = v[i++]; seems to be the closest thing that would support Mario's claim but that isn't happening here.

And see http://www.difranco.net/cop2220/op-prec.htm, or perhaps any other table for information on delayed increments. There's likely chapter and verse somewhere...

I thought that too, but I think the relevant part is here:

Quote:

---

Furthermore, the prior value shall be accessed only to determine the value to be stored.

---

Ah, well, err to the side of caution I suppose.

My apologies.
I tried to display that undefined behavior behind an implementation only to further the idea C++ (whether through its C roots or not is irrelevant) also has its share of undefined behavior and no compiler warnings, as seems to be Elysia's major gripe with C and her crusade to rid the world of C textbooks.

Perhaps I overdid it. So apologies again.
But I feel It could go much further. It is often said of C++ that with C you are given a gun with which you can accidentally shoot your own foot, but with C++ you can blow your whole leg off (or some variation of this). If we were to crusade against languages for their inherent general-purpose idiosyncrasies, there would not be any programming languages in the world and not even interpreted languages would have a chance at being developed.

The statement

Code:

---

bar[i] = foo[i++];

---

could be done as (using an extra variable to more clearly show the different steps)

Code:

---

t = foo[i];
bar[i] = t;
i++;

---

or

Code:

---

t = foo[i];
i++;
bar[i] = t;

---

Both are reasonable interpretations. One could of course argue which one is "right" but that is moot. The standard decided to not define one as the correct behavior and left it as undefined behavior.

It is equally undefined for both C and C++.

Code:

---

bar[i--] = foo[i++]

---

Would leave the value of i in doubt in addition to which array element got moved where.

That is why changing the value of a variable on both sides of an equation is considered undefined according to the standard. Just as it is undefined to change the same variable across multiple parameters of a function.

Code:

---

printf("%d %d", ++i, i--);

---

Quote:

---

Originally Posted by robwhit

Are you adverse to using a compiler switch to fix that problem in C89?

---

That is a compiler fix and not a language fix which is what I'm having a grip with.
It's a flaw that shouldn't have been in the language to begin with.

Quote:

---

Originally Posted by Mario F.

My apologies.
I tried to display that undefined behavior behind an implementation only to further the idea C++ (whether through its C roots or not is irrelevant) also has its share of undefined behavior and no compiler warnings, as seems to be Elysia's major gripe with C and her crusade to rid the world of C textbooks.

---

I'm well aware of the fact and I did explain it too, that C++ isn't perfect and has its set of flaws.
Some of them I would see fixed, yes.
But C is much MORE flawed with things that shouldn't have been allowed in the first place. At least C++ fixes SOME of those things and is better in that regard.

>> But C is much MORE flawed with things that shouldn't have been allowed in the first place. At least C++ fixes SOME of those things and is better in that regard.

Yes. And introduces new things. Until you come with with a number for both cases, and also clearly justify "better" and "worst", I prefer to keep considering your whole arguments a display of your utter ignorance.

Have a nice day.

Quote:

---

Originally Posted by Elysia

That is a compiler fix and not a language fix which is what I'm having a grip with.
It's a flaw that shouldn't have been in the language to begin with.

---

That's understandable. However, since there is an easy fix for it with the tools that are used in real life, then it makes C a usable tool again, as long as this fault is concerned. Wouldn't you agree?

I would agree that it's nice that compiler vendors work around nasty stuff in languages that should never have been introduces. When they do exist, I tend to use them (such as VS's "safe" C functions such as strcpy_s and VS's iterator debugging, etc).

So are you saying that you would use this workaround for this problem if you were working on C code?

Absolutely, I most definitely would.

I feel like i'm talking to bloody brick wall!

C99 doesn't have implicit function declarations!

Can you think of any situation where this workaround would not be workable?

Quote:

---

Originally Posted by Mario F.

I feel like i'm talking to bloody brick wall!

C99 doesn't have implicit function declarations!

---

I got that already, but I was discussing GENERALLY, not a SPECIFIC something.
I already acknowledged that C99 has taken steps in the right direction.

Quote:

---

Originally Posted by robwhit

Can you think of any situation where this workaround would not be workable?

---

Other than when I would be forced to use a compiler such as one that does not support said feature, no.

Given that you would use this workaround in all situations that supported it, and all situations that you know support it (Post #39), wouldn't this detraction from why to use C not apply in real life, since in real life, you need a compiler for C code?

Quote:

---

Originally Posted by Elysia

I got that already, but I was discussing GENERALLY, not a SPECIFIC something.
I already acknowledged that C99 has taken steps in the right direction.

---

So, is it you advocate against C because you GENERALLY think you should, or because you SPECIFICALLY think you should?

Do you honestly think people should listen to you if you can be coherent in the course of a single thread, if you don't understand the difference between design and implementation, and you don't have the smallest clue of the industry?

I refrain from commenting on the rest because I see where robwhit is taking it... albeit I fear is as useless as any other attempt so far. You lack humility.

C is not advanced enough. It's an old language unfit for today's commercial needs (and due to its lacking functionality, also a poor choice for private software).
It will most likely produce buggy, unreliable code unless you put in lots and lots of hours into it. And those hours could be used to create more, better functionality. On in other words, it's time that could have been spent in other areas for improvement.

Quote:

---

Originally Posted by Mario F.

So, is it you advocate against C because you GENERALLY think you should, or because you SPECIFICALLY think you should?

Do you honestly think people should listen to you if you can be coherent in the course of a single thread, if you don't understand the difference between design and implementation, and you don't have the smallest clue of the industry?

I refrain from commenting on the rest because I see where robwhit is taking it... albeit I fear is as useless as any other attempt so far. You lack humility.

---

What you don't seem to understand is that sometimes I voice opinions, but I cannot convert long-time C users to C++ or any other language. Am I trying? No. Because I know I cannot succeed.
But it doesn't stop me from voicing opinions and trying to stray newbies from C, by attempting to explain why C is to be used only when necessary (it's obviously up to them in the end - no one is allowed to choose for another).
And I do it, because frankly, I'd like to see faster quality software, with few bugs and lots of features. You don't get that with C.

Quote:

---

Originally Posted by Elysia

C is not advanced enough. It's an old language unfit for today's commercial needs (and due to its lacking functionality, also a poor choice for private software).
It will most likely produce buggy, unreliable code unless you put in lots and lots of hours into it. And those hours could be used to create more, better functionality. On in other words, it's time that could have been spent in other areas for improvement.

---

by that rationale, you should abandon C++ in favor of C# and Java

Quote:

---

Originally Posted by FillYourBrain

by that rational, you should abandon C++ in favor of C# and Java

---

Why would I do that?
What does Java and C# have that C++ does not (except for "safety")?

more type safety, garbage collection, binary cross platform capability, reflection...

Note that I don't advocate Java over C++, but I'm simply presenting your argument for it.

Quote:

---

Originally Posted by nonoob

Maybe programming is 99% frustration nowadays. But it didn't used to be. I wouldn't have lasted 30 years in this biz if it had.

---

They used to teach generalized problem solving, now they teach them to use pre-fab solutions.