|
pasztorpisti wrote: Yes, in the last years we had many times when we had to rearrange the header
includes and optimize for compile times for our CI system. We compiled the
codebase (~2millions loc) with a grid system (IncrediBuild) plus SSD drives in
all machines in the grid and the compile time was still 20 minutes. By
rearranging some header files we could decrease the build time to around 5
minutes. Thats what I'm talking about ...
And what I am talking about is that is a poor design.
Let us just suppose that there is absolutely no way that you can divide that into independent deliverables (each with a defined public interface.)
It certainly wouldn't stop a well design code base in which one could still work effectively on a piece without using the entire code base. If it was designed correctly.
pasztorpisti wrote: And could you make a list of language features
I use and have used all of the popular languages to make large systems. The features of the language have nothing to do with the success of the projects.
|
|
|
|
|
jschell wrote: And what I am talking about is that is a poor design.
Thanks for your advices, it had always been cut into about 10 DLLs. Still the CI system sometimes performed full clean build intentionally and that iteration time was important for us before relase days. Relatively rarely when some central system headers needed modification a grid came very-very handy. Of course I was talking about the full clean build time. I have to admit that the legacy codebase we are speaking about was full of lava code/flow and refactorization and/or partial rewrites in such a huge codebase is not always an option, its cheap neither in time nor in money. Still the owner wants to see it running and extending with new features. :P
jschell wrote: I use and have used all of the popular languages to make large systems. The features of the language have nothing to do with the success of the projects.
A well chosen language and its development environment can cut the development/debugging (and maintenance!!!) time and the money spent considerably, so it has to do with the success of a project. Of course this isn't true if your company has infinite amount of time and money (I've already worked for one that seemingly had these traits...  ).
|
|
|
|
|
pasztorpisti wrote: A well chosen language and its development environment can cut the development/debugging (and maintenance!!!) time and the money spent considerably
Wrong. If you think otherwise then provide a reference.
The only proven thing that can reduce maintenance is a well regulated process. And that has nothing to do with language choice. A good process can provide other proven benefits as well. Scan articles from IEEE and ACM to find the studies that demonstrate it.
|
|
|
|
|
Then why have people invented languages and dev environments at all when assembly and edlin was already there? The first time I rrealized the importance of dev evnironment support is when I started to use Delphi. That indeed cut development and maintenance time to its fraction in some cases! It provides 10 to 100 times faster iterations for certain type of projects, and the same is true for some other languages/ides when its about specific problems. This has to do with the development process and strategy and also with the budget.
|
|
|
|
|
pasztorpisti wrote: Then why have people invented languages and dev environments at all
Why did someone invent the following language?
http://en.wikipedia.org/wiki/Whitespace_%28programming_language%29[^]
pasztorpisti wrote: It provides 10 to 100 times faster iterations for certain type of projects,
How did you measure that? What problem domains did that study apply to? How many developers were involved in it? How and what contributing factors controlled for?
|
|
|
|
|
jschell wrote: Why did someone invent the following language?
http://en.wikipedia.org/wiki/Whitespace_%28programming_language%29[^]
Read the wiki page to find that out, but its quite unambiuous why. Still you havent answered the question why don't you still use assembly when the language doesn't count in your opinion.
pasztorpisti wrote: 10 to 100 times faster
Well, here I got carried away...  I worked for a company where we created customized database solutions (2 tier) usually in 2-3 month periods with multiple iterations, around 10 coders involved. We worked with C++ and some helper libraries including Qt for the frontend. Sometimes the required fronted and UI was quite complex and pain in the ass to wire together and 2 week was always a bottleneck on the frontend side. Usually 3-5 people was working on the frontend (sometimes including me) with 1-2 weeks per iteration. Then we bought Delphi and used that for frontend development - the 1-2 week iteration time was reduced to 1-2 days, development became comfortable, also the quality/usability of the whole stuff became better with much-much less critical bugs. This was a radical but definitely good step and I think this achievement is a serious difference in many aspects - for me it proved well that language and ide support counts. What delphi gave for us (before 2000) is available now for everyone in the form of .net and C#, a lot of C# coders have C++ experience and they can tell the difference between developing such frontends in C++ and C# even today - more than 10 years later.
My opinion about a lot of different measurement techniques: most of them has not much of use other than showing colorful diagrams for higher leaders (if they need it at all), the only ones I find useful: estimated vs actual duration of an iteration or whole development till release (for the whole team), the number of critical bugs during development, and maybe the number of shipped bugs (that you might not know about but its important if we speak of maintenance).
modified 22-Sep-12 23:45pm.
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
