Legacy C Vs. C/C++ - What are the differences?

[Saman]

Saman wrote:No Nandika. That will never happen. C++ is the oldest common programming language and still it is the mostly used and most popular language in the world.

If you take Operating Systems, almost all are developed using C++ including Windows 7, Ubuntu, Android, iOS, etc...
If you take firmware development, other than assembly, C++ is the mostly used programming language.
If you take compilers of other languages such as Java are written using C++.

So in simple terms, almost all are running on low level layers written using C++.

If there is no C++, that's the end of software world. That's guaranteed

we use C++ for application programming , and C for operating system programming.

but that doesn't mean we can't write OSes in C++ or C#.net or something else.
could you please correct that "C++" to "C" ?

Sandun, this is a good question so I thought to reply in public

This is a common misconception. When we refer C++, we refer the extended C language we used today. Not the coding style. C++ programs can be written in OOP style or sequential style. When we write OSs, it is true that most of the parts are written in sequential style but compiled using the same C++ compiler. there is nothing called C compiler today. Based on the extension (C or CPP), the same compiler distinguishes between them (such as special requirements for CPP such as large stack and heap for dynamic allocation).

If you want to see it, try cout in .C and printf on CPP and compile with your compiler. Both works without any hassle.

So in professional programming world, when we refer C we refer the legacy language we used decades ago with IDEs such as Turbo C. Not the sequential coding style we use today and compiled with the same latest compiler.

I think you now understand why I used C++.

Regarding OS writing with C. This is not correct. We made few tiny dedicated OSs for few ARM based embedded platforms and what we had used is C++ (OOP style) with C++ compiler that turn the code directly to target machine code. At the end of the day, you load machine code to the boot-strap and it has no understanding on whether it is written in C++ or any other high level language. Fundamentally, Kernel or nucleus of the OS is in the lower level and run in machine code. Whatever run on top of it can be anything else whether it is compiled or interpreted. So again it is a misunderstanding.

So in simple terms, C++ is referred to the C language extension we use today and C is referred to the legacy language that we no longer use. C style coding (sequential programming) or C++ style (OOP) programming is a choice made by the programmer.

[SemiconductorCat]

Saman wrote:No Nandika. That will never happen. C++ is the oldest common programming language and still it is the mostly used and most popular language in the world.

If you take Operating Systems, almost all are developed using C++ including Windows 7, Ubuntu, Android, iOS, etc...
If you take firmware development, other than assembly, C++ is the mostly used programming language.
If you take compilers of other languages such as Java are written using C++.

So in simple terms, almost all are running on low level layers written using C++.

If there is no C++, that's the end of software world. That's guaranteed

we use C++ for application programming , and C for operating system programming.

but that doesn't mean we can't write OSes in C++ or C#.net or something else.
could you please correct that "C++" to "C" ?

Sandun, this is a good question so I thought to reply in public

This is a common misconception. When we refer C++, we refer the extended C language we used today. Not the coding style. C++ programs can be written in OOP style or sequential style. When we write OSs, it is true that most of the parts are written in sequential style but compiled using the same C++ compiler. there is nothing called C compiler today. Based on the extension (C or CPP), the same compiler distinguishes between them (such as special requirements for CPP such as large stack and heap for dynamic allocation).

If you want to see it, try cout in .C and printf on CPP and compile with your compiler. Both works without any hassle.

So in professional programming world, when we refer C we refer the legacy language we used decades ago with IDEs such as Turbo C. Not the sequential coding style we use today and compiled with the same latest compiler.

I think you now understand why I used C++.

Regarding OS writing with C. This is not correct. We made few tiny dedicated OSs for few ARM based embedded platforms and what we had used is C++ (OOP style) with C++ compiler that turn the code directly to target machine code. At the end of the day, you load machine code to the boot-strap and it has no understanding on whether it is written in C++ or any other high level language. Fundamentally, Kernel or nucleus of the OS is in the lower level and run in machine code. Whatever run on top of it can be anything else whether it is compiled or interpreted. So again it is a misunderstanding.

So in simple terms, C++ is referred to the C language extension we use today and C is referred to the legacy language that we no longer use. C style coding (sequential programming) or C++ style (OOP) programming is a choice made by the programmer.

I'm sorry ,but I have to tell this, Lots of misinformation is going in here.
I'm precisely confident what I'm speaking here because I have read the source of the CC (C) font end and g++ (C++) font
end and they are completely isolated and different. For a example C does not support type-checking.so C font end is
completely different from C++ font end.You need to go through it's codebase and see the changes, at least generate
the dependency graph over source files and see yourself. Anyway this link explains the same thing:
http://en.wikibooks.org/wiki/GNU_C_Comp ... chitecture

C is not C++ , neither their font ends are overlapping. It's normal that C or C++ or Java or whatever is using the
same backend. But it's safe to assume that C is not C++. but you could mix C with C++.



And finally you couldn't write this code in "C".

Code: Select all

#include <iostream.h>
int main()
{
    cout << "Will This Work On C\n";
    return 0;
}

Will say he was unable to find the iostream.h , and same thing is true for iostream too.
in my computer C++ include files are located in here: C:\MinGW64\lib\gcc\x86_64-w64-mingw32\4.6.1\include\c++
they are inside a special folder called "C++",they are available for the C++ front end.


and old C healder files won't match with the C++ header files either. But files like stdio.h , where specially designed to
use both C and C++ are working in both. If you dig stdio.h file , you could see that preprocessor is doing the magic
using #ifdef __cplusplus and #endif thing.

and there is no operator overloading in C, so how could someone call '<<' operator in C?
but there is a way.This is how , you need to do this magic too then.

Code: Select all

#ifndef CALLING_C_PLUS

#ifdef __cplusplus
extern "C"{
#endif

void print_from_c_plus(char *);

#ifdef __cplusplus
} // extern "C"
#endif 
#endif CALLING_C_PLUS

calling_c_plus_function.h

Code: Select all

#include <iostream>
#include "calling_c_plus_function.h"

void print_from_c_plus(char * print)
{
    std::cout<<print<<std::endl;
}

calling_c_plus_function.cpp

Code: Select all

#include "calling_c_plus_function.h"

void main()
{
 
    print_from_c_plus("this will be printed from C++ ");
    return 0;
}

main.c

To compile follow the bellow instructions

Code: Select all

$ gcc -c main.c
$g++ -c calling_c_plus_function.c
$g++ -o main  main.o calling_c_plus_function.o

so likewise you could do it. But you have to patch your header file with extern "C".

and please Neo , could you please put these two comments in a separate thread? This is going to be confused now.
I don't think original title of this thread is the difference between C and C++.

--thanks in advance--

[Saman]

I'm precisely confident what I'm speaking here because I have read the source of the CC (C) font end

I think you are talking about front-end on gcc, right? not 'font end', I never heard of such thing.

I'm not interested to go in to much details on gcc C compiler as it is not the only C compiler in the world. I only use it to compile my apps in Linux, nothing more than that. Besides gcc is a compiler collection that provides few compilers bundled together. So within the bundle, it has named the structure as Front, Middle and Back that I have no interest to learn since its kind of an internal naming for them. But I would have gone in to lexical analyser stage on the C compiler to check whether how it distinguish between C and CPP syntax.

However you misunderstood again. I didn't explain anything technical. I just mentioned the common grounds in the programming world. We refer C to legacy C and C++ to what we use now (We usually use C/C++ to denote that). You got it? Nothing in to coding style, C style or CPP style. You were explaining the coding styles.

Most popular C++ compilers support both C-style and CPP-Style source codes. Though we name it as say Visual C++, it doesn't mean it can't do C-style compilation. It just do both but the name is still C++. This is why I always refer C++ for anything written in C now. If someone is asking a beginner to learn C (C-style coding), I guess is non other than a fool.

Okay...no point in going in to that much details. I would rather prefer to study the theoretical compilers than studying a single compiler which had been complicated by its programmers over the years to work as a bundle.

Regarding what you said about compilers...

we use C++ for application programming , and C for operating system programming.

Have a look at this Microsoft employee's answer. I think that will remove your confusion.
http://social.microsoft.com/Forums/is/w ... 8e6b3da9f1

Most lower bits are written in assembly, the bit on top of it must be raw C (compiled using the C++ compiler anyway ) and the code on top of it can be anything like C++, C#, etc...

[SemiconductorCat]

for your convenience you could find the tiny C compiler book source in the book in
zip format here too.
http://www.cs.sjsu.edu/~louden/cmptext/loucomp.zip


Neo: could you please create a new thread called "different front End of C and C++" and put this
post and above four posts into it ? Sounds like I have to personally init() neo on this!

[Saman]

You now going in a different direction. You are talking about C/C++ compiling process. Let's get back to the original argument.

Sandun: we use C++ for application programming , and C for operating system programming.

Microsoft guy says they use C++ as well for OS programming (Not only C).

Do you see your misunderstanding here? It doesn't matter what language you write in OS programming. What matters is the compiler transfer it to a directly executable machine code rather than to a virtual machine. That's all.

[SemiconductorCat]

sorry for my interest, when somebody iniated to talk about GCC internals I can't stop myself,because
this is where I have special interest(compiler theory).You may read the last post too, it's still on the
previous thread I think.

yes microsoft is using C++ for OS imlplementation.

These are the difficulties when we jump into C++.
* we need to explicitly turn of some level of optimization or we will need some cryptic syntaxes.
[ex #pragma packed(4) ]
* Linkage will go too complicated due to the name mangeling, because C++ supports namespaces and
overloading.
* RTTI and virtual tables , exceptions should be turned off manually, this will requires you to read your
compiler documentation start to end without any excuse.
* eventhrough you paid the cost you won't be able to use standard C++ lib , libstdc++ string functions.
you'll think , [what kind of a idiot is me ?]
* Debgging will be a nightmare with your cryptic symbols.
* Some cryptic symbol decorations won't supported by some executable and libraries. So you will be come up
with the difficulty to writing interfaces to them. For a example,classes inside windows dll files need a complex
dirty code rambo jumbo.
you many read this and understand how it would be difficult to deal with cryptic code mangling when
we using other C++ compilers but same interface. Then interfaces to interface you would be required a new
header files and libraries.

Because of this reason , microsoft implemented a OLE, COM, COM+ like technologies. They have implemented a
dll format called .ocx to support and standardize it among various compilers.
http://en.wikipedia.org/wiki/Object_Lin ... _Embedding
this kind of thing is typically breaking down whole standard interfaces isn't it? My idea is yes.However
I'm not a software architect.Not even close.

So do we need that complexity by adding more tools? Instead we use tools to cut off the complexity.
that's why C++ is still not a wide choice for Operating system programming. However MS Windows is
written with using C++ too.

If you could manage the difficulties and manage with the cryptic name decoration then using C++ for
OS development is oky.

[Saman]

As your PM meant to me as you are trying to learn something, now I feel like you are trying to teach me Anyway, if there is something interesting I would do that as technology pleasure exceeds all pleasures for an enthusiast.

However what you are now saying is different from the previous path. You now explains the complexity of C++ and the reasons it could be unsuitable to use for OS programming. Your understanding is wrong.

C++ codes can be compiled either to a target machine or to a virtual machine. This is totally depend on the compiler you use. When we do OS programming, we compile the C++ code to target micro (I told this before). We don't compile to a virtual machine which runs on top of certain layers such as MSVCRT or HAL. So don't expect MS to use VC++ to compile their Kernel. On top of Kernel, it is possible host anything.

Have a look at this C/C++ compiler for ARM. This is a direct compiler which transfers C++ code to ARM machine code.

However I agree C-style coding is normally used for low level programming. We don't use OOP (Classes, Inheritance, Polymorphism) and other high level abstractions that are available in C++-style coding (CPP). However it doesn't mean that we can't compile them to a target machine.

[SemiconductorCat]

As your PM meant to me as you are trying to learn something, now I feel like you are trying to teach me Anyway, if there is something interesting I would do that as technology pleasure exceeds all pleasures for an enthusiast.

I bet I could ever be a good teacher. believe me I have hard time explaining very simple things. Seriously lacks
technical communication skills.I seriously need to ramp up my communication skills. However I'm so glad to hear
from you that you have learn something from me. Me too learnt many things from you.



In the previous post I have explained that C does never uses the C++ compiler in modern compiler implementations.,
I come up with the gcc codebase and shows you redudant lex and parsers exists independently for C++ and C.
For the programmers still believe it, I suggest them to take a look at the source code.[this is the advantage of
opensource, I bet most of believers of that misconception is from MS world or using closed source compilers].



Your ARM compiler said that it implements the EABI specification.
And this is the docs for that specification, nothing is hidden and everything are open.
http://infocenter.arm.com/help/index.js ... index.html
(links may get broken when time elapse ).

So it supports all the C++ object oriented features and also exceptions. And any compiler which supports
that specification can be used to program that processor. or do cross compiling and interchange code and
binaries between compilers and toolchains. (since every one are agreed on one standard).
So you could freely use all the features in C++ there.

I don't know correctly ,But I bet both MSCVC++ and gcc also have ports for that ABI.
so you could use these compilers too with right configuration.

However what you are now saying is different from the previous path. You now explains the complexity of C++ and the reasons it could be unsuitable to use for OS programming. Your understanding is wrong.

But this is not the same case when writing a general purpose operating system. You can't publish a
ABI document and told everyone to strict to it's rules , and 3rd party compilers will never or hardly
agree you. They will ask who are you? Your just a operating system writer not a Microprocessor
company right! Who are you to tell me like that ?

and on the other hand , a general purpose OS is not a closed one like your ARM one. It need to
support to drivers, executable, plugins, extensions, tasks , services and many more windows that
connect outside interfaces into the system. Suppose company ABC wrote a operating system ,
then they need to publish their SDK to the 3rd party developers. Suppose there are n number of
compiler writers and m number of programmers who are willing to implement 3rd party apps,
extensions and other binaries. Then there is a m*n dependencies. It's not simple like you can
publish a ABI and order m*n people to strict to it. It will never happen.So the only choice is
keep it less stricter and respect m*n developers and keep the things simple. The downside is
you need to give up C++ language extensions.

So I still believe in red quoted fact. I don't like this to be a debt, I hate school of taught.
But keep this discussion fact wise will leads both of us to learn something from each other
as the same time,to somebody who will dig this thread in future.



You have choosen ARM , it's a nice processor by the way. Have fun of it.