Qbasicnews.com

General => General Programming => Topic started by: Nixon on May 29, 2006, 07:36:51 AM



Title: C/C++, which one first
Post by: Nixon on May 29, 2006, 07:36:51 AM
I need to learn C/C++ by the end of this year for my course next year, enough to pass a 3 hour test. I was wondering which I should learn first, or doen't it matter. Also does anyone know of any 'from BASIC to C/C++ tutorials'


Title: C/C++, which one first
Post by: na_th_an on May 29, 2006, 07:45:26 AM
Rule #1: When learning a new language, forget everything about other languages. Just keep algorithmics on mind.

I'd go for C, then C++, as C++ is just C with added junk. You understand C, you'll understand the add-ons.

Learning C will help with your fB coding as well, as mastering the simple concept of pointers and dynamic memory management will open lots of doors :P


Title: C/C++, which one first
Post by: stylin on May 29, 2006, 08:16:41 AM
I'd say learn C++. It's been one of the more predominant languages right now - especially for games - so there is a vast wealth of information available to you.

C is very different from C++. Good/practical techniques in one are not necessarily good in the other. C++ is not just "C with classes", it's a multi-paradigm language that supports different kinds of programming than C (which is procedural). When you're learning C++ the "right way", imo, you'll find that the only similarities to C are some syntax.

Also, I would say that to get started in either language, the learning curve is not as high in C++ (it's alot easier to create a safe dynamic array in C++ than it is in C. plus, you'll be using already tested implementations with your C++ standard library).

Additionally, learning C++ - as opposed to C -  will make it easier to migrate to languages like Java, or C#.


Title: C/C++, which one first
Post by: Nixon on May 31, 2006, 08:19:29 AM
Well I have begun to learn C. I know enough to make games now, crapy games at that cause I can't get conio working which is a major pain in the butt.

Anyone know of a small (smaller than 10mb) C compilier and IDE, one that can use conio preferably.

Also are there any good libraries I could use for graphical 2d game creation, or any that would be helpful.

One more thing, what is the point in having pointers, apart from pointing to memory locations and linking with variables, whats the use really?


Title: C/C++, which one first
Post by: Peter on May 31, 2006, 08:25:58 AM
I would suggest C on the fact that most C++ code I've seen is really just C code with some OO tacked on that could have been replicated using other data structures.

Unless you are really gung-ho on OO C++ is kind of a bother.
$0.02


Title: C/C++, which one first
Post by: na_th_an on May 31, 2006, 12:02:15 PM
Quote from: "Peter"
most C++ code I've seen is really just C code with some OO tacked on that could have been replicated using other data structures.


Yay! You're on my team! :D


Title: C/C++, which one first
Post by: stylin on May 31, 2006, 07:20:10 PM
Hmm, you two need to see more C++ code ...


Title: C/C++, which one first
Post by: Peter on May 31, 2006, 08:04:31 PM
I deal with C++ all the time, I understand the whole different paridigm of programming idea.  It's completely valid, but from the code that I have work with it seems to me that many of the people who work with C++ don't, hence they use those different tools (OO in particular) when they don't have to.

It's all an issue of elegence.  Just because you can use a tool doesn't mean you need to.  Most people don't get thier heads completely around C++ and so that becomes a liability to thier coding.  C has less tricks about it and lets people mong cleaner code.


Title: C/C++, which one first
Post by: Anonymous on May 31, 2006, 09:30:28 PM
i can tell you after working on a medium sized project (LL, 20k lines without comments/whitespace) that OOP would be invaluable in FB.

OOP is necessary like a chisel is necessary. sure, you could use a flatheaded screwdriver, and it will get the job done (with more effort, more chances to f*** up), but the "chisel" is made for the job.

OOP is made for organizing, encapsulating, genericizing (not a real word), but of course not 100% blaze efficency in every case. You want that? Code in ASM. And then cry when the code you make has to be rewritten all the time to suit special needs when things like templates or function overloading would've reduced the amount of work by a magnitude of 5 or 10 or 20.

Keep in mind, I don't routinely program in c++, FB is my language of choice, but I've learned about the paradigm, and it's really a shame that it hasn't been embraced yet.* Finally web coding seems to be with things like XML. Dividing the data from the code. Encapsulation. Just like seperate objects.

When FB gets OOP I'll show you. ;P

*By many BASIC programmers? ;P


Title: C/C++, which one first
Post by: stylin on May 31, 2006, 11:55:28 PM
Quote from: "Peter"
...from the code that I have work with it seems to me that many of the people who work with C++ don't [fully understand it], hence they use those different tools (OO in particular) when they don't have to.

The way certain people program in a language doesn't have anything to do with the usefullness of that language. I've seen alot of crappy, wasteful and unsafe C code in my time, also; doesn't mean C is all those things.

Quote
It's all an issue of elegence.  Just because you can use a tool doesn't mean you need to.  Most people don't get thier heads completely around C++ and so that becomes a liability to thier coding.  C has less tricks about it and lets people mong cleaner code.

Again, I think it's wrong to say that a language is a bother just because there may be some people that don't know how to use it properly. I would give the OP the benefit of the doubt.

I don't know what you mean by tricks (or "mong", for that matter), but to do some of the more basic and elegant things in C++ - like polymorphism, for example - requires a level of knowledge of C that is much greater than either a beginner or intermediate programmer. C++ takes much of the work involved in memory management and does it for you, unlike C where memory management is always a top-level concern.


Title: C/C++, which one first
Post by: TheAdventMaster on June 01, 2006, 03:49:42 AM
Quote
When FB gets OOP I'll show you. ;P
I can't wait.


Title: C/C++, which one first
Post by: Peter on June 01, 2006, 08:33:01 AM
Quote
Again, I think it's wrong to say that a language is a bother just because there may be some people that don't know how to use it properly. I would give the OP the benefit of the doubt.

I should have as well :oops: I'm just a cranky old man sometimes.

I don't know what you mean by tricks (or "mong", for that matter), but to do some of the more basic and elegant things in C++ - like polymorphism, for example - requires a level of knowledge of C that is much greater than either a beginner or intermediate programmer. C++ takes much of the work involved in memory management and does it for you, unlike C where memory management is always a top-level concern.[/quote]

'Mong' is a really old word for making things or selling things
It's why a person who sells fish is called a Fishmonger.

I like to think of programmers as codemongers, with the internet as code markets (like fish markets) where coders get together and comment on and trade code.  Sometimes my analogies get ahead of me :oops:

In anycase I still go against C++ because of the habits those who program in it poorly tend to get in, namely using OO where you could use a list or even a simple array.  Complexity for Complexities' sake.  I'm not saying OO is bad, OO is a great thing when used correctly, I'm just against people using it where it is innapropriate to do so and I see this quite a lot in C++ code.

I'm actually quite excited about OO coming to FB myself as well. :D


Title: C/C++, which one first
Post by: na_th_an on June 01, 2006, 09:01:12 AM
#1 flaw of C++: it allows for non-OO stuff. As a language, in the purity of the word, it has that incredible flaw. I prefer the cleanness of Java, for instance.

@Cha0s: everything you say about OOP, you can do with procedural languages. It's all just a matter of syntax shortcuts and macros.


Title: C/C++, which one first
Post by: yetifoot on June 01, 2006, 09:06:56 AM
Mong here (England) now means a retard, or at best a very slow, dim-witted person.  ('Special Needs' for the polically correct).  Its a common insult.


Title: C/C++, which one first
Post by: Peter on June 01, 2006, 09:30:12 AM
Quote
Mong here (England) now means a retard, or at best a very slow, dim-witted person. ('Special Needs' for the polically correct). Its a common insult.

England! What would England know about english! :P


Title: C/C++, which one first
Post by: stylin on June 01, 2006, 09:40:30 AM
na_th_an: I wouldn't say C++ is the epitome of anything. I agree that, because of its support of a wide variety of paradigms, you could say it's the jack of all trades, master of none. I'll have to disagree that allowing for non-oop is a flaw, though, simply because nowhere does it say that C++ is an object-orientated language, nor is it best used purely as one.

And, you may be able to simulate objects, polymorphism and the like with a procedural language but ... why on earth would you? :o

Peter: Thanks for the clarification. I've seen the term before, but never by itself. :)

Ultimately, I still have to recommend C++ over C just as I would recommend C over assembler. Beginning programmers need to worry about using the language, not making the tools necessary to. Going back to memory management, for example. In C, it takes an incredible amount of knowledge and work to be able to make a linked list as generic, safe and fast as the one C++ already provides for you. IMO, beginners should be learning where and when to use a linked list, not how to make one. Granted, such an exercise gives you much insight to things like pointers, but pointers are not as important in C++ as they are in C, consequently, much of the worry over their use - particularly memory leaks and buffer over/underruns - is simply non-existant in C++. Beginner's can worry about program design, as opposed to implementation.


Title: C/C++, which one first
Post by: TheAdventMaster on June 01, 2006, 10:22:45 AM
Quote
simply because nowhere does it say that C++ is an object-orientated language, nor is it best used purely as one.
Correct, but one of the main reasons people move to C++ over C is because of the object orientation.  Forcing OO would be idiotic though :P

The problem with learning C++ first is most tutorials expect you to have a slight amount of knowledge in C first.  I tried learning from a C++ tutor a few months back, and most of the stuff was written for someone who already took C.


Title: C/C++, which one first
Post by: LooseCaboose on June 01, 2006, 06:40:51 PM
Quote from: "stylin"

And, you may be able to simulate objects, polymorphism and the like with a procedural language but ... why on earth would you?


Its more about using techniques such as encapsulation and separating the interface from the implementation. These are widely used in object orientated languages, but are just as applicable to procedural languages.

A friend (also doing a Masters degree) and I have been discussing the issue of which language should be taught first in Universities, and have come to the conclusion that it really doesn't matter. I tutor the first year course in programming in Java. We have had a couple of students with delusions of l33tness that have complained with "why do we have to learn Java and not a real language like C/C++". A good computer scientist/programmer should understand the principles of programming and the various paradigms to a point where they can pick up any language in a few days. The computing world moves so quickly that the language you learn in school may be obsolete by the time you make it to the industry. As an example, C# did not exist a few years ago, a company shouldn't have to send its employees back for new language retraining, they should be capable of picking up the documentation and transfering over.

Auckland university here in New Zealand has an assignment that must be written in C, but they never teach it, students are expected to be able to learn it themselves. Some of the better Universities for computer science (cant remember names offhand) teach functional languages (Haskell, SML, etc) rather than imperitive languages. While functional languages are rarely used in industry, the skills learnt translate easily to other languages.

In short learn any language you want, but learn how to program in general rather than learning how to program in a single language specifically. You have no idea what language you will be programming in when you go out an get a job, it may not even have been invented yet ;-)


Title: C/C++, which one first
Post by: Anonymous on June 02, 2006, 12:12:36 AM
Quote from: "na_th_an"
@Cha0s: everything you say about OOP, you can do with procedural languages. It's all just a matter of syntax shortcuts and macros.



Quote from: "me"
sure, you could use a flatheaded screwdriver, and it will get the job done (with more effort, more chances to f*** up), but the "chisel" is made for the job.


Title: C/C++, which one first
Post by: neuro on June 02, 2006, 02:20:24 AM
I'd say, learn C++ first.  With C++'s std::string class, you won't face such a ridiculously annoying learning curve with C strings.
Simple things like QB's MID$(a$,b,c) are rather difficult in C.  I, for one, use shitloads of string manipulation in my programs so it's important that that sort of stuff is easy.
In C++, it would just be a.substr(b, c);

I would, however, not discount C altogether.  Learn it when you understand C++ and want to take it to an even lower, closer-to-machine code level.

And yeah, though C++ has greater potential for obfuscated code (though C's obfuscation factor is damn high too), I would argue that a well formatted, object oriented C++ program is MUCH easier to follow and understand than a well formatted C program.

My 2cents

 - Eric / neuro


Title: C/C++, which one first
Post by: stylin on June 02, 2006, 05:36:45 AM
Quote from: "LooseCaboose"
[Simulating OO in C is] more about using techniques such as encapsulation and separating the interface from the implementation. These are widely used in object orientated languages, but are just as applicable to procedural languages.

Yes, I agree. But as you imply below, the needs of the situation dictate the practicality - therefore the applicability - of those techniques. That is, in practice, those methods aren't as universal as they seem, and their use as an aid in learning a language is questionable.

Quote
[programmers] should be capable of picking up the documentation and transfering over.

Of course they should, but is it wise to recommend techniques which obfuscate what the language was intended for (I'm talking specifically about OO in C)? IMO, when you're learning a language you should at least learn how to use it properly, if not effectively. In any case, I don't think the ability to go beyond what a language is inteded to do should be a 'pro' of whether or not it's a better learning tool.

neuro: Yeah, strings and dynamic arrays in general are good examples. You can pack a large amount of power in an intuitive, and potentially worry-free package.


Title: C/C++, which one first
Post by: Radical Raccoon on June 02, 2006, 05:57:03 PM
OOP is great. I don't know why anyone would want to do it all procedurally, unless you're using a compiler that isn't OO.

If C is any tougher to learn than C++, I'd say go with C++. That's what I went to from QB, and it was tough enough.

I would hope that FB doesn't become OO, because then it really wouldn't be basic anymore.


Title: C/C++, which one first
Post by: LooseCaboose on June 02, 2006, 08:32:59 PM
Quote from: "stylin"

...but is it wise to recommend techniques which obfuscate what the language was intended for (I'm talking specifically about OO in C)?


I'm not talking about simulating OO in C, I'm talking about using code maintainability techniques such as encapuslation which were popularised by OO languages. For example a module in C could be used for maintaining lists of information. If the module allows callees to modify the list themselves via global variables then the program is not well encapsulated, changing the storage implementation will break all of the callee modules. If the module provides a set of functions for adding, deleting, etc then the implementation can be changed without breaking the functionality of other modules. Object orientation explicitly encourages this with classes and interfaces, it is a good idea is most languages though.

A large number of things that programmers need to understand translate to most languages: algorithm choice, the difference between value and reference types, understanding immutable types, knowing what static and dynamic structures are, etc.

The programming paradigms (procedural, imperitive, OO, functional, etc) can be a bit of a hurdle, but I would still expect a good programmer to be able to learn a new paradigm in a small amount of time and be able to apply their knowledge of programming to each language appropriately.


Title: C/C++, which one first
Post by: NecrosIhsan on June 02, 2006, 11:48:38 PM
You should learn whichever one is going to suit your needs. Personally, I find C to be a bit easier to understand than C++ ("C++ turns C code into error messages"), but there are quite a few niceties in C++ that simply don't exist in traditional C. You don't have to know C to know C++, in fact you have to "unlearn" a few things from C to grasp C++, but knowing both will give you a serious advantage in the professional world, should you decide to venture there with your skills.


Title: C/C++, which one first
Post by: stylin on June 03, 2006, 03:46:48 AM
LooseCaboose: variables, functions and typedefs are also examples of encapsulation, albeit rather simple/obvious ones. The issue is not that encapsulation is bad per se, but when you start over-engineering your code to the point that implementation detail (how things are done, structured) takes it over, it's a bad thing. That is, it detracts from what the code is supposed to do and forces you to deal with how it does it, and I was responding to na_th_an's post in particular, but any naive or impractical designs made to be realized in other languages can lead to this kind of situation (I'll include boost's implementation of functional programming in C++ as well).


Title: C/C++, which one first
Post by: na_th_an on June 03, 2006, 11:03:36 AM
I said "As a language, in the purity of the word". Of course you can do shitty code in C++ and awesome code in C++, I was just talking about language design.

And I concur with everything said by LooseCaboose. The point was, everyone thinks that using an OOP or a pseudo OOP language provides you the "good things" such as encapsulation, etc - and all I was replying is that: "you don't need an OOP language for that" and "using an OOP language doesn't imply that you are using that" :D

I'm coding in pure C for 8 bit computers right now. And you can do all that "good stuff" without the overhead C++ introduces naturally (as it is a higher level language than C - C is almost assembly if you want).


Title: C/C++, which one first
Post by: Radical Raccoon on June 03, 2006, 08:17:07 PM
C isn't object oriented?  :o


Title: C/C++, which one first
Post by: TheAdventMaster on June 03, 2006, 09:13:52 PM
Quote from: "Radical Raccoon"
C isn't object oriented?  :o
. . . ?


Title: C/C++, which one first
Post by: Radical Raccoon on June 04, 2006, 01:16:54 AM
Quote from: "TheAdventMaster"
Quote from: "Radical Raccoon"
C isn't object oriented?  :o
. . . ?

That's the message I'm getting from this discussion.


Title: C/C++, which one first
Post by: LooseCaboose on June 04, 2006, 01:39:07 AM
Quote from: "Radical Raccoon"

C isn't object oriented? That's the message I'm getting from this discussion.


Correct. C is an imperative (http://en.wikipedia.org/wiki/Imperative_programming) procedural (http://en.wikipedia.org/wiki/Procedural_language) language. C++ is an imperative object orientated language.

Quote from: "stylin"

LooseCaboose: variables, functions and typedefs are also
examples of encapsulation, albeit rather simple/obvious ones. The issue is not that encapsulation is bad per se, but when you start over-engineering your code to the point that implementation detail (how things are done, structured) takes it over, it's a bad thing.


Like na_th_an said, you can over or under-engineer things in any language. If a large project is becoming difficult to work with because it is structured poorly then switching to OO is not going to magically fix the problem for example. I have seen lots of OO code that has been written by people that don't understand OO concepts.

I don't believe that OO is the magic bullet that alot of the programming world would have us believe that it is. Different projects suit different languages. As an example the 4th year paper in AI at my University has an assignment for building an AI system that can be done in any language. The lecturer showed some results from previous years: C versions usually took around 200-300 lines of code, a Lisp implementation averaged 30-50 lines and one year someone got full marks with a 9 line Prolog implementation. I think Microsoft has the right idea with .NET and the CLR (Common Language Runtime). Programmers can write different parts of a single program in multiple languages and then easily combine them. The problem is that most of the languages supported by .NET currently are imperitive/OO languages. One of my friends Masters degree is looking at making functional languages work on the .NET runtime.


Title: C/C++, which one first
Post by: Anonymous on June 04, 2006, 06:18:57 AM
Yes, I just read lillo's thesis (not all of it, yet) about declarative languages. (prolog is declarative, i believe) Kind of interesting.


Title: C/C++, which one first
Post by: na_th_an on June 04, 2006, 05:29:15 PM
Declarative languages rock :D LISP (yeah, I know, this is a "functional language", but if fits in what I'm gonna say), PROLOG and CLIPS are simply awesome for some tasks.

I mean, you can create a simple AI which learns stuff from what you say and what it asks in no more than 30 PROLOG lines. Programs that modify themselves, programs that take programs as data and process and modify them... Nice stuff for high-level nerds :D


Title: C/C++, which one first
Post by: stylin on June 04, 2006, 06:19:32 PM
Quote from: "LooseCaboose"
Like na_th_an said, you can over or under-engineer things in any language. If a large project is becoming difficult to work with because it is structured poorly then switching to OO is not going to magically fix the problem for example. I have seen lots of OO code that has been written by people that don't understand OO concepts.

I think we're getting a bit off-track. My initial point was that when those or any other concepts are used in a language that wasn't designed for them (speaking from the programmers' point of view) the burden of replicating the idiom begins to overshadow the code that matters. Your Lisp story parallels that idea a little.

Quote
I don't believe that OO is the magic bullet that alot of the programming world would have us believe that it is. Different projects suit different languages.

I fully agree, which is exactly why I'd recommend C++ over C for beginning programmers; I think C++ is a better overall learning tool, because it supports concepts in native syntax that make it easier for you to concentrate on design, rather than implementation (of not only OO details. For instance, std::vector let's the beginning programmer think more about what she wants to do with an array, while C forces her into dealing with the often complicated and - at that point - unimportant details about how to make it safe to use, further burdening her with debugging hell when she mis-uses it. I'll throw std::map and std::set in there for some over-the-top examples of something better done in C++, again, from the programmers' point of view).

na_th_an: C++ isn't that "far from assembly" itself, but talking about speed in a thread like this is, I think, a little off-topic. :P


Title: C/C++, which one first
Post by: NecrosIhsan on June 04, 2006, 07:00:42 PM
Quote from: "stylin"
C++ isn't that "far from assembly" itself

It isn't? :???:


Title: C/C++, which one first
Post by: stylin on June 05, 2006, 03:08:39 AM
Quote from: "NecrosIhsan"
Quote from: "stylin"
C++ isn't that "far from assembly" itself

It isn't? :???:

It isn't as far as a novice programmer should think about it.


Title: C/C++, which one first
Post by: na_th_an on June 05, 2006, 03:44:11 AM
I just see how people around here are learning C++ and... they are not learning OOP C++. They are learning "C plus classes" which, IMHO, is a bad thing. I can tell this from the code snippets that are posted around here all the time. You get procedural code with C++ syntax and shortcuts.


Title: C/C++, which one first
Post by: NecrosIhsan on June 05, 2006, 09:47:25 AM
Quote from: "na_th_an"
I just see how people around here are learning C++ and... they are not learning OOP C++. They are learning "C plus classes" which, IMHO, is a bad thing. I can tell this from the code snippets that are posted around here all the time. You get procedural code with C++ syntax and shortcuts.

That's not necessarily a bad thing though. Most coders here are probably more used to procedural coding, so procedural C++ makes more sense to them. They may not be "taking full advantage" of C++, but realistically, who does? It's the end product that matters anyways...the end justifies the means.


Title: C/C++, which one first
Post by: Radical Raccoon on June 05, 2006, 12:59:51 PM
OOP is just an overrated term anyways. Basically it's still procedural (one thing happens after another).

Learning OOP and C++ are 2 different things. When I first started learning C++, I had to learn the syntax, classes, and then about pointers. Once you get that down, then understanding the concept of OOP becomes more easy and you begin to take advantage of it. That's probably why all you see is people learning "C plus classes." Because taking on the whole new language is big enough, learning OOP is further down the road. Anyway, procedural code with classes is still a nice thing IMO.


Title: C/C++, which one first
Post by: na_th_an on June 05, 2006, 03:10:26 PM
That's the #1 reason why there's so much shitty code to maintain everywhere.

I work developing new software, but of course sometimes I have to maintain, expand old software already in use. Well, people code like crap. That's the thing. If people learned OOP properly, my life would be ten times easier.

The problem in all these discussions is that people here always think about the latest bedroom game they are coding. I'm talking about big projects, with 20 people involved. Now tell me how good designed OO isn't a must. 'Cause it is.

My claim is that, if you want to master the procedural paradigm, go for a procedural language such as C, Pascal or BASIC. If you want to master the OO paradigm, then try Java or proper C++. Don't mix things.

Radical Racoon: you're wrong. OOP aint' procedural. You are mixing therms, I think you mean "imperative". Procedural comes from "procedures". In OOP you don't have procedures. You have things that look like procedures but are NOT procedures. See? That's the problem! People have the concepts completely messed up and that's why there's so much crappy C++ coding around.

I'm not telling you that you code bad, I'm just talking big words for big scale projects. I think that you, at home, can code as shitty as you want (heck, I DO!), but, at least, you must know how to do things properly.


Title: C/C++, which one first
Post by: Radical Raccoon on June 05, 2006, 03:17:49 PM
Procedures are subs, functions, methods, aren't they?  :???:

The only difference (from my current knowledge) is that in C++ classes 1 procedure is created per instance (unless it's static) whereas only 1 procedure exist in procedural code the whole time and does not belong to any specific structure. But please let me know if there's more.

Still, I wouldn't blame that issue for the main cause of bad code. Bad code has many more other influences than just that (bad team coordination, source control, just plain sucking, etc.). Not that learning the proper concepts wouldn't help or anything, just saying.


Title: C/C++, which one first
Post by: Anonymous on June 05, 2006, 04:22:14 PM
I think what na_th_an is saying is that good c++ ISNT procedure/method based. methods are just one aspect of OBJECT-based programming, which is what you really should focus on with c++.


Seriously, "bad code" doesn't happen from bad management, that's the point of OOP. You could design an object completely autonomous from other objects, and it will interface exactly the same with anything that calls it, or that conatins it through composition.

Sure you can write macro hacks and whatever to simulate it but, the point is the capability is BUILT IN through OOP, and that's the point, to save you time from doing the same pointless crap over and over and over and over.


Title: C/C++, which one first
Post by: na_th_an on June 06, 2006, 04:09:39 AM
The difference is that a program coded in a procedural languages is made of procedures which call other procedures plain and simple. A program in an OO language is based on objects which produce other objects. Of course, at the end of the day, it's all about code you call to be executed - but it's the way you think what should be different. If you consider a OO program as a sequence of instructions and procedure calls (well, object method calls) you are missing the OOP paradigm completely, you are getting that "C + classes" I was talking about, not OOP.

There's a whole layer of abstraction you must adhere to and respect. The whole purpose of OOP is abstraction. "Work with black boxes you know what they take and what they produce, but not "how" - 'cause it doesn't matter". You usually work just using design patterns and combining them. The focus of OOP is getting a project composed by many parts in which you can replace any of those parts without affecting the rest of the system. Getting your things done in a way you can expand functionality without having to change a line. You know, just like when you install a plugin - you don't have to recompile the main program (well, at least if you are not using Linux :lol:) - in the same way you should be able to add functionality without having to "make room for it" in your existing code.

In OOP you have to think about interfaces. In a procedural language, when you call a procedure, you know which bit of code you are calling. In an OO language, you get an object and call to a method of its interface - but you don't know which bit of code it's running. Maybe you are processing a list of objects that are "geometrical" and you are just calling a "rotate(45)" to rotate each one 45 degrees right. But each object could be in fact a rectangle or a triangle, or a circle or a hexagon - each one with its own "rotate" method. You want your program the ability to process squares as well? Just add a new class "square" which implements the interface "geometrical" (this is - it gives an implementation to each method described in the interface) and you are done. Now there's support for squares. Nothing to be done in the other side.

If people understood OO correctly and coded it in the proper way, I would have no problems expading existing applications - but right now I'm stuck in the middle of a huge pile of shit :D everytime I touch something, another one gets broken!! AAAAARGGGHHH!!! (sorry, needed this rant - I'm overwhelmingly fed up with my current task at work).


Title: C/C++, which one first
Post by: Jofers on June 07, 2006, 08:54:33 AM
C.  There's something to be said for a language that's used to program every major operating system.  It's fundamentally important to learn because it's as close as you can get to the hardware in a high-level language.  I had to work in the spring with a guy who had learned C++ and not C on a C project.  It was a disaster, he couldnt figure out printf, couldn't handle strings, had trouble with pointers.  You have to learn core programming concepts in C before you tackle the abstract stuff, it's for your benefit.

That doesn't mean don't learn C++, as it is very featureful and useful, but if you're serious, then learn C first.


Title: C/C++, which one first
Post by: na_th_an on June 07, 2006, 09:35:36 AM
Listen to the yellow peanut, he's wise!

I agree 101% with Jofers.


Title: C/C++, which one first
Post by: Radical Raccoon on June 07, 2006, 11:24:04 AM
Quote from: "na_th_an"
The difference is that a program coded in a procedural languages is made of procedures which call other procedures plain and simple. A program in an OO language is based on objects which produce other objects. Of course, at the end of the day, it's all about code you call to be executed - but it's the way you think what should be different. If you consider a OO program as a sequence of instructions and procedure calls (well, object method calls) you are missing the OOP paradigm completely, you are getting that "C + classes" I was talking about, not OOP.

There's a whole layer of abstraction you must adhere to and respect. The whole purpose of OOP is abstraction. "Work with black boxes you know what they take and what they produce, but not "how" - 'cause it doesn't matter". You usually work just using design patterns and combining them. The focus of OOP is getting a project composed by many parts in which you can replace any of those parts without affecting the rest of the system. Getting your things done in a way you can expand functionality without having to change a line. You know, just like when you install a plugin - you don't have to recompile the main program (well, at least if you are not using Linux :lol:) - in the same way you should be able to add functionality without having to "make room for it" in your existing code.

In OOP you have to think about interfaces. In a procedural language, when you call a procedure, you know which bit of code you are calling. In an OO language, you get an object and call to a method of its interface - but you don't know which bit of code it's running. Maybe you are processing a list of objects that are "geometrical" and you are just calling a "rotate(45)" to rotate each one 45 degrees right. But each object could be in fact a rectangle or a triangle, or a circle or a hexagon - each one with its own "rotate" method. You want your program the ability to process squares as well? Just add a new class "square" which implements the interface "geometrical" (this is - it gives an implementation to each method described in the interface) and you are done. Now there's support for squares. Nothing to be done in the other side.

If people understood OO correctly and coded it in the proper way, I would have no problems expading existing applications - but right now I'm stuck in the middle of a huge pile of #*&$ :D everytime I touch something, another one gets broken!! AAAAARGGGHHH!!! (sorry, needed this rant - I'm overwhelmingly fed up with my current task at work).

C++ is still a sequence of instructions and method calls. That's how you build the classes. You have a sequence of instructions inside you methods that execute the method. No, you don't have to know which bit of code you are calling to use it, but to make you're own yes. You don't have to really know what's inside a procedure call either to use it, just as long as you know what it's for and what it's suppose to take in. It's never 100% abstract, because at some level you have to instantiate the first class, then call it's method, etc. But aren't you trying to reach the same objective with C? When you code a C procedure don't you want to have it to where the person who is calling it doesn't have to worry about "how" the procedure works, just what it's supppose to takes and what it's suppose to do? That's why I liked moving from QB to C++, because I could implement that concept better with an OOP language. Still, it didn't save me (if you suck, you suck). I haven't been able to finish a game in it because I did infact mix the concepts, creating messy and unmanageable code, but I did eventually learn (maybe not perfect yet, but getting there ;)). So if learning C can save you from that hassle, then I guess it's the way to go. But the conclusion we've all come to is that learning the proper programming concepts is more important than the language itself.

Since we are speaking of C, where can I find some good compilers for it?  :wtnod:
I have Visual Studio 2003, but that only allows for C++ and C# programs as far as I know.


Title: C/C++, which one first
Post by: stylin on June 07, 2006, 12:49:39 PM
jofers: why is it a prerequisite to learn C before a higher-level language? IMO, the abstract stuff - that is, the concepts shared by generally all programming languages - is more important than learning the intricacies of C. In other languages, like C++, pointers are less important, but are still used all the time. Any C++ programmer that doesn't know how to use pointers, is the same C programmer that doesn't - it doesn't matter the language used.

More to the point, printf and C-style strings are largely C-specific, but can be used in C++ as well (you just don't typically need to). I fail to see how knowledge of C strings and the C stdlib is a benefit to learning how to think abstractly. If anything, dealing with those kinds of things detract from thinking abstractly.

(I wouldn't put much stock into a programmer that fails to understand how to read the documentation for printf anyway, but that doesn't mean C++, or any other language for that matter, made him/her that way, and I don't think it encourages it, either)

Radical Raccoon: try compiling some *.c files with your VS.


Title: C/C++, which one first
Post by: relsoft on June 07, 2006, 11:27:24 PM
To me, the more languages you learn the better.


Title: C/C++, which one first
Post by: NecrosIhsan on June 08, 2006, 02:11:34 AM
stylin, you missed jofers' point by so far that you'd get frequent flyer miles.


Title: C/C++, which one first
Post by: na_th_an on June 08, 2006, 04:33:28 AM
Quote from: "Radical Raccoon"
No, you don't have to know which bit of code you are calling to use it, but to make you're own yes.


You make your own, and then forget about it when using it. It's a must. You can't depend on the implementation. It has to be a black box for you, even if you coded it.

Quote from: "Radical Raccoon"
It's never 100% abstract, because at some level you have to instantiate the first class, then call it's method, etc.


And how isn't that 100% abstract? You just use those functions which are in the interface, i.e. the public symbols exported by the class. That's 100% abstract.

Quote
But aren't you trying to reach the same objective with C? When you code a C procedure don't you want to have it to where the person who is calling it doesn't have to worry about "how" the procedure works, just what it's supppose to takes and what it's suppose to do?


The difference between procedural and OO is simply that in an procedural language the person may or may not use encapsulation and may or may not respect your "rules". In an OO language, it's a must. You can define your class in a way the people who are gonna use it have to do it properly.

If I'm using a library to manipulate lists in C and the person who coded it tells me "You just use the listGet and listPut functions to access the list" ... Well, I can notice that the list is created using an array, and I could address the array directly to save function calls.

If I'm using a library to manipulate lists in Java and the person who coded it defined as "public" just the listGet and listPut methods, I can't do shit with the array :D

That's the difference.

Quote from: "Radical Raccoon"
That's why I liked moving from QB to C++, because I could implement that concept better with an OOP language. Still, it didn't save me (if you suck, you suck). I haven't been able to finish a game in it because I did infact mix the concepts, creating messy and unmanageable code, but I did eventually learn (maybe not perfect yet, but getting there ;)). So if learning C can save you from that hassle, then I guess it's the way to go.


I think we are mixing a couple of conversations together :D We are talking about two different topics in this thread:

1.- Learn C first? My opinion is yes. You learn tons of lo-level stuff which may come handy in the future.

And

2.- Proper OOP: It's more than procedural + classes. That's why I usually bash C++, 'cause I don't find it a good learning language as it allows  "procedural + classes" programs. I mean, on schools they should teach OOP using Java, for example (I'm talking about theory, I mean, teaching Object Oriented Programming - the best language to teach the concepts is not C++).

Learning C is good 'cause you basicly learn how memory works, how variables work, how strings work, how to deal with memory addresses, to manage memory yourself, etcetera. I think that a C++ coder who knows good C can do better. C is almost like "syntax-friendly" assembly. It's like coding in assembly but with readable structure and syntax :lol:

Quote
But the conclusion we've all come to is that learning the proper programming concepts is more important than the language itself.


That's the point. Then it's a matter of learning different syntaxes.

Quote
Since we are speaking of C, where can I find some good compilers for it?  :wtnod:
I have Visual Studio 2003, but that only allows for C++ and C# programs as far as I know.


I like DevC++, it fits me good. It comes with a C and C++ compiler. I find it pretty stable and it's doesn't take over all your HDD like VS :D


Title: C/C++, which one first
Post by: stylin on June 08, 2006, 05:43:32 AM
Quote from: "na_th_an"
If I'm using a library to manipulate lists in C and the person who coded it tells me "You just use the listGet and listPut functions to access the list" ... Well, I can notice that the list is created using an array, and I could address the array directly to save function calls.

You're assuming the implementation is exposed. If you only had a listCreate that returned some form of handle, you now are forced to use listGet and listPut. Is C bad because it let's you - like C++ - create an 'unsafe' level of encapsulation ?

Quote
2.- Proper OOP: It's more than procedural + classes. That's why I usually bash C++, 'cause I don't find it a good learning language as it allows  "procedural + classes" programs. I mean, on schools they should teach OOP using Java, for example (I'm talking about theory, I mean, teaching Object Oriented Programming - the best language to teach the concepts is not C++).

I would agree that C++ isn't the best language to learn OOP. I didn't learn C++ as a 'C with classes", though, so I cannot relate to your statement. Just because C++ does not embody all that is OOP and allows you to do non-OO things, I fail to see how that is a reason to learn C beforehand. C++ has alot of shortcomings, but - for a beginner - C has alot more that can get you in alot more trouble. (and cause that much more frustration)

Quote
Learning C is good 'cause you basicly learn how memory works, how variables work, how strings work, how to deal with memory addresses, to manage memory yourself, etcetera. I think that a C++ coder who knows good C can do better. C is almost like "syntax-friendly" assembly. It's like coding in assembly but with readable structure and syntax :lol:

As I - and you - have said before, those things are allowed in C++ as well. I don't see how cutting your teeth on pointers in C++ is different than doing it in C. As a student of C++ you realise the procedural/OO/etc. nature of the language. Pointer use may be more prevelant in C, but again, how is that an advantage over C++? Dealing with low-level memory issues just isn't something a beginning programmer should be worrying about, IMO. C forces you to worry about it - C++ let's you worry about it when you're ready. :) (I mean ready as in you understand the need for the lower-level access. Moreover, C++ allows you to deal with those memory management issues in a completely OO way. There's no reason to stray from OOP if you're concerned/interested in low-level memory management)

Quote
But the conclusion we've all come to is that learning the proper programming concepts is more important than the language itself.

The argument here, as I understand it, is: What concepts are most important to the beginner? and Between C and C++, which language is better suited to learn those concepts?


Title: C/C++, which one first
Post by: na_th_an on June 08, 2006, 05:52:23 AM
Mixing therms. Read my prev post, we are having two different conversations here which are not related.

1.- Learning C before C++ is good?

and

2.- Proper OOP.

My points fo view:

1.- Yes 'cause it's good to understand how stuff works.
2.- C++ is not good for learning OOP. It's good when you know OOP.

Quote from: "stylin"
You're assuming the implementation is exposed. If you only had a listCreate that returned some form of handle, you now are forced to use listGet and listPut. Is C bad because it let's you - like C++ - create an 'unsafe' level of encapsulation ?


You missed my point. I was trying to explain the main differences between OOP and procedural. Nothing else. And that was just an example. Don't discuss for the sake of it ;)


Title: C/C++, which one first
Post by: stylin on June 08, 2006, 06:19:06 AM
1. Learning C before C++ is good?
It's good in much the same ways as learning assembler before C. Ie, learning a language is always beneficial, but I don't think there's a need to learn C to be able to get the most out of C++, as I typically use very little from it.

2. Proper OOP.
Program in Java. If you want a bigger toolbox, program in C++.


Title: C/C++, which one first
Post by: Radical Raccoon on June 08, 2006, 06:35:36 AM
Quote from: "stylin"
1. Learning C before C++ is good?
It's good in much the same ways as learning assembler before C. Ie, learning a language is always beneficial, but I don't think there's a need to learn C to be able to get the most out of C++, as I typically use very little from it.

2. Proper OOP.
Program in Java. If you want a bigger toolbox, program in C++.

Or program in C#. C# is much more cleaner and efficient as an OOP language (when compared to C++), and doesn't come with all that excess baggage that you find with C++. I've used both, and C# is way more easier of a programming language to use. But anyways, I've spent enough time on this thread; time for me to move on.

Nathan: Well said and thanks for the compiler info.  :D


Title: C/C++, which one first
Post by: na_th_an on June 08, 2006, 06:56:14 AM
C# is Java with C++ syntax :lol:

And VB.NET is Java with VB syntax.

M$ is wise :lol:


Title: C/C++, which one first
Post by: Anonymous on June 08, 2006, 07:34:36 AM
Seriously, IMO, learn FB first. It's getting to the point where if you learn it right, you will learn a very clean (option ;p) explicit way of programming. and Lots of concepts carry over. You can use pointers, overloading, zStrings, bit shifts, recursion, typedef, etcetc.

All I know about c and c++ I learned with a foundation of knowledge in FB.


Title: C/C++, which one first
Post by: NecrosIhsan on June 08, 2006, 03:31:09 PM
Well, it's easy to see who the C++ zealot is in this thread... :laughing: