# C vs C++ - your opinion.



## valsorym (Aug 9, 2012)

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


----------



## UNIXgod (Aug 10, 2012)

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.


----------



## drhowarddrfine (Aug 10, 2012)

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++".


----------



## Maelstorm (Aug 10, 2012)

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.


----------



## UNIXgod (Aug 10, 2012)

drhowarddrfine said:
			
		

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



Here it is:

http://article.gmane.org/gmane.comp.version-control.git/57918

It is a classic.


----------



## drhowarddrfine (Aug 10, 2012)

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.


----------



## kpa (Aug 10, 2012)

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.


----------



## valsorym (Aug 11, 2012)

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:
			
		

> Here it is:
> 
> http://article.gmane.org/gmane.comp.version-control.git/57918
> 
> It is a classic.



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


Thank you all!


----------



## valsorym (Aug 11, 2012)

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!


----------



## nslay (Aug 11, 2012)

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:

```
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

```
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:

```
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

```
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:

```
void do_something() {
  FILE *file = fopen("thing.txt","r");
  /* ... */

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

  fclose(file);
}
```

In C++

```
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!).


----------



## Maelstorm (Aug 11, 2012)

UNIXgod said:
			
		

> Here it is:
> 
> http://article.gmane.org/gmane.comp.version-control.git/57918
> 
> It is a classic.



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.


----------



## UNIXgod (Aug 11, 2012)

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.


----------



## Maelstorm (Aug 12, 2012)

Here's another reason why I tend to avoid C++:


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


----------



## kpa (Aug 12, 2012)

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


```
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;
```


----------



## zhoopin (Aug 12, 2012)

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.


----------



## kpedersen (Aug 12, 2012)

Maelstorm said:
			
		

> Here's another reason why I tend to avoid C++:
> 
> 
> ```
> ...



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


----------



## UNIXgod (Aug 12, 2012)

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.


----------



## nslay (Aug 12, 2012)

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:

```
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


```
// 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;

  // ...
}
```


----------



## drhowarddrfine (Aug 12, 2012)

typedefs work in C, too.


----------



## nslay (Aug 12, 2012)

drhowarddrfine said:
			
		

> typedefs work in C, too.



Of course, but their common use in C amounts to renaming struct types. Typedefs are far more useful and powerful in C++.


----------



## UNIXgod (Aug 13, 2012)

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.


----------



## Maelstorm (Aug 13, 2012)

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.


----------



## Crivens (Aug 13, 2012)

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.


----------



## valsorym (Aug 13, 2012)

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!


----------



## yoxter (Aug 16, 2012)

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.


----------



## UNIXgod (Aug 16, 2012)

yoxter said:
			
		

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



What's the difference from c++ to objective . Is it just another superset of C or is there any specific feature or paradigm that differs from c++?


----------



## Crivens (Aug 16, 2012)

I can only suggest reading some of the free documentation about objective-c to get a grasp of what it does.

It is tricky to use it outside of the apple universe, but it may be worth a try. I had no chance to try it out for that reason, but I am not biased against it. There are other languages which I would refuse to the point of quitting, but that is rare.

Short example: objective-c does not have templates because it does not really need them. You may write a class which reacts on messages, but does not know anything about it. Therefore a sorter may operate on any structure to sort as long as the container provides switching of elements and elements provide comparisons. Linking of the methods (called messages) is done at run time. So the same binary code may be used to sort lists, arrays and even trees, but it is only present once in the system instead of expanded from templates again and again.

C++ will happily generate seperate instances for a template invocation with _int_, _long_, _long int_ and what not, even when they result in equal code. Removing that bloat is the job of the linker then.

An interesting language with high potential, certainly worth knowing about.


----------



## yoxter (Aug 16, 2012)

UNIXgod said:
			
		

> What's the difference from c++ to objective . Is it just another superset of C or is there any specific feature or paradigm that differs from c++?



The best feature (on my review) is the memory management.


----------



## SR_Ind (Aug 16, 2012)

Oranges vs apples.

FreeBSD (and the list goes) is written in C...because it inherits a C codebase. 

Linus Torvald's opinion...hmm. I think Linux kernel is not the only kernel in the world such that Linus's word becomes a gospel truth.

Why C++? It handles complex software architecture very well, if you are good to average with C++ features. As the size the application grows, C codebase becomes increasingly complex and difficult to maintain.

Talking of kernel (FreeBSD included) despite being monolithic, also relies on loadable modules and hence the code size of a single binary has an upper limit. 

Loadable modules cannot be written in C++ (due to C++'s name mangling), this of course applies to kernels as well as general software.

Misconception about GUI persists. GUI can be done in C. Ask any Win32 programmer.

My professional experience tells me C++ programmers are also equally well versed with C. The two are used with equal ease depending on the situation.

C++ being inefficient is a myth. You pay for what you ask for. Leave aside stuff like templates and polymorphism if you need compact and fast code. Feature by feature both compilers generate similar opcode.


----------



## NuLL3rr0r (Aug 17, 2012)

drhowarddrfine said:
			
		

> 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.
> and let's call that C++".



Torvalds has â€œC-hacker syndromeâ€.

@valsorym  
I'm a C++ programmer who never touched C. For me C is like a higher level assembly, I like the abstraction layer that C++ gave me over C. But based on what I know and what I heard for developing Kernel, Drivers, and all low level stuffs I believe C is the right choice. For everything else C++ rocks over C (Applications, Games, even Websites and WebApps).

There are so many reasons that I have to explain. I explained some of 'em in the comments here: I disagree with Linus Torvalds about C++

Right tool for the right job.


----------



## SR_Ind (Aug 17, 2012)

&quot said:
			
		

> Right tool for the right job.


This simple principle is seemingly difficult to grasp for by many.


----------



## SR_Ind (Aug 17, 2012)

I've noticed one interesting point made by people skeptical towards C++. Reference to the MFC library and how bad it is.

The reason this point is of interest to me is whether such people have really used MFC? If yes then when?

I don't recall anyone in my organization or peers outside writing software for Windows in MFC after 2002/2003 (give or take few years). The people that used to write low level stuff in Win32 continue to do so. 
MFC used to be used to be business apps, and the same has been sidelined in favour of C#.


----------



## zhoopin (Aug 17, 2012)

I'm very fond of C language, by reason of I know it very well, and have no such experience in other languages in depth.
However Linus Torvalds's manifest is a classical example of Fallacy.


----------



## UNIXgod (Aug 17, 2012)

yoxter said:
			
		

> The best feature (on my review) is the memory management.



Does it have built in garbage collection? Are malloc(3) and free(3) still available? I guess a better question would be does it allow you to drop down to real C like C++ does?



			
				zhoopin said:
			
		

> I'm very fond of C language, by reason of I know it very well, and have no such experience in other languages in depth.
> However Linus Torvalds's manifest is a classical example of Fallacy.



I think he wants git to be fast. He does have a very abrasive way of protecting his project. I imagine that guy gets alot of people bothering him to do things outside his perspective of how he wants it to be designed.


----------



## Crivens (Aug 17, 2012)

SR_Ind said:
			
		

> Loadable modules cannot be written in C++ (due to C++'s name mangling), this of course applies to kernels as well as general software.


I beg to differ. This has been done and continues to be done.
May I point you towards BeOS and the rewrite of it called Haiku? BeOS was famous for it's compact programms due to the fact that it heavily used inheritance.


			
				SR_Ind said:
			
		

> C++ being inefficient is a myth. You pay for what you ask for. Leave aside stuff like templates and polymorphism if you need compact and fast code. Feature by feature both compilers generate similar opcode.


To be efficient, meaning writing efficient code, means also that you really know what you are doing. Whan was the last time anyone here looked at the assembler code produced by the compiler to check if it comes close to that what you wanted? I do this from time to time to catch constructions which may look efficient in the source but force the compiler to generate code by the megabyte.


----------



## zhoopin (Aug 17, 2012)

UNIXgod said:
			
		

> Does it have built in garbage collection?


Since Version 2: Yes (Exception: iOS)



			
				UNIXgod said:
			
		

> Are malloc(3) and free(3) still available?


Yes, malloc and free reduce overhead of the runtime.



			
				UNIXgod said:
			
		

> Does it allow you to drop down to real C like C++ does?


Yes, Objective-C a proper superset of C.


----------



## Crivens (Aug 17, 2012)

Garbage collection is where I am not up on speed in objective-c. Is it using reference counts or some more elaborated ways?


----------



## zhoopin (Aug 17, 2012)

Crivens said:
			
		

> Is it using reference counts or some more elaborated ways?




Garbage collection Architecture

When a collection is initiated, the collector initializes the set with all known root objects.
The collector then recursively follows strong references from these objects to other objects, and adds these to the set.
All objects that are not reachable through a chain of strong references to objects in the root set are designated as â€œgarbageâ€.
Notes:
The collector does not scan all areas of memory.
The stack and global variables are always scanned.
The malloc zone is never scanned.
Warning: Garbage Collection is deprecated in OS X v10.8. Instead, You should use ARC: Transitioning to ARC Release Notes

Reference: How the Garbage Collector Works


----------



## SR_Ind (Aug 17, 2012)

Crivens said:
			
		

> I beg to differ. This has been done and continues to be done.
> May I point you towards BeOS and the rewrite of it called Haiku? BeOS was famous for it's compact programms due to the fact that it heavily used inheritance.


BeOS/Haiku is a good example. I knew it/they are written in C++, but I was under the impression they do drivers and runtime modules in C. Thanks for the info, its another plus for C++.



			
				Crivens said:
			
		

> To be efficient, meaning writing efficient code, means also that you really know what you are doing. Whan was the last time anyone here looked at the assembler code produced by the compiler to check if it comes close to that what you wanted? I do this from time to time to catch constructions which may look efficient in the source but force the compiler to generate code by the megabyte.


Well, not always. We do some driver development for networking OEMs, and there once in a while we double check the compiler output. In reality its not always fast AND compact. The two attributes are traded off against each other.


----------



## drhowarddrfine (Aug 17, 2012)

The only thing I have to add to this is that every piece of code we compiled in the past was far larger in C++ than in C and took us far longer to put together. I'm sure it took longer because we weren't used to it but, all along, we kept thinking to ourselves, "Why am I doing this in C++? I can do this in C."

That's really not a knock against C++. If I started with C++ I probably wouldn't see the need to use plain C. 

Not everything is an object, especially in kernel development, and that may be the issue here.


----------



## SR_Ind (Aug 17, 2012)

In fact the concept of object is most suited to kernel development. Device drivers for instance. File is an abstraction of disparate physical and logicals devices. 

Various files handles are nothing but instances of the that abstraction and each one supplies same set of primitives (I can immediately think of virtual functions...as someone pointed out above; in BeOS/Haiku) which very transparently handles devices specific operations.

Object orientated development is an architectural principle (I'd say it is a state of mind, you get it or you don't), and some languages like C++ simply provide various constructs for that style of programming.


----------



## Crivens (Aug 17, 2012)

SR_Ind said:
			
		

> In fact the concept of object is most suited to kernel development. Device drivers for instance.
> 
> Object orientated development is an architectural principle (I'd say it is a state of mind, you get it or you don't), and some languages like C++ simply provide various constructs for that style of programming.



OS-X also uses a subset of C++ in device driver programming, greatly reducing the size and LOCs of the drivers, along with the number of bugs I think.

Calling object orientation as a state of mind is a good analogy.


----------



## drhowarddrfine (Aug 17, 2012)

See, those points are the exact opposite of what I've ever heard. Torvalds specifically talks about that in his piece.


----------



## nslay (Aug 18, 2012)

drhowarddrfine said:
			
		

> The only thing I have to add to this is that every piece of code we compiled in the past was far larger in C++ than in C and took us far longer to put together. I'm sure it took longer because we weren't used to it but, all along, we kept thinking to ourselves, "Why am I doing this in C++? I can do this in C."
> 
> That's really not a knock against C++. If I started with C++ I probably wouldn't see the need to use plain C.
> 
> Not everything is an object, especially in kernel development, and that may be the issue here.


RTTI and exceptions probably don't help with executable size. Clang's documentation actually knocks RTTI quite a lot and claims that it makes executables much larger.

Hands down, templates give C++ a distinct advantage over C and *at no cost to run time performance*. Templates look hideous but they are entirely compile-time constructs. They are general and provide type information (and numeric and boolean information too). In C, you generalize code with void pointers and function pointers ... there's just no comparison. Used correctly C++ will be more general and at least as fast as C. When you start using void pointers and function pointers, C++ already wins out. It's not a deficiency in C, just that C++ can provide the compiler more information.

Templates can make your executable bigger though ... especially if you instantiate a function/class for a ton of different types. But that's what you get when you avoid void pointers.

However, C does have restrict pointers ... that's pretty awesome.


----------



## falkman (Aug 18, 2012)

I'm not a very big fan of C++. I'm very little a fan of object oriented programming. I'll give a quick example.

Generally objects refer to each other with pointers (sometimes they're statically compiled, I know). Lots of classes are just massive collections of pointers. Now when you're calling 80% of all your functions via a class, you're doing multiple unnecessary dereferences. You most likely have a dereference for your class, then another for the function you're calling.

Don't get me wrong, the performance overhead of this is negligible, but object-oriented programming puts people in a little different mindset than what I think developers should be in while programming. Everyone seems so comfortable using massive classes, allocating new memory, etc. When you have to manually allocate memory in C and such, you understand exactly what the system is about to do and if you're like me, look around for better ways to save memory. When I find myself reverse engineering C++ binaries, I see some massive stack allocations because people forget that the class they create in every function takes up thousands of bytes of space on the stack. Then this has to be initialized, etc. I often see hundreds of lines of assembly at the start of _each function_ (shivers) just to initialize a massive class of which a couple simple functions are used.

As a reverse engineer, I spend a lot of my time looking at other people's binaries, and that's what really starts to make me like C a lot more than C++. C++ just feels so dirty and impure. If people use C++ because you can develop faster than C, then why not just use Java or .NET?

I like to think of C as a way of making the lowest level code possible, but still maintaining the ability for it to be cross-architecture.

I still like C++, in the matter that I'm okay using someone's C++ program, however I'd never write it myself unless it was mandatory (for work or the like).

Now take what I say with a grain of salt, as I'm very radical in terms of performance and memory usage. The issue I have is that even a good developer would have difficulties writing a full-featured C++ program (taking advantage of C++ features, not just C with a .cpp extension) that maintains small stack usage, and minimal unnecessary dereferences. C++ puts in these dereferences in by itself and it is supposed to, it's the best way to do what it's designed to do. If you try to program in such a way that C++ performs at similar rates as C, you're most likely writing in an abnormal way that you've defeated the purpose of using C++ in the first place.

However, I see plenty of C programmers that do some nasty no-nos. Like those guys who link to the entire Qt because they like using the character set converter in it.

Something that cannot be countered, as it is simple fact: C++ takes a lot longer to compile than C. If you're like me and compile everything from scratch, you'll start to get annoyed every time you see $(CXX) as you know it's going to take longer. This isn't C++'s fault by any means, it just has a more complex and featured syntax that takes more effort to parse and construct.

TL;DR:

C is cross-platform rapid-dev assembly (rapid-dev compared to assembly)
C++ has unnecessary performance overheads and distorts programmers' mindsets from the "Do one thing and do it well" concept

Sidenote: Hi, nslay!

-Brandon


----------



## SR_Ind (Aug 18, 2012)

falkman said:
			
		

> *If people use C++ because you can develop faster than C++*, then why not just use Java or .NET?



What does your sentence mean ? Anyway, the effectiveness and purpose of your entire post is lost the moment you dragged in Java and .NET along with C (which you typoed as C++) and C++. I've never heard of any language called .NET.

Are you aware that (I've said it before and I'll say it again) majority (if not all) C++ programmers are also skilled C programmers?

It is a deliberate mischief by a set of people, that never got up to C++ skill levels, to talk about C and C++ as two vastly different languages. A small set of C features that never overlapped with C++ has since been obsoleted. 

If I design my classes and yet call into C standard library inside my functions, am I a C++ programmer or a C programmer? Or if I call inline assembly inside my functions do I become a assembly programmer? 

Your conclusion about stack allocation is completely wrong. Two ways. 
One, it is not necessary, because you can allocate every damn object on heap as your program progresses. 

Second, yes C++ allows such stack allocation within well encapsulated code blocks, because this very feature eases memory management (meaning no manual allocation/deallocation ) as the program grows in scope and complexity. 



			
				falkman said:
			
		

> However, I see plenty of C programmers that do some nasty no-nos. Like those guys who link to the entire Qt because they like using the character set converter in it.


Entire Qt for a few character set conversion?


Now don't get me wrong, no offence meant here but:

1. Deliberating C, C++, Java and .NET (BTW there no such language) in single sentence and advising C++ program to use Java or .NET (whatever that is) shows you are proficient with none of the 4.

2. Restricting ourselves to C/C++. Your Qt comment is interesting. Its been 7 or 8 years since the current format of Qt came out and it does not require one to link to entire library for few functions. For what you described QtCore is enough. I've two conclusions either you are into the profession very recently (or maybe still in college) or your professional peer group is very inexperienced. 

Once you get some opportunity to work in more than a few languages, please revisit your assessment.


----------



## falkman (Aug 18, 2012)

Not sure why you directly attacked me as a person on this one. I said that I like C and C++ and that I prefer C, but for some reason that was too radical?



> Java and .NET along with C (which you typoed as C++) and C++. I've never heard of any language called .NET.



I know that .NET isn't a language, however it refers to a set of languages and most people are comfortable with just saying .NET to refer to them as a group.



> Are you aware that (I've said it before and I'll say it again) majority (if not all) C++ programmers are also skilled C programmers.



How is that related? In no way did I say C++ developers are less skilled than C programmers, nor did I say C++ programmers cannot be C programmers.



> Your conclusion about stack allocation is completely wrong. Two ways.
> One, it is not necessary, because you can allocate every damn object on heap as your program progresses.



Obviously you don't have to put things on the stack. I'm talking about in general. Sure, you could probably take 10,000 compiler flags and a very unique coding style, and do anything you could possibly want for c++ binary output, but I don't see how that invalidates my point.



> Second, yes C++ allows such stack allocation within well encapsulated code blocks, because this very feature eases memory management (meaning no manual allocation/deallocation ) as the program grows in scope and complexity.



I never said that the C++ implementation was bad, in fact I said it was the best implementation for what it was trying to achieve.

As for the Qt thing, that was a hypothetical exaggeration of a situation where someone might include much larger dependencies than what they need in C. It had no basis in fact. It was simply meant to get a chuckle out of people.


Please, discuss the topic, don't sit and call me a bad programmer because you simply disagree with what I've said.

It's pretty obvious that you only want to get into an argument when you imply that I thought .NET was a language over and over again as if it is to prove my stupidity. Come on, lighten up.

-Brandon


----------



## zhoopin (Aug 18, 2012)

There is an article about: C++ for Kernel Mode Drivers: Pros and Cons in Windows systems.
I know it has nothing to do with FreeBSD, but for those whom have time to spare (obviously in a positive light), it could spark some ideas into someone's head to do a comparative research between similar aspects of them (FreeBSD's C++ vs Windows one). Maybe it come to a FreeBSD-oriented conclusion.:stud


----------



## SR_Ind (Aug 19, 2012)

falkman said:
			
		

> Not sure why you directly attacked me as a person on this one.
> 
> Please, discuss the topic, don't sit and call me a bad programmer because you simply disagree with what I've said.
> 
> It's pretty obvious that you only want to get into an argument when you imply that I thought .NET was a language over and over again as if it is to prove my stupidity. Come on, lighten up.


I don't think I said you are bad programmer and I don't think it might be the case either. What I alluded is that you might not have experience with other languages. 

I (for that matter anybody else) don't disagree with your choice. What I'm not impressed with is opinions that are formed on basis of questionable anecdotes and hearsay.



			
				falkman said:
			
		

> How is that related? In no way did I say C++ developers are less skilled than C programmers, nor did I say C++ programmers cannot be C programmers.


They are related. Since most C++ programmers are also skilled C programmers and use both equally well, they would not find grounds to find faults with either. They'd know when to use which. People of my age group started with assembly and C, before picking up C++. So, that's the link. 

There are programmers with exclusive grounding in either C and C++. The former are the ones that never picked up C++, and the later are ones that had benefit of being taught C++ right there in their curriculum (I hadn't that luxury). So neither of these two categories should comment on one another.



			
				falkman said:
			
		

> I said that I like C and C++ and that I prefer C, but for some reason that was too radical?
> 
> I know that .NET isn't a language, however it refers to a set of languages and most people are comfortable with just saying .NET to refer to them as a group.
> 
> As for the Qt thing, that was a hypothetical exaggeration of a situation where someone might include much larger dependencies than what they need in C. It had no basis in fact. It was simply meant to get a chuckle out of people.


Nothing radical about loving C. 

People love C and that's that. I think every programmer worth his/her salt should master C whether they use it or not. After that they might settle down upon a language for long term mastery. That's what I do, if need a small utility I do it in C. I might throw away that program later on. However, what's interesting is that many such utilities or tools later expand and are refactored into classes and used within larger C++ programs. I don't see the difference here as people shout about, C++ is the natural progression once your software begins to grow in size.

Again, .NET is not a group of languages. It is just a runtime (sort of a virtual machine). There is a library that sits on top of that. And there are languages that use that library and target that runtime. Your comment led me to conclude that you might have heard of .NET but are not aware of its entire stack and definitely not experienced with programming on that platform.

People working with .NET would talk of C# or VB.NET, but not .NET alone. And they are far removed of C++ which runs on bare metal. Your suggestion that C++ folks try C# would not be received very kindly.


----------



## kpedersen (Aug 19, 2012)

SR_Ind said:
			
		

> Your suggestion that C++ folks try C# would not be received very kindly.



Agreed. Not to mention C#'s inherent flaw of non-deterministic destruction. With RAII, C++ pulls off memory management elegantly without the programmer actually needing to do anything (other than wrap in smart pointers). Whereas in C#, you need to spam your code with lots of try/catch to ensure correct cleanup and stopping threads and stuff (it is horrendous). The hacky "using" keyword is broken too since it can only work in a single function rather than over the lifetime of a class.
When people suggest C# without mentioning these fatal issues, it does kinda suggest that they are lucky enough to not have spent much time researching or working with .NET languages.

Saying that... C++/clr (Microsoft's C++ .NET) is actually pretty decent.. it is a shame mono doesn't have this because it seems that Microsoft is going to drop it once C# becomes better at handling native libraries. This (afaik) is the only 100% (when using /clr:safe) .NET garbage collected language that also supports RAII so you can almost get the best of both worlds. (auto_handle is the clr equivalent of auto_ptr).


----------



## drhowarddrfine (Aug 19, 2012)

kpedersen said:
			
		

> C++/clr (Microsoft's C++ .NET) is actually pretty decent.. it is a shame mono doesn't have this because it seems that Microsoft is going to drop it once C# becomes better at handling native libraries.


Which is a reason why anyone wanting to use Windows languages could be exposing an Achille's heel making Mono, and therefore C#/.NET stuff, a dangerous road to follow.


> I know that .NET isn't a language, however it refers to a set of languages and most people are comfortable with just saying .NET to refer to them as a group.


Not to get off track or stir up the pot but I, too, have a problem with people trying to lump everything under the .NET banner because some of those languages have nothing to do with .NET at all.


----------



## SR_Ind (Aug 19, 2012)

C++/CLI or C++/CLR whatever it is called is indeed a second class citizen on .NET. It was introduced for C++ developers to pick up .NET library. Even I've used it.

With Windows 8, MS is going back to C++ as the primary language for development. As, *kpederson* pointed out its shortcoming, hence the furious back paddling. 

However, to be fair, .NET is an excellent framework. And the best part is that the CLR specs are ECMA standards, which means contrary to FOSS opinion it is not tied to MS anymore. 

Back to topic.

Few days ago Qt was bought out by Digia and their immediate goals are port for iOS and Android with more R&D for desktop (Nokia had begun to sideline desktop towards the end of its Qt ownership).

So, C++ is there with Windows, iOS, OSX, Android and Linux (X11 port). This where the market is moving.


----------



## Crivens (Aug 20, 2012)

drhowarddrfine said:
			
		

> See, those points are the exact opposite of what I've ever heard. Torvalds specifically talks about that in his piece.



I spoke about this as the third dimension of the problem. You can not blame a tool for how it is used. You can use C++ to elegantly slice the different parts of drivers into seperate classes and provide an easy way to create new drivers, specialized drivers, ... but all that can also become a complete trainwreck if you happen to have a certain amount of clueless developers on the team. And with C++, is is much easier to produce such wrecks as compared with C as you have more degrees of freedom to screw up and more power to lang that punch.

And while torvalds may be a skilled C programmer, I yet have to see some C++ code from him where it is demonstrated that he actually knows what he is talking about.

Lucy has some interesting points for this, using MacOS X as the example.


----------



## drhowarddrfine (Aug 20, 2012)

Crivens said:
			
		

> And while torvalds may be a skilled C programmer, I yet have to see some C++ code from him where it is demonstrated that he actually knows what he is talking about.



In his rant, he says they tried using C++ before.


----------



## nslay (Aug 21, 2012)

drhowarddrfine said:
			
		

> In his rant, he says they tried using C++ before.



He just doesn't know how to use C++. As flexible as C++ is, you can easily wall yourself in with the wrong design approach. Also, having come from C, I know first hand that you can't really approach problems with the same mindset as a C programmer.

As much as I despise them, established C++ design patterns do help prevent you from walling yourself into a bad design. These types of patterns aren't very intuitive either. Don't believe me? Go read about some of these design patterns for yourself. As abstract and useless as they might appear, they're actually used quite universally in projects like Qt, Clang and Firefox (to name a few).


----------



## Crivens (Aug 21, 2012)

drhowarddrfine said:
			
		

> In his rant, he says they tried using C++ before.



As I wrote : "I yet have to see some C++ code from him *where it is demonstrated that he actually knows what he is talking about.*"

No offense, I pull my hat when it comes to herding cats in front of Linus for what he does to manage the kernel. He also seems quite competent at C, but it may be a bit hard to spot code which is 100% from him in the kernel. I frankly tell that I did not take the time to dig some of it out. But upto now, his position about C++ is about as scientifically proven as mine regarding ruby. Tried it, did not understand it immediately, therefore most likely misused it and failed. But I am open minded enough not to blame ruby for my not liking it, and I am a bit offended that a person which seems competent and intelligent to me does not consider the possibility that he may himself be at fault. 

So, when it comes to Linus, let's file his rant under "using screwdriver as a hammer" but not under "reviewed research".

The question 'C or C++' (let alone Java, Lisp, Fortran or Cobol) can not be answered without knowing what the exact problem is and who is going to be doing the programming. Someone who is competent in Pascal but not Java, I would allow to use Pascal if no big arguments to the contrary are present. So, let Linus use C for all he wants as long as he get's it done without creating unmaintainable nightmares. But that does not mean that this is a rule which suddenly appeared on some stone atop some mountain.


----------



## drhowarddrfine (Aug 21, 2012)

You're not offending me. I'm just pointing out things I read.


----------



## valsorym (Aug 21, 2012)

UNIXgod said:
			
		

> What's the difference from c++ to objective . Is it just another superset of C or is there any specific feature or paradigm that differs from c++?



What's the difference from c++ to objective . Is it just another superset of C or is there any specific feature or paradigm that differs from c++?

I understand that, Objective-C it is real heir C, but that object oriented language.  C++ - object oriented language too, but it is a separate language, let's say: like C but not heir C.

As I understand, for example:

```
+-----+           +--------+         +------+
     |  C  |           | Pascal |         |  C++ |
     +-----+           +--------+         +------+
        |                  |
        |                  |
 +-------------+   +---------------+
 | Objective-C |   | Object Pascal |
 +-------------+   +---------------+
                           |
                           |
                      +--------+
                      | Delphi |
                      +--------+
```
** I'm not saying I'm right, but I think that C + + should be considered as a separate language, Objective-C as the successor Ð¡.

I would like to use Objective-C but it is very ugly syntax. :\


----------



## yoxter (Aug 22, 2012)

valsorym said:
			
		

> understand that, Objective-C it is real heir C, but that object oriented language. C++ - object oriented language too, but it is a separate language, let's say: like C but not heir C.




```
+-----+          
     |  C  |     ---- -->  +------+
     +-----+               | C++ |
        |                  +------+
        |                    |
 +-------------+       +-------------+
 | Objective-C |  --> | Objective-C++ | 
 +-------------+       +-------------+
```

I am not really sure but both are heir of C, because both are supersets of C, for example exist Objective-C++ than is a 
combination of C++ and Objective-C syntax. Objective-C++ adds to C++ the extensions that Objective-C adds to C.


----------



## Crivens (Aug 22, 2012)

drhowarddrfine said:
			
		

> You're not offending me. I'm just pointing out things I read.



That is good. Since I tend to question anything that is not nailed down in all directions and dimensions some people get annoyed at me for constantly poking holes into arguments and plans. For me, this is what I consider part of my job.


----------



## NuLL3rr0r (Aug 23, 2012)

valsorym said:
			
		

> I would like to use Objective-C but it is very ugly syntax. :\



Agreed!! The ugliest syntax that I've ever seen.


----------



## zhoopin (Aug 23, 2012)

valsorym said:
			
		

> I would like to use Objective-C but it is very ugly syntax. :\





			
				NuLL3rr0r said:
			
		

> Agreed!! The ugliest syntax that I've ever seen.


Ambiguous feelings.
Lack of familiarity with new language syntax and philosophy behind the structure of language is major cause of feeling like that.

This thread has been started a fortnight ago. For those who are familiar with one language beforehand, It's more than just enough time to learn the syntax of new language.


----------



## NuLL3rr0r (Aug 23, 2012)

zhoopin said:
			
		

> Ambiguous feelings.
> Lack of familiarity with new language syntax and philosophy behind the structure of language is major cause of feeling like that.
> 
> This thread has been started a fortnight ago. For those who are familiar with one language beforehand, It's more than just enough time to learn the syntax of new language.



No I programmed in plenty of languages in past 15 years including (if we count scripting too):
C++, C#, Perl, Ruby, Python, Lua, JavaScript/JScript,
ActionScript, UnrealScript, VB.NET, VB6,
Delphi/Pascal, VBScript, FoxPro, Logo, GW/QBasic
and CMake even Assembly (Of course there are languages
like C, Java, PHP which I had no experiments with).

It is ugly by any means!!


----------



## Crivens (Aug 24, 2012)

NuLL3rr0r said:
			
		

> It is ugly by any mean*s*!!



That is something I also found highly disturbing in objective-c. Being a compiler geek, I mostly value what the thing does behind the back, but the syntax from objective-c has the double inheritance of C and smalltalk. The "object" part is taken from a language with a very different syntax and thus feels pretty alien to the C part. The C part then looks alien in areas where a lot of object oriented code is crammed together. This is one point that was done a lot better in C++ (when leaving templates out), it fits a lot better into the "picture". 

Core of the ugly is, IMHO, the way to pass parameters to methods which is completely different to C in syntax. Passing more than one parameter simply looks ugly to the C eye.

But what the language offers in power is, is several areas, a lot better and clearer as C++. I would like to do some work with it, just to get to know it better and maybe love or hate it with more gusto and reason


----------



## NuLL3rr0r (Aug 25, 2012)

@Crivens

My English sucks a little bit 
Thank you for correcting me.


----------



## NuLL3rr0r (Aug 25, 2012)

From http://gcc.gnu.org/


> GCC now uses C++ as its implementation language [2012-08-14]
> The cxx-conversion branch has been merged into trunk. This switches GCCâ€™s implementation language from C to C++. Additionally, some data structures have been re-implemented in C++ (more details in the merge announcement). This work was contributed by Lawrence Crowl and Diego Novillo of Google.



From http://gcc.gnu.org/wiki/cxx-conversion#Rationale


> Migrating GCC to C++ as implementation language:
> C++ is a standardized, well known, popular language.
> C++ is nearly a superset of C90 used in GCC.
> The C subset of C++ is just as efficient as C.
> ...


----------



## SR_Ind (Aug 25, 2012)

GCC in C++? Linus will have a fit


----------



## Slurp (Aug 26, 2012)

I like C for it's simplicity, but whenever I start a project in it I start to miss C++ features at some point. That's especially true when I try to keep C90 compatibility...



			
				kpedersen said:
			
		

> Saying that... C++/clr (Microsoft's C++ .NET) is actually pretty decent.. it is a shame mono doesn't have this because it seems that Microsoft is going to drop it once C# becomes better at handling native libraries.


The .NET library is the most rushed through and undersigned standard library that I've seen. Sometimes it feels like a collection of ad-hoc hacks and for this reason I just can't stand writing in .NET. Or rather - I couldn't because now I just steer clear of it.


			
				SR_Ind said:
			
		

> However, to be fair, .NET is an excellent framework.


I'm hugely surprised to read this and would like to know what makes you like it so much.


----------



## kpedersen (Aug 27, 2012)

Slurp said:
			
		

> I couldn't because now I just steer clear of it.



Agreed, but unfortunately these days .NET is so well marketed that it is extremely prevalent in most software companies. My previous statement was mostly that I simply prefer writing in C++/clr than C#. However, native C/C++ and the best library for the job is really the *only* solution.

I think it is great that Microsoft is cooling off .NET and moving towards native C++ or Javascript, it is going to leave the "consumer-developers" standing around looking confused just like in the Visual Basic 6 days 

(But will they finally choose C++? Nooo, 'course not! The fools will probably choose some proprietary MS Javascript clone instead. WinRT? Then the whole cycle begins again...)


----------



## fluca1978 (Aug 27, 2012)

Well the C vs C++ endless debate.
Operating Systems are usually written in C for different reasons, mainly because to program OSs you have to deal with low level details, and low level details are not easily modeled thru objects (which are higher abstractions). Think about the mi_switch() function: that is a function that switches two threads, it is not something like "the only instance of the _scheduler_ object have to switch two object threads". This of course does not mean that OSs do not include objects: a process is an object, and structs represent them very well. After all, an object is a struct with the data and somewhere methods contained in a table. 
Another reason is about compilers: while it is simple todays to find a good C++ compiler, it was not in the past. This is why Gnome does not use C++ but C.
Last but not least there is to deal with the develooers: while a lot know quite well C, a few know C++ and in particular a very few know how to use it effectively.
Having said that, OSs can be developed using C++, as well as using Java and other languages. HaikuOS is one of such system (as far as I remember).


----------



## expl (Aug 27, 2012)

For me nature of the code I am writing will determine if I will use C or C++. You have to plan ahead to save time, things like code reusability, portability and processing features determine for me what language I will use. 

For example if I write really general code that I want to reuse in ruby/python later on I will definitely write it in C for painless porting as a native module. Another thing to keep in mind is if you will heavily use dynamic data types and hashing, because of lack of templates in C it gets very ugly and you have to drag a bunch of libraries with you, while stdc++ lib will cover most of it.


----------



## expl (Aug 27, 2012)

valsorym said:
			
		

> I would like to use Objective-C but it is very ugly syntax. :\



Its not about how pretty it is. Its more about having a clear separation of the layers in the syntax. Its easer to read through the code and see how Objective layer wraps the C/C++ code. At start it feels weird/wrong, but like with everything you need to get used to it.


----------



## fluca1978 (Aug 27, 2012)

expl said:
			
		

> Its easer to read through the code and see how Objective layer wraps the C/C++ code. At start it feels weird/wrong, but like with everything you need to get used to it.



Agree.

Moreover, Objective C could be considered a Java father, therefore it should not scare so much.


----------



## SR_Ind (Sep 1, 2012)

Slurp said:
			
		

> The .NET library is the most rushed through and *undersigned* standard library that I've seen. Sometimes it feels like a collection of ad-hoc hacks and for this reason I just can't stand writing in .NET. Or rather - I couldn't because now I just steer clear of it.
> 
> I'm hugely surprised to read this and would like to know what makes you like it so much.


Although this is off topic (unless someone moves this to a Mono/C# thread), let me answer.

I didn't get you, what is "undersigned" standard library?

To be direct to the point, .NET is one of the well designed libraries. I worked on the first project way back in 2001/2002 with the beta release. In those days there was nothing on the Internet. There was no complete documentation for the beta product. We did the project with whatever content there was in MSDN and .... intellisense of Visual Studio. In my opinion this is only possible when the library you are working with is a well structured, intuitive, with a sensible nomenclature.

To anybody coming from direct C background the library would seem weird. Similar complain was from Visual Basic programmers. It is due to lack of familiarity and experience with large scale object oriented development.

Talking of ad-hoc hacks, to my experience two libraries take the honour, GTK and Java.

How queer my choice of tools are C# and Qt...the opposites of the above two.


----------



## tommyjung (Sep 2, 2012)

https://michaelochurch.wordpress.com/2012/07/27/six-languages-to-master/

Reading this article will help choosing languages to learn. c++ does well on what it's good at in a very complicated way.


----------



## Slurp (Sep 2, 2012)

[OT]


			
				SR_Ind said:
			
		

> Although this is off topic (unless someone moves this to a Mono/C# thread), let me answer.
> 
> I didn't get you, what is "undersigned" standard library?



I meant underdesigned.



			
				SR_Ind said:
			
		

> To be direct to the point, .NET is one of the well designed libraries. I worked on the first project way back in 2001/2002 with the beta release. In those days there was nothing on the Internet. There was no complete documentation for the beta product. We did the project with whatever content there was in MSDN and .... intellisense of Visual Studio. In my opinion this is only possible when the library you are working with is a well structured, intuitive, with a sensible nomenclature.
> 
> To anybody coming from direct C background the library would seem weird. Similar complain was from Visual Basic programmers. It is due to lack of familiarity and experience with large scale object oriented development.
> 
> Talking of ad-hoc hacks, to my experience two libraries take the honour, GTK and Java.


What I experienced there was a mess of exceptions, inconsistencies and hacks. Frankly, I am happy to have forgotten most of them. But 1 horror will probably stay with me forever.
Equals / operator==.
Both are nice and have well defined semantics.
The only problem is that the standard library doesn't adhere to the definitions. For example strings. Or arrays. The latter is really outrageous. They didn't meet deadlines to implement comparison, so they made .equals work like ==. By .NET 3.5 (which I couldn't use BTW) they thought that comparing arrays might have some use. How did they fix it? Obviously, not by making arrays follow the standards as that would break compatibility. They added an external function.

BTW, I don't know GTK at all and barely touched Java.[/OT]


----------



## SR_Ind (Sep 2, 2012)

^^

Array comparison? One use case I remember was in an in-house GIS application, comparing line objects. Though I know people doing this with ordinary data sets as well.


----------



## fender0107401 (Sep 4, 2012)

CPP is not good, at least for me.

Read APUE2 will let you know why operating systems are always written in C.


----------



## numpad5 (Sep 6, 2012)

valsorym said:
			
		

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



I'm not much of a programmer as far as systems and hardware, but here is my opinion.

C++ and C have become quite close in the application development side, as an example you can easily use most libraries designed for C in C++ apps (like libsdl for multimedia)

C has a more strict coding style to it, its not as dynamic as C++ in the way you can write things and that makes it alot closer to the computer's machine language you are programming on in that you have to keep the program simple enough for both you and the machine to understand.

C++ has built in objects and other such things that are great tools but can easily overcomplicate things if you don't have great coding style and habits.

To sum up, I believe C is still used for its simplicity and the things that it is easier to NOT be able to do with it. I believe most system developers look for the most straightforward and simplest solution to get their code done, and most system level code doesn't need anything too much more advanced than what C has, plus most of the available code is already in C and it would be alot of porting.  C++ it is too easy to get lost in the abstracts of things like objects and templates.

It is like using every blade on a swiss army knife to put peanut butter on bread (C++), instead of just grabbing a butter knife and using that (C)

Just my opinions, and like I said, I don't do much system level stuff.


----------

