C or C++

Vintendo · 2009-04-03 12:02:06

Hi everybody,

I am a computer science student who is bored. I am learning java at school but it's going to slow, I get it all. So I want to learn a new language. I tried python but I dont like it. Haskell is like magic and I dont have that much energy to put into it.
Now I want to choose between C++ and C. C++ seems like C with a lot of extra stuff in it. What do you recommend for a little cli programming? C doesnt know classes right?

peets · 2009-04-03 12:05:46

Isn't there another thread with this exact title?

C is fun because linux is written in C; all system calls are C functions.

C++ is like Java, but you have to do memory management yourself.

Allan · 2009-04-03 12:06:25

I think C is very similar to java in terms of programming style. C would be a lower level language for you to learn.

thomasknowles · 2009-04-03 12:06:56

Depends on the programming paradigm you are comfortable with. C is a procedural language thus you would not get the object orientated goodies such as information hiding, data abstraction, encapsulation, modularity, polymorphism, and inheritance (I pinched that last bit from wikipedia).

Vintendo · 2009-04-03 12:23:37

@feels I thought so but I couldnt find it.

I think I am going to go with C, nice and low level. Thanks for the incredibly fast responses!

pauldonnelly · 2009-04-03 21:37:50

Vintendo wrote:

Haskell is like magic and I dont have that much energy to put into it.

Then stay far away from C++. It will suck you dry. Of your two choices, go with C, but that doesn't mean there aren't better choices.

http://www.cs.cmu.edu/~dst/LispBook/index.html
http://gigamonkeys.com/book/

jumzi · 2009-04-03 23:24:27

Pfft i wanna deacently learn myself C and C++... I hate that i have so much else todo atm... tcp/ip, html, css and the alike, booring ground stuff... (Altought it isnt booring at all )

Husio · 2009-04-04 18:51:18

I like C becouse it's very simple. That's why I don't like C++. Becouse it's overflowed with so many features..

Xilon · 2009-04-05 02:57:52

peets wrote:

Isn't there another thread with this exact title?

Yes, and it's only a few days old.

See that thread for my opinions. Basically go for C. if you want a C language that's OOP, go for Objective-C, not C++.

vkumar · 2009-04-05 05:25:42

From what I've seen so far, using object orientation always introduces more bloat than is necessary. Encapsulation, data hiding, inheritance - none of it would be necessary if you had good coders who comment their stuff!

I'll use c++ when a project demands it, but C feels more natural to me for some reason..

If you really want OOP, do it the hardcore way :
http://www.planetpdf.com/codecuts/pdfs/ooc.pdf

pauldonnelly · 2009-04-05 18:39:09

vkumar wrote:

From what I've seen so far, using object orientation always introduces more bloat than is necessary. Encapsulation, data hiding, inheritance - none of it would be necessary if you had good coders who comment their stuff!

Inheritance and type-based method dispatch can be pretty helpful. I wouldn't want to operate on a family of data types without it. I wouldn't choose a C++-style object system though.

dalingrin · 2009-04-05 20:22:22

I wouldn't discredit c++ completely. If you plan to be a professional programmer, I highly recommend learning it at some point.
That said, if I were you, I would continue with Java. It doesn't hurt anything to read ahead and/or start getting involved with open source projects.
Once you know Java forward and back it will be incredibly easy to work in another language. Right now your time would be better spent understanding programming in general.
The language used is only a small part of what makes up programming.

btw, You don't like Python? Thats blasphemy!

Last edited by dalingrin (2009-04-05 20:26:48)

vkumar · 2009-04-05 21:10:08

@dalingrin: if the "you don't like Python?" question was directed at me; no, I love Python. I don't know what I'd do without it. Else, disregard that .

Inheritance and type-based method dispatch can be pretty helpful.

So can comments. Except comments don't restrict you from using the language however you like.
In a rigid object orientation paradigm (like Java's/C++'s), you're forced to baby the compiler with an endless stream of idioms - and this limits your flexibility. It wouldn't be so bad if there was type inferencing - something similar to Boo's approach...

OOP makes a lot of sense for large projects with many data types and many contributers, but for simple things, it's just overkill.

I wouldn't choose a C++-style object system though.

And as far as object systems go, what's wrong with C++'s? It's a bit trickier than Java's, but it gets the job done..

pauldonnelly · 2009-04-06 01:09:56

vkumar wrote:

Inheritance and type-based method dispatch can be pretty helpful.
So can comments. Except comments don't restrict you from using the language however you like.
In a rigid object orientation paradigm (like Java's/C++'s), you're forced to baby the compiler with an endless stream of idioms - and this limits your flexibility. It wouldn't be so bad if there was type inferencing - something similar to Boo's approach...
OOP makes a lot of sense for large projects with many data types and many contributers, but for simple things, it's just overkill.

I don't think objects impose much of a restriction, and the features I mentioned above can be very helpful when you have a family of related types. I'm not sure what type inferencing has to do with it.

vkumar wrote:

I wouldn't choose a C++-style object system though.
And as far as object systems go, what's wrong with C++'s? It's a bit trickier than Java's, but it gets the job done..

It's inside out, for no reason I can discern. It goes overboard with the "information hiding" stuff too — first they add private members, and then they turn around and add a way to defeat it. Plus

EDIT: I guess I posted too soon. I'm not sure what "Plus" was, but it was probably something about how they didn't integrate method dispatch, overloading, and templates, which are all really trying to do the same thing: to choose the appropriate code for a given type.

Last edited by pauldonnelly (2009-04-06 01:16:19)

neosisani · 2009-04-06 22:06:38

thomasknowles wrote:

Depends on the programming paradigm you are comfortable with. C is a procedural language thus you would not get the object orientated goodies such as information hiding, data abstraction, encapsulation, modularity, polymorphism, and inheritance (I pinched that last bit from wikipedia).

C has information hiding, it is called static methods and variables.
http://dirac.org/linux/writing/lkmpg/2. … tml#AEN517

C is low-level and works.
Java is oop and works (and i don't like it)
C++ is ugly hybrid, and yet it works too.

For small stuff i think C is better (less then 1000 lines of code). On the other hand i never really had to use oop due too shear project size. C++ is nice because it has fancy goodies such as STL and operator overloading, so you don't have to go trough pain of implementing heaps and sorts and stuff.

Xilon · 2009-04-07 18:33:15

pauldonnelly wrote:

vkumar wrote:
From what I've seen so far, using object orientation always introduces more bloat than is necessary. Encapsulation, data hiding, inheritance - none of it would be necessary if you had good coders who comment their stuff!
Inheritance and type-based method dispatch can be pretty helpful. I wouldn't want to operate on a family of data types without it. I wouldn't choose a C++-style object system though.

If you want to operate on a family of data types, I'd suggest using a language that is focused on data - a functional one.

pauldonnelly · 2009-04-07 19:55:36

Xilon wrote:

If you want to operate on a family of data types, I'd suggest using a language that is focused on data - a functional one.

That doesn't make any sense.

vkumar · 2009-04-10 02:46:59

With oop languages, it's easier to make things foolproof - but imho a by-product is a fugly syntax and verbose code.. When I said "restrictive" earlier, I meant that the syntax is painful at times (bad use of the word, I'm sorry).

If you have a large codebase with many different classes (a family, as you say), I think an oop language would be great.

I'm not sure what type inferencing has to do with it.

Type inferencing would make any oop language a lot easier to code in, and it's feasible to implement - it's been done plenty of times before. I'm actually working on a translator that supports this, atm =/. I have a lisp-like grammar defined (lexer is done), and the code is designed so that you can implement parsers that will translate to any language you choose. The intent is to provide a simple(r) language that you can write something in quickly, and then have translated to another language (e.g Java/C++) for compilation/development.

@dalingrin: it's written in Python

pauldonnelly · 2009-04-10 03:46:29

vkumar wrote:

I'm not sure what type inferencing has to do with it.
Type inferencing would make any oop language a lot easier to code in, and it's feasible to implement - it's been done plenty of times before.

Oh, are you assuming that an OOP language should have static typing? Ick. Forget that; just give my dynamic typing and get out of my hair.

But I agree that if you do have static typing, it's nuts not to include type inference.

Xilon · 2009-04-10 04:42:01

pauldonnelly wrote:

vkumar wrote:
I'm not sure what type inferencing has to do with it.
Type inferencing would make any oop language a lot easier to code in, and it's feasible to implement - it's been done plenty of times before.
Oh, are you assuming that an OOP language should have static typing? Ick. Forget that; just give my dynamic typing and get out of my hair.
But I agree that if you do have static typing, it's nuts not to include type inference.

Static typing is better than dynamic typing. If a language has static typing you can still do dynamic typing (in most cases), but not the other way around.

wuischke · 2009-04-10 05:34:07

Xilon wrote:

Static typing is better than dynamic typing. If a language has static typing you can still do dynamic typing (in most cases), but not the other way around.

This quote confuses me. Could please explain it with examples (you can send me a message, too), for the sake of my understanding?

On topic: I'm surely not the worst programmer and I've used both C and C++ a lot, but I wouldn't recommend either.
Knowing and understanding C is very important (learn a bit about assembler, too) to gain and understanding of code efficiency - imho. But unless you are writing low-level stuff or things where performance matters, it's just too verbose and it's too easy to make thousands of errors.
C++ is like PHP: You'll love it at first, especially when you come from C, you'll start groaning a bit when you learn about all these triple-assignments for operators and once you reached a certain level, you'll either hate the language or you'll defend it as the best thing after sliced bread. This is not to say it doesn't have its applications - I choose it for a recent project, which had to run on various older Unix systems - and the big number of libraries and high-quality compilers and developmental tools can make working with it fairly enjoyable.

My recommendation: Learn something where you actually learn something - Scala is an obvious candidate for a Java programmer. It'll teach you functional programming, concurrency and should still be fairly familiar. Erlang does this as well, but features a different syntax. Furthermore I believe everyone should know at least some advanced Lisp for the concepts you learn.

C# is the mainstream language where you actually can apply the knowledge gained when learning functional programming (this is very frustrating in C++), at least in VS2008. It took me longer to learn the basic syntax than to write a Memoization-optimization.
Those "new" scripting languages Ruby and Python (actually JavaScript a.k.a. obfuscated Scheme, too) will teach you new ways to think about programming as well and a stack-based language like Factor won't hurt either.

I'm currently learning Smalltalk and I can't help myself but to admire its design, although I'll probably never use it in practice.

Xilon · 2009-04-10 16:25:11

wuischke wrote:

Xilon wrote:
Static typing is better than dynamic typing. If a language has static typing you can still do dynamic typing (in most cases), but not the other way around.
This quote confuses me. Could please explain it with examples (you can send me a message, too), for the sake of my understanding?.

It's simple really. There are a lot of concepts in static languages that emulate dynamic typing to a degree, for instance generics in Java, or templates in C++. However these are typically hacks due to the lack of language-level support. The best example I can give at the moment is Objective-C. It's a superset of C and is therefor statically typed. However, much like void* in C, it has an "id" type. This type means "an object". Objective-C is message based, like Smalltalk, which means that it additionally allows for duck-typing, ala Python. With "an object" you can do any type checking you want, via introspection. However, at the same time you can say "I want a string, or a descendent of a string" to have compile-time type checking.

- (void) doSomethingWithObject(id object, NSString *aString) {
    if([object isKindOfClass:[NSString class]]) {
        NSString *foo = (NSString *)object;
        if([foo isEqualToString aString]) {
            printf("lol\n");
        } else {
            printf("%s\n", [foo utf8String]);
        }
    } else {
        [object print];
    }
}

The example doesn't show good code or good design, but it does show the flexibility of the id data type. It mostly shows duck typing, but also runtime checking. The definitions of dynamic typing, duck typing and weak typing aren't all that clear to me and they seem to blur, so some of the terminology I use may be inaccurate.

C's void* is similar to an extent, but it's more code-time checking rather than runtime-checking, since it masks the true type, rather than making it generic (or using type inference).

I'm not saying that dynamic typing in static languages is easy or extremely readable, but it is possible. Taking the example of cPython, all Python variables do have a type (PyObject), which provides information about it. With this information it is possible to do runtime checks and so forth.

Last edited by Xilon (2009-04-22 06:23:07)

pauldonnelly · 2009-04-10 20:33:32

Xilon wrote:

Static typing is better than dynamic typing. If a language has static typing you can still do dynamic typing (in most cases), but not the other way around.

So what? Dynamically typed languages let me do dynamic typing in all cases, without hacking around the language. Therefore they are better. IMO, static typing just catches one trivial class of bugs at compile time rather than run-time, the utility of which is dubious when it requires adding a bunch of type annotations. I'd rather fix just my broken code than preemptively debug my correct code.

You need to accept that a preference for static typing vs. dynamic is a dispositional thing rather than an absolute better/worse relation. Some people have a massive hardon for compiler-checked type-correctness, and that's fine, but not everyone enjoys bondage play.

vkumar · 2009-04-11 04:21:30

Some people have a massive hardon for compiler-checked type-correctness, and that's fine, but not everyone enjoys bondage play.

Well said.

wuischke · 2009-04-11 07:54:17

@Xilon: Thank you, I understand now what you mean.

I like languages which make it hard to create accidental errors. Giving me the possibility to avoid errors is nice, but too much work on my side. (I'm lazy, as all programmers should be.) For instance, I prefer foreach/map over explicitely iterated loops with bounding checks and exceptions.

I personally like Haskell's type system. I haven't written much code in Haskell, but everything I've done was of "if it compiles, it works" quality (except for algorithm errors, of course).

Arch Linux

#1 2009-04-03 12:02:06

C or C++

#2 2009-04-03 12:05:46

Re: C or C++

#3 2009-04-03 12:06:25

Re: C or C++

#4 2009-04-03 12:06:56

Re: C or C++

#5 2009-04-03 12:23:37

Re: C or C++

#6 2009-04-03 21:37:50

Re: C or C++

#7 2009-04-03 23:24:27

Re: C or C++

#8 2009-04-04 18:51:18

Re: C or C++

#9 2009-04-05 02:57:52

Re: C or C++

#10 2009-04-05 05:25:42

Re: C or C++

#11 2009-04-05 18:39:09

Re: C or C++

#12 2009-04-05 20:22:22

Re: C or C++

#13 2009-04-05 21:10:08

Re: C or C++

#14 2009-04-06 01:09:56

Re: C or C++

#15 2009-04-06 22:06:38

Re: C or C++

#16 2009-04-07 18:33:15

Re: C or C++

#17 2009-04-07 19:55:36

Re: C or C++

#18 2009-04-10 02:46:59

Re: C or C++

#19 2009-04-10 03:46:29

Re: C or C++

#20 2009-04-10 04:42:01

Re: C or C++

#21 2009-04-10 05:34:07

Re: C or C++

#22 2009-04-10 16:25:11

Re: C or C++

#23 2009-04-10 20:33:32

Re: C or C++

#24 2009-04-11 04:21:30

Re: C or C++

#25 2009-04-11 07:54:17

Re: C or C++

Board footer