What can C do that C++ cant

[pacerier]

ok so i've heard that C++ has a ton of advantages that C has. is it true that there is nothing that C can do which C++ cant, if that's the case, then am i right to say that actually learning C is a waste of time we should just learn C++

[mcleano]

then am i right to say that actually learning C is a waste of time we should just learn C++

You're going to get some interesting replies to that one haha. Also,

C

You shoot yourself in the foot.

C++

You accidently create a dozen instances of yourself and shoot them all in the foot. Providing emergency medical assistance is impossible since you can't tell which are bitwise copies and which are just pointing at others and saying "That's me, over there."

[moorecm]

Knowing both C and C++ is definitely beneficial, although I would recommend focusing on learning C++. Throughout the process you will inevitably begin to piece together some of the differences. If, or more likely when, you need to work on a project written in C you'll get by.

Personally, I wouldn't even consider using C for new development but in the real world new development isn't as common as we would all like to think.

[chrisname]

C programmers have the advantage of not being asked stupid questions like this.

[EvanEjk]

You can program more small things (microchips) with C.

[chrisname]

That isn't true at all. Give me one reason why you can program "more small things [...] with C" than with any other language.

Edit: and with that rationale, you could say that programming in Assembly is always better. The problem there is that you have to know the assembly language for that "microchip," and the developer of it has to provide an assembler.

[Disch]

Aside from a few minor differences, there's nothing C can do that C++ can't. About the only things I can think of are:

1)

int foo = Something();

int array[ foo ];  // C++ can't do this, but C can IIRC 

Of course C++ provides alternatives to do the same thing:

vector<int> array(foo); // similar code in C++ 

2)

C is more friendy for making external libraries. A DLL compiled in C will likely work in any C/C++ program made in any other C/C++ compiler. Whereas DLLs made with C++ often only work in C++ programs made in the same C++ compiler (or so I hear -- I never actually faced this issue head on and don't know the details about it).

-------------

On the other hand, C++ has tons of additional stuff that C can't do. Templates, polymorphism, operator overloading, etc, etc. C can mimic all of these things with different syntax, and there's no program you can write in one language that can't be written in the other language... so they're both equally capable. C++ just provides more tools/options.

I'm not a fan of straight C at all. Personally I don't know why anyone would choose it over C++ these days unless they can't find a C++ compiler for X obscure platform. Even if you don't like a lot of what C++ adds, you can still compile in C++ and do mostly "C-ish" code... leaving your doors open to take something C++ offers at a future time.

Does this mean that C++ is a better language than C? That depends who you ask. Personally I'd say yes, but I'm sure there's a lot of people that would disagree with me.

[chrisname]

there's no program you can write in one language that can't be written in the other language... so they're both equally capable.

Not true. There are plenty of things you can write in C or C++ that you can't do in Python.

Does this mean that C++ is a better language than C? That depends who you ask. Personally I'd say yes, but I'm sure there's a lot of people that would disagree with me.

I wouldn't say "better." It has advantages over C, certainly, but I wouldn't say it was better.

DLLs made with C++ often only work in C++ programs made in the same C++ compiler (or so I hear -- I never actually faced this issue head on and don't know the details about it).

I'm not sure, but I would hazard a guess at that having something to do with the way C++ constructors and destructors work. I would assume the reason that C++ program X and C++ library Y can't be linked together when compiled would have to do with calling conventions. With GCC, arguments are pushed on the stack in reverse order (right to left) and the return value is stored in eax. But some compilers do it differently, some push the return value onto the stack, etc. etc.

[PanGalactic]

chrisname wrote:

Not true. There are plenty of things you can write in C or C++ that you can't do in Python.

Such as?

[Disch]

Not true. There are plenty of things you can write in C or C++ that you can't do in Python.

Where did Python come from? I was talking about C vs. C++

I wouldn't say "better." It has advantages over C, certainly, but I wouldn't say it was better.

Well that was an opinionated statement so I figured there'd be people that disagreed.

The way I see it, most code written in C will compile in a C++ compiler... so why not just use a C++ compiler all the time in case you ever want something C++ specific?

Using a straight C compiler just seems silly.

[chrisname]

@PanGalactic,
Such as something that has to interface with hardware directly. You also can't write stand-alone executables in Python AFAIK. I don't know of an AOT compiler for Python. At the same time, Python doesn't need one.

Disch wrote:

Where did Python come from? I was talking about C vs. C++

When you said anything that can be written in one language can be written in another, I decided it meant we could discuss any obscure language I wanted.

The way I see it, most code written in C will compile in a C++ compiler... so why not just use a C++ compiler all the time in case you ever want something C++ specific?

I'm not entirely sure about this, but doesn't C++ have constructors and destructors for primitive types like ints? If so, then that would mean you'd have to call a function just to create an integer.
Something as simple as
int i = 0;
in C, would usually compile to something like
mov i, 0
or

xor eax, eax
mov i, eax

if the compiler was any good

But in C++, if I'm right about primitives and constructors (I hope I'm not, though), that would probably compile to something like

mov eax, i
push eax
call int_constructor
pop eax
mov i, eax

In the first example, if the compiler was smart enough to optimize assigning 0 to a variable into a xor, that would produce two very quick instructions (otherwise the CPU has to pull 0 out of the data cache, work out the absolute memory location for i, and then put zero there) to make i 0. In the second example, the compiler had to push i onto the stack (in a very round-about way because I don't think push i or pop i would work), call the constructor, and then get the new value for i off of the stack.

[Disch]

But in C++, if I'm right about primitives and constructors (I hope I'm not, though), that would probably compile to something like

I find that extremely far fetched. That'd be like saying it calls a subroutine to do assignments and + operators because it overloads operators for primitive types.

[chrisname]

Yeah, but I thought I read somewhere that it has constructors for primitives. But I doubt the reliability of my memory, to be honest. I don't see why there would need to be a constructor or destructor for primitive types.

[PanGalactic]

@chrisname: is that more a limitation of your operating system API or of the language itself?

[chrisname]

Is that a rhetorical question?

AFAIK Python strives to provide an abstracted interface to every operating system, such that code written for system X will work on system X, system Y and system Z. So if Python doesn't provide a function in the os module which the operating system you're on provides in it's C API; it's probably because another of the OSes Python supports doesn't have that function. So it could be a limitation of another operating system's API... although, tbh, it seems silly not to support an API function on one system just because it doesn't exist on another... You wouldn't write C code that calls CreateProcess if you wanted the program to work on POSIX systems. I suppose, then, you could say it's a limitation of both.

[PanGalactic]

@chrisname:

The only way to interface with hardware directly in Linux is to write an device driver. Linux is written in C, and therefore device drivers must be written in C. There is no inherent limit in the Python language preventing direct access to hardware (especially given the ctypes library). The only thing that is special about C in the context of hardware access is that is what most modern operating systems require.

To reinforce this point, you cannot write an operating system like Linux purely in C. There is a decent amount of assembly language in the boot code of Linux to get the hardware into the proper state to execute an operating system and in the low-level functions required for things like port I/O and interrupt handling. Device drivers make use of those same assembly language functions that are part of the OS kernel API. Those same low-level functions would have to be implemented outside of the core Python language as well.

[chrisname]

Yes, I know, that is why I said that it wasn't true that any program that can be written in one language can be written in another. I simply used Python as an example.

The only way to interface with hardware directly in Linux is to write an device driver.

You can write kernel modules, though. I've done that (only ones that printed "Hello world!" and "Goodbye World!"); it was quite fun, even if only to see

$ dmesg | tail
[...]
Hello, world from init_hellomod@23:20:19
Goodbye, world from exit_hellomod@23:21:18

(those times are compile times from __TIME__)

There is a decent amount of assembly language in the boot code of Linux to get the hardware into the proper state to execute an operating system and in the low-level functions required for things like port I/O and interrupt handling.

That's all in arch/, isn't it? Everything in kernel/ is architecture independant.

Also, I think you could have left it at

you cannot write an operating system like Linux

because I don't think I could write an operating system like Linux ever. In any language. I wouldn't want to, anyway; even Linus Torvalds has admitted that Linux is bloated. If I were to attempt to write a kernel at any point in my life, it wouldn't attempt to be nearly as big, and it would probably never go graphical. I'd probably try to make it like a cross between Linux, Minix and FreeBSD, so it would be a hybrid kernel or microkernel.