|
pasztorpisti wrote: Again, the only reason for the existence of C/C++ is massive amount of legacy
code.
Nonsense.
At one time languages like COBOL, ALGOL and FORTRAN had massive support and massive amounts of legacy code.
But programmers have moved on from those languages for various reasons which although often subjective are probably based on non-explicit objective reasons.
Yet that hasn't happened with C/C++. C/C++ fills a need that other current languages do not.
pasztorpisti wrote: (like header files that terribly slow down the compile time).
Err..the only ones that think that is a significant problem are those that don't know how to design (nothing to do with language choice) or those that can't recognize a poor design when one sees it.
|
|
|
|
|
The less mistakes a language lets to make, the better the language is. Its not real knowledge to learn to deal with the idiotic features of a complex language. If you work in a big team its more likely that someone will be unable to "design". On the other hand the header include are nowhere for example compared to turbo pascal/delphi units. Every other normal language uses some kind of "units" that contain data preprocessed for the compile to make things faster and easier. On the other hand only people how don't have experience with massive codebases don't feel the significance of the slow compilation times caused by header includes.
|
|
|
|
|
pasztorpisti wrote: The less mistakes a language lets to make, the better the language is.
Wrong.
If you spend even 10% of your time fixing "language" mistakes versus logic/design/requirements mistakes in your code then at best you are an atypical developer.
pasztorpisti wrote: If you work in a big team its more likely that someone will be unable to
"design".
If you work on a big team then it is almost 100% guaranteed that complexity issues will become the most serious development impediment.
pasztorpisti wrote: Every other normal language uses some kind of "units" that contain data
preprocessed for the compile to make things faster and easier....
As I already said, if you think this is a a significant problem in C/C++ then it is because there is a problem in the design.
And the SAME exact problem can show up in Java/C# projects.
|
|
|
|
|
pasztorpisti wrote: don't feel the significance of the slow compilation times caused by header
includes.
Granted I haven't programmed large scale C/C++ applications in 10 years, but I did do a lot of very large scale C and C++ applications before then, and it was common practice to use Precompiled Headers. There should be no need to be continually chopping and changing headers around, so I don't see why you would have such a massive problem. In fact, this was one of the nicer features of Visual C++ 6 - the ability not to recompile parts of code that hadn't changed.
|
|
|
|
|
Agree, precompiled headers is a nice 'hack' of modern ages, but you can not put everything into precompiled headers. As an addition I would note that using just visual studio is luxury, its one of the fastest compilers (if not the best in this regard) and the speed gain of its precompiled header feature is also the best. You can not include everything in your precompiled header because that makes iterations on your project much slower and uncomfortable. If you include something in your pch then a single unit compilation (ctrl+f7 in VS) wont detect the changes in headers that are referenced by the pch. OK, then you recompile the pch as well, but thats quite cumbersome. Instead I mostly put the headers of other referenced libraries the pch of a given library, thats often a good tradeoff in a well organized project where inter-library includes and predeclarations are used well without unnecessary header-from-header includes.
I have a more comprehensive list of reasonings against headers, please see the link below instead of reading this flame war, this is just pointless spinning around a small thing I've mentioned earlier.
http://www.codeproject.com/Messages/4377527/Re-What-makes-C-and-Cplusplus-a-good-language.aspx
|
|
|
|
|
Regarding the power and the popularity:
Being the language that was used to develop both windows and Linux operating systems is a proof that supports c\c++ as the best middle level languages not the contrary. I think this is because accidentally c++ was the first most complete in logic language that has been invented, since then, even now.So most of people learned it and wrote their programs with it. That is why it became the most popular.
The fact that most of people use it and recommend it for their friends because they don't know except it, i think this is false, especially for the professional programmers who do this for living. You will find most of them master more than 3 or 4 languages. Most of the people still use it because it is still valid for most of purposes. You can code for any operating system, any new device. For example if I'm using vb can i code programs for i pad??!!
So i agree with you for coding for general purposes you or we can chose any other easier language, this is correct, and i support, but regarding serious issues and for those who want to program for many purposes being real professionals you will find yourself forced to chose c++.
Regarding load and other technical issues:
Sorry, the reasons you mentioned for considering C++ not the optimal language, for example the arrange of header files, i think it returns to your team bad choices not to the language itself. The lines of code are compiled the order you put. Even if we agree and i agree that there is nothing optimal, especially at the field of science, and we are expecting the better. Tell me what is the alternative you propose to get rid of C++. I accept all alternatives. Is there anybody find something makes his life easier and not following it. I think he is ........ hahaha. You my dear mentioned the problem without mentioning the solution. Propose a solution and let us discus. The fact is , i think , it is difficult and expensive to write a new language like that one you and we dream of. Even if some company did so, and i think some did especially Microsoft, they wouldn't release it for commercial use easily like that. That would be one of the company precious treasures, and will be kept as a secret. No one these days invent something makes his work easily and let it go in public like that.
Regarding the market side:
Microsoft is trying to kill C++ to control the market when they make all visual studio equal regarding linking and compiling but i thing they wouldn't succeed, because they live on the planet beside other human beings. And the fact is however they try make other programming languages easier providing it with new libraries the sum of all other programmers that dealing with different operating systems will tend to C++.
Warm regards,
modified 20-Sep-12 5:29am.
|
|
|
|
|
ah_ga_ah wrote: for many purposes being real professionals you will find yourself forced to chose c++
Agree with the whole paragraph. Oh my god! Finally someone gets it!!!  Thank you!!!
ah_ga_ah wrote: Sorry, the reasons you mentioned for considering C++ not the optimal language, for example the arrange of header files, i think it returns to your team bad choices not to the language itself.
This is at least a decade old legacy code, how the hell could we grow out 2 million lines of code?  Anyway an include hell can be rearranged in 1-2 days even in such a big project if you did it a few times. Just mentioned this to show that headers are bad in general because they give you one more unnecessary problem to look at. Such big codebase is usually grown by big companies who replace their people relatively often and not all of them are good or able to maintain some aspects of such a codebase. I'm also making mistakes. As a result more and more mistakes are made if the language allows that because noone is superman. Its sad but this is not the first big codebase I'm working with and most of them suffers from some problems that could be avoided with a good language that doesn't have the deficiencies of C/C++. C/C++ is way too allowing language.
ah_ga_ah wrote: You my dear mentioned the problem without mentioning the solution. Propose a solution and let us discus.
Agree, I haven't mentioned a solution because "everyone knows" that there is no true alternative currently. I didn't want to do that, my post had a totally different purpose. I wanted to point out that having no alternative still doesn't mean that C/C++ stands it ground well in every aspect but you understood this.
ah_ga_ah wrote: <layer>The fact is , i think , it is difficult and expensive to write a new language like that one you and we dream of.
Here comes the reason for my post: I think not every people are dreaming of that language. Lot of people know only C and/or C++ thinking that its the best language of the world for everything and they are just lying in the matrix without seeing the C/C++ defects. My post just wanted to open some eyes, but most of them is OK with their lives in the matrix. I guess you are the only poster in this discussion having some understanding of my cries.
The sum of all my posts, my opinion: C/C++ knowledge is quite useful today because of the massive legacy codebase, but as a general purpose programming language it has way too many defects accumulated over the decades.
|
|
|
|
|
pasztorpisti wrote: Such big codebase is usually grown by big companies who replace their people
relatively often and not all of them are good or able to maintain some aspects
of such a codebase.
And of course none of that has anything to do with a specific language.
pasztorpisti wrote: Its sad but this is not the first big codebase I'm working with
Perhaps you will get to work with a well designed system some day.
pasztorpisti wrote: Lot of people know only C and/or C++ thinking that its the best language of the
world for everything
Many people think that the language that the primarily use is the "best" language for any of a variety of things. Some even refuse to consider the possibility that any other language might be better for anything else.
That however has nothing to do with a specific language.
pasztorpisti wrote: but as a general purpose programming language it has way too many defects
accumulated over the decades.
Of which you cite your personal observation of nothing more than slow compile times. And apparently at least one of which the 'best' choice was made to fix it by throwing hardware at it. I can assure you that any number of people have attempted to throw hardware at systems to fix performance problems which only produce marginal improvements.
Looking at requirements, architecture and design however can lead to orders of magnitudes improvement. And that has nothing to do with language.
|
|
|
|
|
pasztorpisti wrote: have other design failures (like header files that terribly slow down the compile time)
That's not a design failure. Something other woudln't be possible at that time.
First Header-Files were made for easy reading classes. There was no Syntax-Highlighting or code-analysis while editing. You had jsut the VI.
Second Point: It was easier to compile that with 16kb or less many machines had in those days, instead of building crossreferences at compiletime.
pasztorpisti wrote: A minimal amount of assembly to communicate with hardware, a thin layer of relatively high level but unsafe language that allows for manual memory management in the low-level part of the operating system, and a high level safe language that can be used to write the top level of the operating system and the user programs
I think Oberon can do all three levels. But who programms in Oberon at all?! 
C/C++ is fast, lean but it's not designed for everything. It's good to be backend for complex algorithms but not for frontend.
There are tools which close all memory leaks, but they are very expensive.
------------------------------
Author of Primary ROleplaying SysTem
How do I take my coffee? Black as midnight on a moonless night.
War doesn't determine who's right. War determines who's left.
|
|
|
|
|
|
I thought there is something like this goin' on. That's okay. 
|
|
|
|
|
Just though you should know
|
|
|
|
|
Thank you!
|
|
|
|
|
First, because there is so much C/C++ code out there still running. With C/C++, there is no translation layer and it is true compiled code where some are interpreted. Sure you can get compilers for Java and VB that will create native code but you also lose portability, the reason for Java in the first place.
With C/C++, you have access to everything. This isn't a big problem for application developers but for driver programmers, it is a huge issue. C/C++ is also easier to write drivers than assembly.
But then, what does it really matter if C/C++ hasn't been killed off with Java, VB.NET, C#, SmallTalk, and others? If you don't need it, don't worry but they are good tools to have in the tool chest.
You do have to be careful with memory use. There is no garbage collector to save you so if you allocate it, you have to release it. This control is a huge asset but you do have to know how to use it properly. I like using C/C++ because I am most familiar with them. The other thing is I've gotten so I prefer the total control I have.
|
|
|
|
|
Why shouldn't the industry still use it? If it worked for them in the past, and they already have the programmers experienced in its use, why take the risk and switch to something else?
And besides, in many areas it still makes sense to use C/C++ rather than presumably more advanced languages:
1. Existing low level drivers are mostly written in C, and when adding a new driver it would needlessly complicate the interfaces and introduce additional sources of errors.
2. Similarly, Unix and Linux related OSs are written in C/C++, and writing any OS extension in another language would just complicate matters needlessly.
3. Embedded devices usually have much less resources available (processor, memory capacity), and there may only be a limited amount of compilers available for the OS being used. This makes languages like C/C++ a more attractive choice, as they can better deal with these conditions than some modern languages that were designed with the resources and OS-functionality of a full-fledged workstation in mind. E. g. you won't usually find .NET on embedded devices. 
4. Real time applications often require full control of algorithms for time critical functions. Modern languages that rely on libraries or provide their own implementation of certain functions don't easily allow that kind of low-level control. Pretty much any language that provides garbage collection is a big no-no for real time, as you cannot sufficiently control when garbage collection occurs. Also, any language that does not use pointers can not be as efficient as a language that does. (or at least I wouldn't know how that's possible)
5. Any application that does an amount of local processing sufficient to make the users wait for more than a couple of seconds, can benefit from a language that allows for better performance. As pointed out in 4., languages not using pointers, or implementing garbage collection, may be inferior choices.
There are lots of examples where the benfits of C/C++ don't shine, e. g. a browser, or just about any web application benefits much more from libraries and even basic functionality that other languages like Java, PHP, Ruby etc. provide, and don't have any real restrictions regarding resources or performance. This is not my area of expertise though.
Personally I believe that beyond the above reasons, companies may stick with C/C++ simply because it works, and they are reluctant to switch to something new when all (or most) their programmers are used to C/C++.
|
|
|
|
|
One programming language is not better than other. Use the right tool for the right job.
PS: Note that ANYTHING is better than JAVA though. This is an exception.
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
One programming language, but C, is not better than other.
FFY
Veni, vidi, vici.
|
|
|
|
|
1. Compatibility. If you want code to run on different architectures (X86, ARM, PIC, etc) and different operating systems, C (and sometimes C++) is the only way to go.
2. Performance. Predictable, excelent performance. Unrestricted use of memory and system resources.
3. Libraries (GLib, STL, etc).
4. Huge codebases.
5. Games (most games are done in C++).
6. Flexibility. C++ for example, doesn't impose "objects" and "interfaces". You can write code "the way you want" mixing objects, procedures and templates. You can write abstract code or go directly to asm in the same project.
C tops in portability. C++ tops in flexibility.
In these areas they have little competition (if any).
Both usually top in performance (there are exceptions, but they are that, exceptions).
That said, they are complex and require discipline. They are error prone. They are difficult to master (years). They don't have "unique" GUI or libraries. They are not controlled or improved by any corporation.
They move at slow pace, considering that improvements should not break existing software.
it´s the journey, not the destination that matters
|
|
|
|
|
I'm looking for an SDK that will make it easier for me to record audio and store it in one of the ADPCM variants like G.711, G.726, G.722, and others.
I am writing a recording utility for our application. The reason for using these encoding codecs are because they are more naively used for VOIP and can be used directly rather than standard PCM recordings to have to be converted first.
Key needs are being able to either directly record into this format or easily convert the recordings using API calls. Also a method to have the software automatically trim leading and trailing "silence". I quote silence because there is actually background noise but at a very low volume what would need to be trimmed. Having a way for the software to automatically trim this static of the beginning and end of a recording is a key feature for me. I don't want to have the user to use another tool to self edit the audio file because most of our users will not be efficient and will save the files in the wrong formats.
|
|
|
|
|
How to know whether the server has no data while reading the response of a request which is keep alive because the socket read function waits for the server to send data if we have made a request with keep alive option.
I am writing a socket program to fetch a webpage.
My request header has no connection close header so by default the connection is keep alive.
I open a connection, send the request header using socket_write and getting using a while loop to receive data
if it is a Connection Close request the everything works well.
if it is keep alive and after i have read the content the socket_read function is still waiting for data which causes the code to hand in there.
Here how do we know whether the server has completed sending the resource though it is keep alive...
i have a work around like checking the content-length response header to know how much data is received and accordingly i can stop reading
or
if response header has transfer-encoding as chunked then i can write more code to find the end of the response
yet without the above two workarounds how to check whether the socket_recv is still waiting for data?
Besides, i was thinking that since we are setting the read buffer length (like 1024 in this code) and the socket_recv is returning the no of bytes read and if the bytes read is less than 1024 then i can assume that the next read will not return anything and by this time i can quit the while loop.... BUT http server sends different length response so my logic will not work.
Here is my request header and the while loop in which i receive date from the server
//i have commented the connection close header so that by default it will be keep alive
here the code is in different language but the basic concept is the same for all languages so i am asking it here.
$o = 'GET /search?hl=en&q='.$query.'&start='.$start.' HTTP/1.1'."\r\n";
$o.= 'Host: www.google.co.in'."\r\n";
$o.= 'User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0'."\r\n";
$o.= "\r\n";
do
{
$bytes = socket_recv($f, $tbuf, 1024, 0x40);
if($bytes === false)
die("\r\nUnable to read headers - ".socket_strerror(socket_last_error()));
echo "\r\n".$bytes;
if(!$bytes)break;
$buf.= $tbuf;
}while(1);
In the above code after i have received the complete html of a webpage the control is in the line where i am reading the response. Which i assume the code is still waiting for data from the server.
Suggestions, comments and advice's are welcome.
|
|
|
|
|
You have been here long enough that you should know to ask your questions exactly ONCE. 
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
I will delete the other one
|
|
|
|
|
Since you are using blocking sockets (and not async sockets) you have to find out the size of the response and read exactly that many bytes from the socket. If its chunked encoding then you have to read till the end.
Blocking mode sockets with raw api calls work like this: When you send() data the send() function returns only if an error occurs or the whole buffer you provided could be written out the send buffer of the socket. recv() works a little bit different, it returns immediately even if only a single byte of data is available in the receive buffer of the socket and you can't assume that a consequent recv() call would block if your buffer wasn't filled up completely during the previous call. This behaviour of recv() can be changed to wait for a whole buffer by specifying the MSG_WAITALL flag on windows but that is not recommended and that flag isn't supported everwhere.
|
|
|
|
|
oh... let me try the async (non blocking)...
Besides, yes as you have suggested it is that i have to read untill the end chunk by chunk...
I will try both. Thank you for the reply.
http://vikku.info/ Today's Beautiful Moments are
Tomorrow's Beautiful Memories
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
