Qbasicnews.com
August 19, 2019, 02:25:07 AM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: Back to Qbasicnews.com | QB Online Help | FAQ | Chat | All Basic Code | QB Knowledge Base
 
   Home   Help Search Login Register  
Pages: 1 [2] 3 4
  Print  
Author Topic: C/C++, which one first  (Read 17625 times)
stylin
Ancient QBer
****
Posts: 445


« Reply #15 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? Shocked

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

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.
Logged

stylin:
TheAdventMaster
Ancient Guru
****
Posts: 671


« Reply #16 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 Tongue

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.
Logged
LooseCaboose
I hold this place together
*****
Posts: 981



« Reply #17 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 ;-)
Logged

esus saves.... Passes to Moses, shoots, he scores!
Anonymous
Guest
« Reply #18 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.
Logged
neuro
Forum Regular
**
Posts: 114



WWW
« Reply #19 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
Logged

ignatures suck
stylin
Ancient QBer
****
Posts: 445


« Reply #20 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.
Logged

stylin:
Radical Raccoon
I hold this place together
*****
Posts: 914



WWW
« Reply #21 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.
Logged

LooseCaboose
I hold this place together
*****
Posts: 981



« Reply #22 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.
Logged

esus saves.... Passes to Moses, shoots, he scores!
NecrosIhsan
Been there, done that
*****
Posts: 1191



« Reply #23 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.
Logged

\__/)
(='.'=) Copy bunny into your signature to
(")_(") help him gain world domination.
stylin
Ancient QBer
****
Posts: 445


« Reply #24 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).
Logged

stylin:
na_th_an
*/-\*
*****
Posts: 8244



WWW
« Reply #25 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" Cheesy

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).
Logged

SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
Radical Raccoon
I hold this place together
*****
Posts: 914



WWW
« Reply #26 on: June 03, 2006, 08:17:07 PM »

C isn't object oriented?  Shocked
Logged

TheAdventMaster
Ancient Guru
****
Posts: 671


« Reply #27 on: June 03, 2006, 09:13:52 PM »

Quote from: "Radical Raccoon"
C isn't object oriented?  Shocked
. . . ?
Logged
Radical Raccoon
I hold this place together
*****
Posts: 914



WWW
« Reply #28 on: June 04, 2006, 01:16:54 AM »

Quote from: "TheAdventMaster"
Quote from: "Radical Raccoon"
C isn't object oriented?  Shocked
. . . ?

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

LooseCaboose
I hold this place together
*****
Posts: 981



« Reply #29 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 procedural 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.
Logged

esus saves.... Passes to Moses, shoots, he scores!
Pages: 1 [2] 3 4
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!