C vs C++ - your opinion.

Hi all,
What do you think, what language is best used to create low-level programs (for example: drivers, kernel to new operation system, etc)?

Yes, C++ it is Object Oriented Language - it facilitates the work of the programmer. But let's not look at the development of custom software products (for example: browsers, editors, calculators, accounting software etc.).

If C++ is so good, why the FreeBSD base written in C?
1. For that would not overwrite the operating system, developers continue to use C.
2. С for such problems is better than C++.
3. Or, and - your opinion!


Thanks. :stud
 
Historically Dennis Ritchie's C programming language was created to aid in portability. They where sick of reimplementing various languages and systems in different assembly on different hardware.

C was derived from a stillborn language called B which was influenced by Martin Richards' BCPL which Thompson implemented while he and Ritchie where working on Multics.

Interesting fact is the system was initially called UNICS. When the system was able to compile itself with C is when they Kernighan suggested a new name be given and it was called UNIX.
 
Google for Linus Torvalds opinion of C++ if you haven't read it already. He knows more about kernel development than I do and he says C++ resembles a bull's bowel movement. They tried using C++ in Linux kernel but caused them nothing but grief.

Over the years, I've debated the same issue myself but never had a chance to play with C++ enough to get into it until last winter. All the while I kept thinking to myself I can do the same thing in C so why do I need C++. To tell the truth, it almost won me over because I was playing with something where "everything was an object" and it might have gone well until I ran into some interfaces where "everything was a PITA" and C++ was part of that.

So now, when someone wants me to do something in C++, I say, "Give me a struct and a function and let's call that C++".
 
The long and short of it is that C was developed to program an operating system. C++ was developed to facilitate GUI applications and the GUI itself to make things easier on the programmer. When it comes to kernel code, you don't want easy, you want exactness and correctness. Adding the additional overhead of C++ classes, inheritance, and polymorphism just adds to the complexity and slows things down.

As to my opinion, I never really needed to code something in C++. But then again, I generally write things that play with the kernel and multithreaded server applications, where C++ is generally considered a no-no.
 
Maelstorm said:
C++ was developed to facilitate GUI applications and the GUI itself to make things easier on the programmer.
That's the first time I've ever heard that. I believe Stroustrop created it for programming large systems using objects.
 
Microsoft's MFC classes are probably the reason for this misconception. They were very likely your first encounter with C++ if you started to hack together a windows program with a GUI first time.
 
Thank you UNIXgod! But I know the history. ;)
I know history of the development of BSD, C language, etc.
But if you were created a new operating system, you would have chosen the C language (or C ++)?

drhowarddrfine and Maelstorm I also agree with your opinions.

UNIXgod said:

Wah, good article. Good to know the personal opinion of the expert in this field. Thanks for the link.


Thank you all!
 
kpa said:
Microsoft's MFC classes are probably the reason for this misconception. They were very likely your first encounter with C++ if you started to hack together a windows program with a GUI first time.

I very rarely use Microsoft Visual Studio. When I used Windows I used the products of Borland (VCL).

Last year (and my choice for life), I use FreeBSD and C language (not C++). I really like the C language: accuracy, I control everything, I can write on it whatever you like (in theory - I'm still not a guru ;) ).

But I hear a lot of criticism that C++ is better C - so I'm trying to understand, am I right? ... My choice (for the low-level programming) - C programming language.

C++ in the furnace! (***This is a joke, if I need to re-write accounting software for Windows (using GUI) - I write in C++. But thank God, I no longer use Windows).

And I'm wondering your opinion!
 
While C may have restrict pointers, I think C++'s templates takes the win in C vs C++.

If you want both generalization and optimization, you can't expect void pointers and function pointers to help the compiler optimize your code. A widely cited example is C qsort() versus std::sort(). The latter is always faster because the compiler knows more about the types it's working with. For example, the qsort() compare function pointer now becomes a single instruction rather than an indirect function call.

Templates are the best thing about C++ and there is absolutely nothing in C that compares.

The next biggest advantage of C++ over C is STL. You get
  • Standard data structures
  • Standard algorithms (especially powerful in C++11)
And these are all type-aware! There are no void pointers for storing arbitrary data or finicky macros for efficient data structure manipulation. And as mentioned above, the compiler can make more informed optimizations since type information is known at compile time.

Less used, but templates can even be used to work the compiler (e.g. do complicated calculations at compile-time ... like generalized loop unrolling or computation of constants).

While there are many examples of C++ abused, judicious use of its features can help with code maintainability, convenience, and optimization. Take for example function pointers with void arguments used for callbacks. It would look something like:
Code:
void do_something(void (*callback)(void *), void *arg);

The the void *arg is synonymous to an instance of an object in C++. In fact, it's entirely the same as
Code:
struct Callback {

  void operator()() {
     // 'this' pointer [b]is[/b] 'arg' above
     // Oh yeah, and no casting void pointers ... the type is always known

     DoSomething(someData);
  }
  // Argument information is member data
  SomeDataType someData;
};

How about initialization and cleanup? In C, you'd do something like:
Code:
void do_something() {
  struct my_thing *thing;
  thing = my_thing_alloc();

  if (!my_thing_do_something(thing)) {
     /* Oops, forgot my_thing_free(thing)! */
     return;
  }

  /* ... */

  my_thing_free(thing);
}

In C++, at no extra cost and less code you get automatic initialization and cleanup
Code:
class MyThing {
  MyThing() {
    // Initialize data
  }
  ~MyThing() {
    // Cleanup data
  }

   bool DoSomething();
};

void do_something() {
  MyThing thing;

  if (!thing.DoSomething()) {
    // Destructor called here automatically
    return;
  }

  // Destructor called here automatically
}

It's especially useful with resources like files or memory. There's just less chance of programmer error. For example:
Code:
void do_something() {
  FILE *file = fopen("thing.txt","r");
  /* ... */

  if (something_failed) {
   /* forgot fclose(file) */
   return;
  }

  fclose(file);
}

In C++
Code:
void do_something() {
  std::ifstream fileStream("thing.txt");
  // ...
  if (something_failed)
    return; // Destructor closes file here

  // Destructor closes file here
}

Upshot:
C++ gives you more control over C (templates) and offers an impressive arsenal of standard data structures and algorithms.

Miscellaneous:
Take a look at the CUDA thrust examples. In C, this kind of GPGPU programming would be substantially more complicated! The thrust interface behaves just like the generalized STL interface (and at no real extra cost!).
 
UNIXgod said:

I have only one thing to say about this: Laugh-Out-Loud That was freaking hilarious.

http://article.gmane.org/gmane.comp.version-control.git/57918 said:
And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any idiotic "object model" crap.

I fully agree with that sentiment, and the entire post as well. Yep UNIXgod, that is a classic.
 
drhowarddrfine said:
That's the first time I've ever heard that. I believe Stroustrop created it for programming large systems using objects.

Bjarne Stroustrup's C++ is based on the earliest language which was object oriented (Simula).

Alan Kay who defined Object Oriented Programming Systems as a conceptual method created SmallTalk which would be the canonical OOPS language. The Ruby Programming language is sort of a smalltalk and perl language and both are considered complete as everything is an object vs C++ where objects can be created via wrappers around procedural code.

SmallTalk was created at XEROX to be used for GUI and graphical application development. Alan Kay's concepts in message passing would eventually identify the architectural pattern Model-View-Controller (MVC).

The cool thing about Kay is he is a teacher. He considered a paradigm which would act like biological elements (template instantiation i.e. classes). Subsequently it works well when controlling memory in a graphical environment.

C++ is faster than these interpreted languages since it's still essentially "c with classes". For building game engines and graphical frameworks C++ is probably the right tool. The previous mentioned scripting languages sit nicely for shell scripting automation and the current generation of full stack web frameworks.

Here is a classic video of Kay explaining how user interface design could be a useful tool for the human learning experience. What he did with smalltalk and definition of object oriented programming concepts is much in the same as what Doug McIlroy pulled off with the UNIX pipeline paradigm. Both of the computer scientist are among the greatest thinkers of our time.

https://www.youtube.com/watch?v=50L44hEtVos

^^ mind you this video is before we had any home gui or windowed interface in our homes. It's also a killer concept of critical pedagogy.
 
Here's another reason why I tend to avoid C++:

Code:
std::vector<boost::shared_ptr<std::map<std::wstring, std::vector<int> > > > blamoList;

Do YOU understand that?
Do YOU follow what's going on there?

Not me. I have to think about it a lot.
 
It's an std::vector of boost::shared_ptrs. The boost::shared_ptr objects in the vector point to objects of type std::map (an associative data type) that have std::wstring keys and std::vector<int> type objects as values.

Not too hard to understand ;) Some typedefs would make that whole lot easier to read because then you're not distracted by the <<<<>>>>.

Code:
typedef std::map<std::wstring, std::vector<int> > my_map;

typedef boost::shared_ptr<my_map> my_shared_map_pointer;

std::vector<my_shared_map_pointer> blamoList;
 
I do prefer C/Assembly in the Embedded system's fields because of the "availability" (maybe not the case nowadays). In the other hand there's some concerns about executable size, Here is an old rough comparison:
Executable sizes comparing C and C++, iostream, stdio, and unistd

Concerning the Self-hosting and Compiler Bootstrapping hypothesis, lead us to this fact that: the process of Analysis of algorithms and using the Computational complexity theory results are more important than the compiler itself.
 
Maelstorm said:
Here's another reason why I tend to avoid C++:

Code:
std::vector<boost::shared_ptr<std::map<std::wstring, std::vector<int> > > > blamoList;

Do YOU understand that?
Do YOU follow what's going on there?

Not me. I have to think about it a lot.

Well, I think it is more the fact that this functionality would take a lot more effort than simply understanding it to recreate in C.

kpa's suggestion was a nice solution, but I tend to not typedef stuff, I just grit my teeth and bare it ;)

I love both C and C++.
 
I'm curious since the conversation has gone in this direction. In any language where the programmer is not being clever for the fun of it; where clear and concise code can't be used for one reason or another isn't it universally known to write a comment and document what the code does.

Especially in a area where there will be multiple authors or for reexamination of your own code years after it was written.
 
kpedersen said:
Well, I think it is more the fact that this functionality would take a lot more effort than simply understanding it to recreate in C.

kpa's suggestion was a nice solution, but I tend to not typedef stuff, I just grit my teeth and bare it ;)

I love both C and C++.

typedefs are among the most useful feature in C++. If it weren't for typedefs, interesting features like type traits would never be possible. You should embed useful type information into classes with typedefs whenever it can help with generalized code.

For example, something like this is very common:
Code:
template<typename ContainerType>
void DoSomething(ContainerType &container) {
  typedef typename ContainerType::value_type value_type;

  // Now you know the type stored in container and can do something like:
  std::vector<value_type> tempVec;
}

EDIT: A type trait example

Code:
// Example: Use type traits to strip signedness

template<typename T>
struct GetUnsignedType {
  // Default behavior, forward type information
  typedef T UnsignedType;
};

// Template specialization
template<>
struct GetUnsignedType<short> {
  typedef unsigned short UnsignedType;
};

template<>
struct GetUnsignedType<int> {
  typedef unsigned int UnsignedType;
};

template<typename T>
void DoSomething(const T &something) {
  typedef typename GetUnsignedType<T>::UnsignedType UnsignedType;
  UnsignedType somethingUnsigned;

  // ...
}
 
typedef falls into the subject of abstract data types. Primitive data types are generally char, int and float. They represent actual memory (i.e. 64-bit has a larger int than 32-bit and so on).

C doesn't have classes but does have struct (i.e. structure). structs define primitives which can be used to represent a gestalt of memory. (i.e. if a struct has four ints a a new struct will be sizeof(int) * 4)

typedef in an unto itself allows further abstraction of memory in effort to create complex data types.

Curious though. This isn't the first time I've seen a conversation come up about using another language to create a kernel than c. I'm not a kernel hacker but would imagine that using a supersetted language like c++ to create a program (kernel) that sole purpose is to manage memory and thread execution of system resources would bring in unnecessary complexity and slower executions at the cost of "simplifying" the development process with more tools.

This is much the same as why an admin would use POSIX ash when bash/korn/z has more features which may act like a programming language vs pure pipeline for automata.

The right tool for the right job. C++ has it's uses for many types of programming in application development. C is and will always be tied to the OS and it's core.
 
One thing that I want to point out as well, since Zhoopin mentioned embedded systems. I have personally worked extensively in the microcontroller environment where memory is at a premium. Virtually all these devices use the Harvard architecture where the program store and ram are completely separate. I say virtually because every one that I have seen over the years uses Harvard, but there may be some DSP (Digital Signal Processor) hardware that might use the more traditional computer architecture. Ram isn't too big of an issue, because I can expand it with an external memory device if need be...but the program store is fixed on the device (There are some devices that don't have the internal program store so the program must be supplied via an external ROM chip.) and the size cannot be changed. The program store on these devices can range from at little as 512 Bytes to 1MB or more depending on the device. These devices also have a plethora of different peripherals on chip, much of which uses memory mapped I/O. These peripherals can be various types of timers/counter, serial ports, analog I/O (Generally DSPs), digital I/O, etc.... Atmel is somewhat unique in the fact that they also include a analog comparator on chip.

The tools used for microcontroller development are vendor supplied. However, the one that I have worked with the most, Atmel's AVR, their AVR Studio uses gcc as a compiler. They have a custom assembler for their chips as they are RISC based. I've written an RTOS (Real-Time Operating System) kernel using AVR assembler. The requirements are WAY different between a controller and a regular computer. So it all comes down to this: The right tool for the job/project at hand. You can use C for the high level stuff, and assembler for the low level if you need the speed or if there are sensitive timing issues (microcontrollers control hardware devices) to deal with. However, if you put out a piece of C++ code, most companies that I'm aware of will drag you out and shoot you, twice.
 
Ah, the AVR. Old love it and hate it.
The analog comparator does make it more fun to write a working battery management for mobile devices when charging NiMH batteries. I found it harder to explain what a delta-peak is to the PHBs than actually write the code. But enough strolling down memory lane.

As a lot of the contributors have written, you need the right tool for the right job, but also the right person to wield that tool. I have come across programmers who I would trust to use C++ in almost any way, but then there are also those I would lock in an ADA only project. That is the third dimension of this problem. Purpose, Language, Person.

You can use C++ to write a kernel, have a look at haiku for example. This is a nice thing when done right. But as Linus' also expressed so eloquently, there are too many persons using C++ which would be better served with some kind of BASIC. You can shoot yourself in the foot with almost any language, but with a badly designed C++ programm and enough abstraction using the pletonia of templates, tricky vectors and virtuality at all places you may aim for the mosquito at the wall and blow up the planet. In the hands of someone who writes such 'applications', C++ is not a tool but a risk. In the hand of an expert who really knows what it can do and when not to do it, it can be bliss.
 
Thank you guys.

I prefer to use C for the low-level programming too, I have already spoken about this. I'm glad that you expressed your opinion and I am glad that most of them agree with my opinion.

P.S. I'm not going to close this topic, maybe not still express their opinion!
 
I am not a really good programer, I've learned c++ and after c, But i really don't like c++, I prefered used objective-c but it is really tricky outside apple.
 
Back
Top