|
Again you didn't understand. C language compilation is relatively fast.
C++ language compilation, on the other hand is slow, I am aware of it. Anyway you cannot achieve the same performance of a (well) written C++ application with a (well) written application using your favourite programming language (try it).
LLVM? Do you mean: "An aggressive open-source compiler for C and C++ and Stacker, a forth-like language"? 
Veni, vidi, vici.
|
|
|
|
|
llvm was started to kill off gcc, so its first frontends are C and C++. Its a nice clean compiler infrastructure that already has other frontends and you can integrate any other languages relatively easy compared to the same work with for example gcc. Its a beam of hope to get rid of the "C++ is good because its the optimal" reasoning because that is simply ridiculous and still doesn't change the fact that both C and C++ are defective. And yes, compiling C is much faster, but on the other hand a C project is also much harder to maintain and the language features don't give much support to arrange huge codebases. The biggest C codebase was around 100.000 loc and it was already hard to navigate. The lack of type safety and typeless linking, lack of namespaces (and the list goes on) give way too much space for human errors. Yes, C code compiles faster but it misses lots of nice features that wouldn't require you to sacrifice compile speed.
|
|
|
|
|
pasztorpisti wrote: "C++ is good because its the optimal" reasoning because that is simply ridiculous
Your point is ridiculous. You have nothing to bear out it.
Veni, vidi, vici.
|
|
|
|
|
CPallini wrote: Your point is ridiculous. You have nothing to bear out it.
Which point from the many listed in my posts?
|
|
|
|
|
(In my previous reply) I reported your sentence.
Veni, vidi, vici.
|
|
|
|
|
I will tell it to my mom!
|
|
|
|
|
Veni, vidi, vici.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
