Thread: C is ssssslooooowing me

GTK is ugly. GTK+ is for C++.

Eh, GTK+ is a C library, and it is not the only GUI library out there (though you might find them all ugly, even with skinning, since that is a matter of taste). Perhaps you are thinking of Gtkmm when you say "GTK+ is for C++".

I can only write CGI using C, may be I will try that too for Web.

There are CGI libraries available for C++, though these days web development is far more common in Java, PHP and Ruby than C or C++.

In short all of the above and more.

Actually, if you simply want to learn another programming language, all this talk about speed is useless, whether it be the speed of development or of program execution. Just learn the programming language you have in mind.

Seeing as you aren't going to write programs for embedded systems or other machines whose hardware isn't top notch, I would say that C++ would give you the best of both worlds since C++ is backwards compatible with C.
Many frameworks are C++-oriented simply because C++ is more suited for such tasks.
But this may all irrelevant to you.
You may try a language and stick with the one you find to suite your tastes best. Perhaps start off with C++ since books often do teach C basics before digging into C++ stuff. Then you can specialize yourself in one language if you want, or learn both.

Anyway, I think that's my recommendation if you want to go the C/C++ route.

I think I was just being a little ignorant and a little over enthusiastic about simplicity of C language.

Speed of development is a compromise. You can have lots of freedom (which often translates to being able to write high-performing code), or you can have a language that gives you lots of functionality - but not quite as much freedom.

C is a low-level language. It gives the developer a good level of control of EXACTLY what is going on. But this also means that the language is quite complex to develop code in - because you need to give the compiler a lot of details of what you want done, and how you want it done, when you want it done, where you want it done, and which colour you want it done in. On the other extreme we have shell-scripts and batch-files for example. They don't allow much flexibility or detail on what gets done - but in a few lines you can write something that does quite a bit of work. However, if it's calculationally heavy, then it's going to take quite a bit of time to complete (assuming you can even express what you want done). And like Ford Model-T, you can have it in any colour you like, as long as black is the colour you like, and it's delivered when it's ready - whenever that may be.

Assembler goes a step further than C, and thus takes even longer to develop code in.

Unfortunately, it's hard to define a language that gives the programmer freedom and control, as well as simplicity in use. C++ gives the user some choices here, since if you want full control, you can use it like C (for the pedants who like to point out that C and C++ do not support exactly the same things, it is ALMOST the same language as C), but you can also use the Standard Template Libraries (STL), and various other "ready made" solutions that give a reasonable compromise between development speed and freedom.

Of course, to write high-speed code, you also need to use the right algorithms - if the programmer uses the most stupid bit of code in highly optimized assembler, it will probably not beat a "slow" language using a fast algorithm. Being clever about things beats having a fast language. We can estimate that the speed-up of a fast language is about 10x that of a slow one (it obviously varies a bit - 2x - 30x would be a likely range). But if we take an example of searching, where we have 1 million items in a list, and the "stupid programmer" chooses a linear search - on average, we will search half the list, so 500000 "hits" on the list. A binary search will do the same in maximum log2(1000000) "hits", which is 20 "hits". So it's about 2500x faster.

--
Mats

C is quicker, but I doubt you would see a big difference unless you are dealing with very large programs.

Originally Posted by matsp

Speed of development is a compromise. You can have lots of freedom (which often translates to being able to write high-performing code), or you can have a language that gives you lots of functionality - but not quite as much freedom.

Thank you for a detailed well explained answer. But I am unable to see the point here. I see no flexibility loss when doing Perl. I want list of file names. Easy. I want them sorted. Easy. I want them based on a pattern. Easy. What I lost here? Flexible also. I can do whatever I want.

C is a low-level language. It gives the developer a good level of control of EXACTLY what is going on. But this also means that the language is quite complex to develop code in - because you need to give the compiler a lot of details of what you want done, and how you want it done, when you want it done, where you want it done, and which colour you want it done in. On the other extreme we have shell-scripts and batch-files for example. They don't allow much flexibility or detail on what gets done - but in a few lines you can write something that does quite a bit of work. However, if it's calculationally heavy, then it's going to take quite a bit of time to complete (assuming you can even express what you want done). And like Ford Model-T, you can have it in any colour you like, as long as black is the colour you like, and it's delivered when it's ready - whenever that may be.

I was impressed with how simply a language can be expressed. Which can do do much of stuff. I am not a fan of brain........ language. Which means being small is not my preference. But C being so small and still so useful is what I like. When I say C is slowing me, I mean, for example:
in Perl I would read a line like this:
$line = <STDIN>;
In C I had to estimate my longest possible length of line. Then create a char[] large enough. Then after reading from stdin I had to make sure no data was left in input buffer.

But on a positive side, Perl can not write another Perl. C can write many Perl like languages.

Assembler goes a step further than C, and thus takes even longer to develop code in.

Yeah. I just ordered my Pentium* manuals from intel. They are shipping for free. I am really excited about MMX/SSE* struff. I know nothing about them yet.

Unfortunately, it's hard to define a language that gives the programmer freedom and control, as well as simplicity in use. C++ gives the user some choices here, since if you want full control, you can use it like C (for the pedants who like to point out that C and C++ do not support exactly the same things, it is ALMOST the same language as C), but you can also use the Standard Template Libraries (STL), and various other "ready made" solutions that give a reasonable compromise between development speed and freedom.

Shell scripting is extreme example. It is more of command control language rather than a programming language. But I do not get the point of flexibility loss. Again.

Of course, to write high-speed code, you also need to use the right algorithms - if the programmer uses the most stupid bit of code in highly optimized assembler, it will probably not beat a "slow" language using a fast algorithm. Being clever about things beats having a fast language. We can estimate that the speed-up of a fast language is about 10x that of a slow one (it obviously varies a bit - 2x - 30x would be a likely range). But if we take an example of searching, where we have 1 million items in a list, and the "stupid programmer" chooses a linear search - on average, we will search half the list, so 500000 "hits" on the list. A binary search will do the same in maximum log2(1000000) "hits", which is 20 "hits". So it's about 2500x faster.

Yeah. In a book. This was the first thing that inspired me. That think better algorithms first. They will speed up in any language.

> But on a positive side, Perl can not write another Perl.
Sure it can.

Originally Posted by JFonseka

C is quicker, but I doubt you would see a big difference unless you are dealing with very large programs.

Speedwise or coding wise?

Originally Posted by Jackie Chan

I was impressed with how simply a language can be expressed. Which can do do much of stuff. I am not a fan of brain........ language. Which means being small is not my preference. But C being so small and still so useful is what I like. When I say C is slowing me, I mean, for example:
in Perl I would read a line like this:
$line = <STDIN>;
In C I had to estimate my longest possible length of line. Then create a char[] large enough. Then after reading from stdin I had to make sure no data was left in input buffer.

C++ way:

Code:

std::string line;
std::getline(stdin, line);

So as mats says, C++ gives you high-level functionality for a lot of things, but still allows you to do low-level things such as C, which is why C++ is so terrific (it is also not as prone to security issues such as buffer overruns as C).

Originally Posted by Elysia

Speedwise or coding wise?

Obviously speedwise, coding wise it's longer because of the extra manual security you have to add in everywhere

In this case, flexibility means that YOU can choose how you want to do things, but also have a low enough level of function that you can DO whatever you like. It's no surprise that C is a language with low-level functionality, as it was originally written to be used for porting operating systems (in particular Unix) and the related tools and utilities that the OS needs.

Perl is a flexible language in the sense that it allows you to do many things - but it's flexible at a higher level - it gives you many functions that are pre-defined (or in libraries).

Perhaps flexible isn't quite the right term - detailed is probably a better term to use. The details of what is going on in Perl is vague (as in, you don't "know" what happens when you write

Code:

$line = <STDIN>;

- aside of course what it says on the tin: It reads a line of text from stdin - but what the tin doesn't say is what ingredients where used.

And of course, you can write a function in C that reads a line of arbitrary length. You just have to do the same thing that Perl does: Allocate a small amount of memory (buffer), read a char at a time until either end of line or buffer is full. If the buffer is full, re-allocate a bigger buffer. Keep on doing this until end of line is found. Of course, you will also have to remember to free the string after you've finished using it. The drawback is that you don't get a function like that in C, but the benefit is that YOU get to decide whether it's flexible (here meaning reading as much as you like), or a bit less flexible with regards to the data size and a bit faster in execution (because it doesn't need to allocate and potentially re-allocate [maybe several times] the string).

However, once you have written a input function for "any length" string, you can of course use it in as many programs as you like. After a while, you get a good set of "useful functions" that you can use for all sorts of things, and you don't need to re-develop these for every project. Of course, some of the code is decidedly specific to a project, but a lot of functions are often quite frequently used in other projects.


One of the drawbacks with perl is just the management of variables and memory - because perl does this FOR you, it will also spend some of it's time "checking how much and what memory is used", and clearing up unused memory. In extreme cases, this can take almost as long as the actual code takes. In other case, it doesn't create much overhead at all - it all depends on what you are doing and how you go about doing it.

In C, it's up to you, as a programmer, to do the right things with memory. The language as such only give you the most primitive functions (malloc, free and realloc - and a few other related functions), but you can also store variables globally, or use local storage in a function. The overhead of using any of these is pretty minimal, and there's no "maintenance" aside from exactly what you have written - there's no code going round checking if something is still in use or not [not counting the overall memory handling of the OS, whcih happens whatever language you use]. Again, the "details" are up to the programmer, who can choose between several different solutions (including implementing something that resembles the garbage collection [which is the technical name for "maintaining which bits of memory are used] of Perl).

Because of the higher level of detail, it also means more work for the programmer.

--
Mats

Originally Posted by JFonseka

Obviously speedwise, coding wise it's longer because of the extra manual security you have to add in everywhere

I doubt you will see a speed difference between C/C++ at all for generic programs.
And C is also slower due to everything you have to handle - from memory allocation and deallocation, to resource release, to testing time and debug and memory errors, etc, etc, etc.
It's the price you pay for extra power. If you want to avoid that yet still have a blazing fast language, try C++.

Originally Posted by Elysia

I doubt you will see a speed difference between C/C++ at all for generic programs.
And C is also slower due to everything you have to handle - from memory allocation and deallocation, to resource release, to testing time and debug and memory errors, etc, etc, etc.
It's the price you pay for extra power. If you want to avoid that yet still have a blazing fast language, try C++.

How is that so? If it's already built into C++ from the libraries it would be calling larger libraries and taking more time to do all the processing, whereas with C it is manual so you are selectively choosing what you want and hence cutting down on the behind the scenes code that is getting executed.

Ah, but the libraries are also insanely optimized, probably more than what you can do by hand, so by that definition, I'd definitely say it's faster.
C++ may be a little more overhead, but it's hardly that much. It's nowhere near dotNet or Java.

Originally Posted by Elysia

it is also not as prone to security issues such as buffer overruns as C.

Subject to programmer doing the right things - and programmer not doing the right thing is where most security issues come from in the first place. I'm not saying that C++ isn't safer, just that it's based on using the correct forms of various functionality, and understanding for example buffer overrun problems and doing "stuff" to prevent it from causing problems (security or otherwise).

C++ as a language is very marginally safer than C - but such things as STL help making it easier for the programmer, because the programmer can use that directly, not have to write his/her own code to solve some particular problem.

When it comes to speed difference in C and C++, I can guarantee that there's no difference - the only difference is in which way someone chooses to solve the same problem. C++ is deemed slower because often people don't use it correctly (or put another way, they do things they wouldn't have done in C, either becasue they didn't understand what the C++ code does, or they couldn't do it that way in C in the first place, or simply "because the programmer made different choices"). If you understand what the code does (in fair detail), then C++ will be just as fast for doing the same thing as C.

There are a few things in particular that is common in C++:
* Unnecessary use of new/delete - where a statically sized allocated choice is just as good.
* Doing "tiny functions that do nearly nothing" - typically getters and setters that don't NEED to be such.
* Too much inheritance, leading to lots of calls to chained constructors, and virtual function calls.

Of course, just as there is "too much", "too little" can be wrong too - coding style and choices can be very important for getting things right, and getting the balance right between object design and the algorithms.

There are quite a few cases where, if you are not very clever with stuff, you can make C slower than C++ - the typical case would be where you want polymorphism. Calling a function on an object is almost free, whilst doing a switch-statement in every function to figure out which type of object this is, and how do deal with it, may be an extra overhead. The other C solution is to set a function pointer to the right routine for each object - in which case we're implementing C++'s virtual function in C, so the same solution, with the same type of overhead.

--
Mats

Originally Posted by matsp

C++ as a language is very marginally safer than C - but such things as STL help making it easier for the programmer, because the programmer can use that directly, not have to write his/her own code to solve some particular problem.

Of course, but it we don't use STL, then typically we must rely on C stuff (unless we use 3rd party, which probably uses STL), so we could argue that we're back into "C++/C" (C inside C++), so it isn't truly C++.
C++ provides a safe(r) framework which we can use to avoid security issues, but is also backwards compatible with C, which means if you choose that route, you're back to those issues again.