Thread: Is Visual Studio C or C++

Also disappointed to note that Tove T. is no longer involved in the martial arts. I guess she just had to give it up for the man! Ouch!

@abachler: of course, every self respecting N. American beyond first generation is like 1/8 squaw, and proud of it!

Originally Posted by abachler

Actually squaw is a very pejorative term (more offensive than the C word) that is generally frowned upon, as I was informed by my (now ex) wife who was 1/2 Tsalagi 1/2 French.

Agreed, just a very nasty attempt to imply that yer great gramma may not have been perfectly happy with the arrangement (but heck, who is?)

I make the same joke about my mom's (English) ancestors in relation to my seafaring dad (Danish), but to the effect that she's charmed anyway, and usually no one is that amused after they finish laughing. I totally like "native people". I have a mohawk, even.

Sorry.

Originally Posted by abachler

I wouldn't want to use pure C++ any more than I would want to use pure C.
(...)
Do I want to write an application without being able to use classes? No.
Do I want to have to write my entire application using nothing but classes? Hell No.

I use Functional/Procedural programming just like I use C/C++. Neither one can exclusively solve every problem in every domain and many solutions are both more intuitive and elegant when using both.

Just checking, but what do you mean by "pure C++"? When I think of "pure C++" in terms of language and libraries, I think of C++ without any language extensions, but possibly including non-standard libraries written in a "pure C++" style. In terms of "pure C++" style, I think of "multiparadigm programming", where the choice (which could be a mix) of procedural, object oriented, functional and generic programming is made as is appropriate to the situation.

Originally Posted by laserlight

Just checking, but what do you mean by "pure C++"? When I think of "pure C++" in terms of language and libraries, I think of C++ without any language extensions, but possibly including non-standard libraries written in a "pure C++" style. In terms of "pure C++" style, I think of "multiparadigm programming", where the choice (which could be a mix) of procedural, object oriented, functional and generic programming is made as is appropriate to the situation.

I thought he meant only the ++ side of the language without using any of the C functions.

That's the way I got it, too.

Originally Posted by cpjust

I thought he meant only the ++ side of the language without using any of the C functions.

Originally Posted by MTK

That's the way I got it, too.

I suggest that you read this article (PDF document) by Stroustrup that explains Why C++ is not just an Object Oriented Programming Language.

Originally Posted by MK27

Vis. the kernel team's attitude, I get the message that there will be NO TRADE-OFFS in the speed vs. ease department. Like none. Zip. Zero. Absolute priority. It is not like the kernel is just another app. They all depend upon it. So you stick with C, since you may be able to do it another way and come "close enough", but your chances of improving performance are nil. Zip. Zero. Also there's that maintainability/portability issue, tho IMO "maintainability" is probably much more subjective than most programmers want to let on.

I don't know how many times we have to bust this myth. This is untrue, false and utter nonsense.
This is a typical thing that C programmers often argue, that C++ is slower. That's not true. C++ can be slower in some instances, true, but so can C. Take the function pointers as an example. In C++, we could pass a function object instead of a function pointer, and it's actually proven to be faster.
Then there's generic code in C. Since you loose all type information, you usually have to do runtime checks to find out what it is. In C++, you don't, because the compiler keeps track of the type all the way.

Furthermore, C developers often roll out there own code for many things such as memory management. In C++, we already have facilities for these things and often they are more effective than the C counterparts! This is imply because this standard code has been written by professionals and profiled time and time again.
In a kernel, I might agree that C++ standard library functions might be problematic because they may not be fast enough, but they could still roll out their own solutions, which wouldn't be worse than the C solution, either.

C is not faster than C++ and C++ is not faster than C. However, some things can be slower in either C or C++, both have advantages and disadvantages.
So the zero speed penalty is just an excuse. They simply don't want to use or try C++. That's all.
Also, no one is going to rewrite an entire kernel in another language unless there were serious advantages with doing so, and C++ doesn't give enough of those benefits.

No, I don't think it's that the kernel's nature doesn't lend itself to C++, it's more like current kernels are not written with C++ in mind. Symbian is an OS written in C++, and I have no doubt a kernel can be, too. It might just be a different way of approaching the problem. That is what I think.

Originally Posted by Elysia

I don't know how many times we have to bust this myth. This is untrue, false and utter nonsense.
This is a typical thing that C programmers often argue, that C++ is slower. That's not true. C++ can be slower in some instances, true, but so can C. Take the function pointers as an example. In C++, we could pass a function object instead of a function pointer, and it's actually proven to be faster.

Would you care to find some proof of this? I seriously doubt that making a deep copy of an object is going to be any faster than dereferencing some pointer, so you must be referring to calling a member function via a reference to an object. This, too, is a pretty weak argument.

If you're calling a member function in C++, you know its name. So the equivalent in C would probably be calling, e.g.

Code:

void something_print(struct Something *something) {}

You only need function pointers when you don't know exactly which function you're going to call; when, for example, you're setting up callbacks or simulating inheritance. This corresponds, in C++, to overloaded functions. And in C++, you have the same sort of action: you have to look at the vtable to decide exactly which function to call. I'm sure this is comparable in efficiency to dereferencing a function pointer.

Then there's generic code in C. Since you loose all type information, you usually have to do runtime checks to find out what it is. In C++, you don't, because the compiler keeps track of the type all the way.

I agree that it's easier to write more generic code in C++, but usually the compiler doesn't have to make runtime checks because it generates different versions of the same code (for overloading, or templates, for instance). Unless I'm forgetting something here?

Originally Posted by Elysia

No, I don't think it's that the kernel's nature doesn't lend itself to C++, it's more like current kernels are not written with C++ in mind. Symbian is an OS written in C++, and I have no doubt a kernel can be, too. It might just be a different way of approaching the problem. That is what I think.

You are probably right, but the fact that Symbian is written in C++ is not "evidence" one way or the other; the context is not related.

People have written operating systems in perl, .NET, and python, but for obvious reasons, it would ridiculous to write a kernel that way. Or maybe not, since AFAICT those OS's used a custom kernel with interpreters built into them.

Anyway, I would guess for certain a kernel could be written in any compiled language. Why not? Of course, some person(s) would have to actually do it, and that person would have to choose a language, and the "logical" choice would probably be whatever that person prefers.

Originally Posted by Elysia

No, I don't think it's that the kernel's nature doesn't lend itself to C++, it's more like current kernels are not written with C++ in mind. Symbian is an OS written in C++, and I have no doubt a kernel can be, too. It might just be a different way of approaching the problem. That is what I think.

I agree it can be done (I've done it). I guess I should have said, the Linux kernel does nto lend itself to being well written in C++. Mostly because of the portability issue but also because of the design choices made during its development. Could you write the thread scheduler as a class, sure, but why would you rewrite a piece of code that is already optimized and functional unless you could squeeze extra performance out of it. If you make each thread an object then the assumption is you will dynamically allocate the objects rather than simply have a predefined array for thread entries. Which entails an extra pointer calculation as you index into the array of thread objects, and then have to index into the object to retrieve the actual information. I think its instances like this that the C programmers are talking about. Is an extra index that computationally expensive? Not really. Can it be done, yes, does it reduce performance at all, yes it does. Does the fact that it reduces performance, however minuscule the amount, conflict with their policy of absolute speed above all other considerations, definitely. You are talking about an area of the system that can bog down everything. If a solution in C++ was somehow faster than the best possible solution in C, then I'm sure they would (grudgingly) accept and use it. The primary reason for the stonewalling of C++ on items where it is just as fast, but no faster is the correct assertion that once they let C++ programmers in it creates design requirements that are not easy to remove. C is also much closer to the hardware than C++. Most language features in C translate directly into a single assembly instruction, while C++ features do not.

Originally Posted by dwks

Would you care to find some proof of this? I seriously doubt that making a deep copy of an object is going to be any faster than dereferencing some pointer, so you must be referring to calling a member function via a reference to an object.

The canonical case of what Elysia is talking about is the passing of a function object as a predicate to std::sort, as opposed to passing a function pointer as a predicate for qsort. The function object is cheap to copy since it usually does not even have any member variables, thus there is no penalty in doing a deep copy. However, apparently the compiler is able to perform optimisations with the function object that it cannot do with a function pointer.