C vs C++ - your opinion.

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++?
 
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.
 
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.
 
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.
 
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.
 
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#.
 
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.
 
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.
 
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.
 
Garbage collection is where I am not up on speed in objective-c. Is it using reference counts or some more elaborated ways?
 
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
 
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.
 
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.
 
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.
 
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 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.
 
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
 
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.
 
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
 
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
 
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.
 
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).
 
Back
Top