Printable View
A few things i never quite found the answers for:
what does return do. I never really understood when something should return (1); or return (0);
if you call a function, that say does a quick calculation, but doesnt pass anything back to the function taht called it, should it return 1 or 0?
Is C language obselete? University is teaching us C, but why not C++? Its difficult in C to do things like basic graphics, etc, would you ever nowadays write a commercial program in C??
To start from the back: C is absolutely not obsolete. It may not (proportionally) be as important as it used to be, but there are many things that are actively developed in C.
As to return, it does two things:
1. Tells the compiler what you want your "result" (or "return value") from this function to be.
2. Tells the compiler that "I would like to leave this function now, please".
The "result" of a function is what you get back as a result, for example:
a is given the return value from sqrt, which [assuming correct C library code] should be about 1.41Code:double a = sqrt(2.0);
Your "middle" question about "what to return from a function that doesn't pass anything back", then the function should really be declared as a "void" function. That is the way to tell the compiler "I'm not going to return anything from this function". It makes it invalid to use the return value from the function.
--
Mats
Depends on the convention you follow. If you just want to know if the function executed without errors or not, you could return any value you like. General convention in most libraries I have come across is that functions return 0 on success and -1 if there was an error.Quote:
if you call a function, that say does a quick calculation, but doesnt pass anything back to the function taht called it, should it return 1 or 0?
C is not obsolete. But, it is not the language of choice for commercial product development either. Your choice of language depends strongly on the kind of product you are planning to develop. C is a good way to start off with learning how to program. I am pretty sure your university will have courses in C++ in higher semesters.Quote:
Is C language obselete? University is teaching us C, but why not C++? Its difficult in C to do things like basic graphics, etc, would you ever nowadays write a commercial program in C??
I wouldn't say that "it's not the choice for commercial development" - the choice of language, as you say, depends on many things. In smaller projects, and particularly where code-size vs. development time favours code-size [such as drivers, kernel code, embedded systems], the C option tends to be the choice.
In cases where:
1. Code is very large anyways.
2. Development time is more important than code-size.
then C++ or some other higher level language is preferred.
Note I am NOT saying that C++ automatically is disqualified in the drivers, kernel, embedded scenario - far from it, I work with a rather large embedded OS that aside from some third party hardware drivers [written by the third party in C because they are designed to work on OTHER OS's too] is entirely written in C++, and it is for systems with medium-level memory constraints (expected to run on a system with a dozens, but not hundreds, of megabytes).
--
Mats
I don't think so, but that's subjective.Quote:
Originally Posted by PING
I believe C++--or any other high level language for that matter--is a great--possibly the best--way to start off with programming.
C is difficult because it was meant for low-level stuff, so in terms of getting lots done in little time, C is indeed obsolete.
However, because C takes less time to implement vs C++, it's still used in spaces where every byte of memory or bit of performance counts. Especially when the systems are not large.
So it depends on what you want to do...
If you want to make general computer software, by all means, go for C++.
If you want to make programming for special systems, many embedded systems, then think about learning C as an alternative.
If you don't like low-level stuff and never intend to work on special systems, then by all means, go for C++.
my opinion in this matter is different.learning c first definitely eases your understanding of other languages.that's why i think most of the universities still prefer to teach c instead of c++ or some other modern language.and yes as far as i know UNIX was the OS written completely in c which shows that operating systems can also be written in c.
The only reason I see that C++ is "better" for learning is it's object orientated. But that alone is hardly a good enough reason to choose C++ over other object-orientated languages. But the distinction for learning certainly depends on what's being taught and for what purpose.Quote:
Originally Posted by BEN10
But let's not step into another argument, (some) people are rather one-sided.
That statement is a bit misleading considering that most operating systems are written in a combination of assembly and C, while hardly any are written purely in C++.Quote:
Originally Posted by BEN10
And a major reason for this has nothing to do with C or C++, but rather that most operating systems in use today were originally written some 10+ years ago by programmers with several years of experience - which meant that they started prgramming before the 1990's, most likely. Whilst C++ technically existed at that time, it was neither mature, nor commonly used.Quote:
Originally Posted by Memloop
And you CAN NOT write an OS in C or C++ alone. There will be some lines of assembler involved to do some of the tricky bits that deal with specific registers of the processor. And for most machines, there is a need to have a few instructions of assembler code to set up a suitable environment to run C itself.
--
Mats
Each to his own, but some kernel developers still won't touch C++ with a ten-foot pole: Linux: C++ In The Kernel? | KernelTrap
Clearly C++ leaves something to be desired when it comes to low-level programming, or there wouldn't be projects like EASTL and Embedded C++.
The "embedded C++" project would not compile our code where I work. We use for example namespaces [and I don't REALLY understand why namespaces are causing any problem with embedded systems].Quote:
Originally Posted by Memloop
I think for a lot of things, C++ and OS kernel development require a bit more developer skill [and I don't say this to brag, as I don't actually work on the Kernel code myself other than by implementing drivers that are running in kernel mode]. But C++ can do all the things that C can, and if you understand what you are doing when you design your C++ code, you can do everything that a C kernel does, in almost identical manner, but with a more controlled environment.
Note that most "embedded C++" (loosely termed, not specifically the EC++ project's definitition) is probably NOT used for Kernel code.
However, C is often more "obvious" as to what goes on in the code.
--
Mats
No, it just shows that the developer is biased.Quote:
Originally Posted by Memloop
It's true that C++ provides a lot of high-level constructs such as std::string, std::vector and so on. But then again, they don't HAVE to use them. And C++ supports far more things that C can only dream about. Yes, they can be implemented in C (because many C++ compilers is/was written in C), but it is a pain, difficult and time-consuming.
Furthermore, they can easily write their own libraries that is specially suited for kernel work instead of using standard containers. But heck, you can still have full control over allocations with the use of Allocators.
They are not even required to use exceptions if they do not wish to, either.
So it boils down to that the kernel wasn't designed for modern C++ in mind, and so the infrastructure might not support everything that they need.
Writing a C++ kernel from scratch, however, I'm sure you will get different results.
And lastly, let me add that C++ can do all that C can and much more.
And I believe one of the reasons for "Embedded C++" is to trim C++ down, to make it less challenging and time-consuming to create a C++ compiler for the system. Not that it is poor for low-level programming.
I'm going to quote a comment from the page I linked to:
Quote:
If we are going to disable exceptions, not use object-oriented style and develop our own memory-management routines, what would be the point of using C++
Quote:
Originally Posted by Memloop
Of course, if you are NOT using object oriented style or any other feature of C++, then C++ is just a bigger C compiler. And there is no point in that. However, there are OS's out there that you can do "new" inside the kernel code [and it does what you expect, even if it's not EXACTLY THE SAME as in user-mode]. Try/catch may not be implemented for kernel code, and I doubt much kernel code uses STL for example. But that doesn't make object oriented style can't be used in a more limited way.Quote:
If we are going to disable exceptions, not use object-oriented style and develop our own memory-management routines, what would be the point of using C++
--
Mats
Type safety, generic programming facilities, abstraction.Quote:
Originally Posted by Memloop
And once more, the kernel is just built using year-old technologies, so it doesn't support any modern technologies. The foundation is flawed.
That doesn't mean C++ is at fault - it means the foundation is.