What makes C and C++ a "good" language?
-
Can someone tell me why C++ and C programming languages are used than any other programming languages, what can these languages do that others can't. I do know that C can create drivers or system files, which is very important when you become serious about your projects. But why is the industry still use it? And will C or C++ ever die, even though it's a non-stop updating language everyday, and what other languages update just like C/C++. EDIT: While also asking this question, will C++/CLI take over or kill out Standard/Win32 C++? Cause I'm on a website called Codejock Software, looking for a ribbon control to work for Standard/Win32 C++ only, and I can't find it. Most of the controls are only made for C++/CLI.
Simple Thanks and Regards, Brandon T. H. Programming in C and C++ now, now developing applications, services and drivers (and maybe some kernel modules...psst kernel-mode drivers...psst). Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
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++.
-
Win95 is "just a nice DOS program". :-) Even if they have replaced and extended parts in the OS they always stayed backward compatible on api and source level and thats alone is a good reason for not switching the language even if all they do is wrapping new kernel. You can take the sources of a pretty old windows program and with minimal or no modifications you have good chances to compile it even for a 64 bit system. I think this backward compatibility drains a lot of their energy and it implies some practical restrictions (like language).
pasztorpisti wrote:
Win95 is "just a nice DOS program"
The point however is that windows has been re-written.
pasztorpisti wrote:
You can take the sources of a pretty old windows program and with minimal or no modifications you have good chances to compile it even for a 64 bit system
I suspect I can take 'cat' from a pre windows unix variant and with "minimal" modification get it to work on a windows 7. That however doesn't mean that windows wasn't re-written.
-
jschell wrote:
And as I already said history is SPECIFICALLY full of cases where exactly that has happened.
So obviously it can happen.There is something in your statement. I guess languages are gone when they roots die. C/C++ have currently strong roots (at least Windows/*nix systems).
jschell wrote:
Wrong. It isn't used because developers have not found an advantage to using it.
I still think this is partly because of library support and development environment support. Its also a high risk to start a commercial project with something new that can blow. Lets imagine a fatal D compiler crash (without the support of the authors) in the middle of your project! Startups are very slow for these simple reasons.
jschell wrote:
You do understand that there are many C++ developers and yet C (not C++) continues to be used significantly? Do you understand how C++ was adopted over time to take over much of the work previously done by C++ and yet C by itself continues to be used? The first part of that puts lie to your contention that legacy code preclude new adoptions and the second to your assertion that something that is better in some way must always universally replace the older because there no longer is any value.
I guess you wanted to write C# when you were talking about the language that took over some of the work of C++. C# can became widespread (relatively quickly) because its supported by a huge rich company. Its library support is good, its IDE is superb. These give the base of one of your reasonings in a previous post: This language gave something. It made development easier and less risky because of the MS support. Noone makes you so nice IDE for D like the one you have for C#, same is true about support. Its not only the "coolness" and efficiency of the language that makes it widespread, money and/or time is also needed. As I mentioned previously I like the simplicity of C, by modifying it a bit (without keeping the ugly backward compatibility) I think it could be a very nice language for low level coding where C++ and its friends were too high.
pasztorpisti wrote:
C/C++ have currently strong roots (at least Windows/*nix systems).
Based on that then C/C++ will never cease to exist because there is no expectation that either or both of those OSes will cease to exist.
pasztorpisti wrote:
I still think this is partly because of library support and development environment support.
Nope. If that was the case then Java/C# would have taken over.
pasztorpisti wrote:
Lets imagine a fatal D compiler crash
I can't speak specifically about D but these days any marginally significant new language will not "crash" when it is released into the public in such a way that it would endanger a product. If it crashes at all then it is probably due to a language construct which can be worked around.
pasztorpisti wrote:
I guess you wanted to write C# when you were talking about the language that took over some of the work of C++.
No. I was specifically using the example of when C++ became widely known and C (not C++) was the predominant language. C++ rapidly gained market share. Yet C did then and still does retain a significant market share. This demonstrates that there is a shift when the market sees a better language come along DESPITE the extensive code base. It also demonstrates that C still finds and audience because it is still used. Thus it STILL provides a benefit that developers can appreciate.
-
I answered the question, you just forget to quote the end of my post. My posts are not advertising that we have true alternatives in every areas where C/C++ is used. I just mentioned that even in the areas where C/C++ has monopoly better alternatives could be forged with todays knowledge.
-
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... :-D).
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.
-
pasztorpisti wrote:
Win95 is "just a nice DOS program"
The point however is that windows has been re-written.
pasztorpisti wrote:
You can take the sources of a pretty old windows program and with minimal or no modifications you have good chances to compile it even for a 64 bit system
I suspect I can take 'cat' from a pre windows unix variant and with "minimal" modification get it to work on a windows 7. That however doesn't mean that windows wasn't re-written.
jschell wrote:
The point however is that windows has been re-written.
Well, from our point of view its not important how much they extended or replaced their codebase. Its a fact that they kept backward compatibility with their old api and that doesn't leave much space for practically changing the underlying language. Lot of parts have been tweaked and replaced in windows in the past decade, but I was shocked how much hacks have been kept in the code and win9x compatiblity layers. I'm pretty sure the level of backward compatibility they have often ties their hands pretty strong. On hack I really mean (sometimes really dirty) hack for example to avoid crashes of specific popular old programs that has bugs that don't crash the program on older systems but without special handling they would simply die on NT. And the hacks are explicitly commented with bug IDs and reasonings. This is another hidden face of windows' backward compatibility. I think what makes windows successful also holds it back in development, but I really respect the MS coder guys for what they achieved. Keeping backward compatibility on such a large scale is tremendous work. They don't rewrite everything, what I was curious in the sources is module loading, that consisted of pretty old sources with lot of win3.1 and win9x sources. They use a lot of typedefs that makes porting relatively easy even to 64 bit and thats quite OK till they go on with backward compatibility.
jschell wrote:
I suspect I can take 'cat' from a pre windows unix variant and with "minimal" modification get it to work on a windows 7.
That however doesn't mean that windows wasn't re-written.I wouldnt compare the complexity of a cat program with even the simplest windows gui program. The same is true for the winapi versus posix. The posix api doesn't contain api calls that seriously enforce windows specific compatibility restrictions internally. On the other hand if a program for example subclasses a windows common controls dialog and it expects the border size to be X pixels and hacks around with gui hooking and expects you to send unrelated window messages to avoid a crash then you have a very complex (and sometimes not too well designed) api system to simulate natively and thats near not as easy as implementing a pure simple posix api. Well, we are talking about why havent they changed the language, and the answer is clear: Source level bac
-
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.
-
No I don't see that answered. Again if you were writing a OS today which language would you pick to write it in?
If I had to keep source and/or binary level compatibility then probably C. If I had total freedom then assembly and a new C-like language that has the unambiguous problems of C fixed.
-
pasztorpisti wrote:
C/C++ have currently strong roots (at least Windows/*nix systems).
Based on that then C/C++ will never cease to exist because there is no expectation that either or both of those OSes will cease to exist.
pasztorpisti wrote:
I still think this is partly because of library support and development environment support.
Nope. If that was the case then Java/C# would have taken over.
pasztorpisti wrote:
Lets imagine a fatal D compiler crash
I can't speak specifically about D but these days any marginally significant new language will not "crash" when it is released into the public in such a way that it would endanger a product. If it crashes at all then it is probably due to a language construct which can be worked around.
pasztorpisti wrote:
I guess you wanted to write C# when you were talking about the language that took over some of the work of C++.
No. I was specifically using the example of when C++ became widely known and C (not C++) was the predominant language. C++ rapidly gained market share. Yet C did then and still does retain a significant market share. This demonstrates that there is a shift when the market sees a better language come along DESPITE the extensive code base. It also demonstrates that C still finds and audience because it is still used. Thus it STILL provides a benefit that developers can appreciate.
jschell wrote:
Based on that then C/C++ will never cease to exist because there is no expectation that either or both of those OSes will cease to exist.
Good point. Thats why I think that llvm is a great invention and a beam of hope. Its a nice thing that can glue languages together and its already good enough to compete with gcc that is a monster codebase compared to llvm.
jschell wrote:
Nope. If that was the case then Java/C# would have taken over.
Despite the nice design and universality of the packages of these languages they far not cover as many areas as C/C++ libraries and they often don't cover native OS specific staff whose api is also in C. Fortunately they are often well suited for all kinds of enterprise problems where it would be a guilt to choose other languages.
jschell wrote:
No. I was specifically using the example of when C++ became widely known and C (not C++) was the predominant language. C++ rapidly gained market share. Yet C did then and still does retain a significant market share.
This demonstrates that there is a shift when the market sees a better language come along DESPITE the extensive code base. It also demonstrates that C still finds and audience because it is still used. Thus it STILL provides a benefit that developers can appreciate.A lot of factors are involved when you have to decide which language is the nearest to the theoritical domain specific dream language (+libs) to solve the actual problem. If you have to decide for example between C and C++ you are already in trouble because most of the problems are just in between. The libraries are shared between these languages but C++ is a messy language overwhelmed with freature redundancy while C is much simpler but misses some really nice features that make development much efficient and manageable. For this simple reason I always choose C++ because I already know which features to use and which ones to avoid but many C coders don't want to bother with learning the feature mass and the freestyle of C++. Without backward compatiblity it would be so easy to put together an extended-repaired C and cleaned C++, and even a good devenv, but what about library support? Thats the only thing that keeps me back from wasting my time on starting a battle I hardly win. Maybe in my older years as a hobby project when I will have less todos because its definitely
-
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?
-
If I had to keep source and/or binary level compatibility then probably C. If I had total freedom then assembly and a new C-like language that has the unambiguous problems of C fixed.
-
jschell wrote:
Based on that then C/C++ will never cease to exist because there is no expectation that either or both of those OSes will cease to exist.
Good point. Thats why I think that llvm is a great invention and a beam of hope. Its a nice thing that can glue languages together and its already good enough to compete with gcc that is a monster codebase compared to llvm.
jschell wrote:
Nope. If that was the case then Java/C# would have taken over.
Despite the nice design and universality of the packages of these languages they far not cover as many areas as C/C++ libraries and they often don't cover native OS specific staff whose api is also in C. Fortunately they are often well suited for all kinds of enterprise problems where it would be a guilt to choose other languages.
jschell wrote:
No. I was specifically using the example of when C++ became widely known and C (not C++) was the predominant language. C++ rapidly gained market share. Yet C did then and still does retain a significant market share.
This demonstrates that there is a shift when the market sees a better language come along DESPITE the extensive code base. It also demonstrates that C still finds and audience because it is still used. Thus it STILL provides a benefit that developers can appreciate.A lot of factors are involved when you have to decide which language is the nearest to the theoritical domain specific dream language (+libs) to solve the actual problem. If you have to decide for example between C and C++ you are already in trouble because most of the problems are just in between. The libraries are shared between these languages but C++ is a messy language overwhelmed with freature redundancy while C is much simpler but misses some really nice features that make development much efficient and manageable. For this simple reason I always choose C++ because I already know which features to use and which ones to avoid but many C coders don't want to bother with learning the feature mass and the freestyle of C++. Without backward compatiblity it would be so easy to put together an extended-repaired C and cleaned C++, and even a good devenv, but what about library support? Thats the only thing that keeps me back from wasting my time on starting a battle I hardly win. Maybe in my older years as a hobby project when I will have less todos because its definitely
pasztorpisti wrote:
A lot of factors are involved when you have to decide which language...
I have been programming for 40 years. I have spent many years programming in all of the popular languages. I programmed in C# version 1. I programmed in Java 1.0.4 (before 1.4). I programmed in C++ before there was a ANSI standard. I programmed in C before there was an ANSI standard. I have also programmed in Fortran, Pascal, Perl, assembly (for various targets), SQL (a number of variants), and even created several small languages myself. I have been working in large systems for more than a decade. I specialize in back end systems and interfacing between sub-systems (many, many legacy systems.) And I have also spent a great deal of time actually seeking real knowledge about making technical decisions. So yes I am in fact aware of what factors are involved in making technical decisions. The conclusion I have come to is that 1. The VAST majority of time technical decisions are made subjectively. There is no objective basis for the decision. The users do it just because they want to. 2. The VAST majority of time it doesn't matter. And for many cases where it it might be considered to matter the problem domain drives the decision (you can't program in C# on a system which does not have libraries, .Net, etc no matter why you think it is a good idea.)
pasztorpisti wrote:
Without backward compatiblity it would be so easy to put together an extended-repaired C and cleaned C++, and even a good devenv
I have written small languages including a small C (used in a commercial application.) I followed the ANSI process for C and C++ extensively when that first occurred. I followed the path of Java as it attempted to reach a consensus and corporate acceptance of a accepted standard along with following the JCP from inception and following a number of topics in there throughout their lifetime. I have even written an IDE. So I know for a fact that it is not "easy".
-
jschell wrote:
The point however is that windows has been re-written.
Well, from our point of view its not important how much they extended or replaced their codebase. Its a fact that they kept backward compatibility with their old api and that doesn't leave much space for practically changing the underlying language. Lot of parts have been tweaked and replaced in windows in the past decade, but I was shocked how much hacks have been kept in the code and win9x compatiblity layers. I'm pretty sure the level of backward compatibility they have often ties their hands pretty strong. On hack I really mean (sometimes really dirty) hack for example to avoid crashes of specific popular old programs that has bugs that don't crash the program on older systems but without special handling they would simply die on NT. And the hacks are explicitly commented with bug IDs and reasonings. This is another hidden face of windows' backward compatibility. I think what makes windows successful also holds it back in development, but I really respect the MS coder guys for what they achieved. Keeping backward compatibility on such a large scale is tremendous work. They don't rewrite everything, what I was curious in the sources is module loading, that consisted of pretty old sources with lot of win3.1 and win9x sources. They use a lot of typedefs that makes porting relatively easy even to 64 bit and thats quite OK till they go on with backward compatibility.
jschell wrote:
I suspect I can take 'cat' from a pre windows unix variant and with "minimal" modification get it to work on a windows 7.
That however doesn't mean that windows wasn't re-written.I wouldnt compare the complexity of a cat program with even the simplest windows gui program. The same is true for the winapi versus posix. The posix api doesn't contain api calls that seriously enforce windows specific compatibility restrictions internally. On the other hand if a program for example subclasses a windows common controls dialog and it expects the border size to be X pixels and hacks around with gui hooking and expects you to send unrelated window messages to avoid a crash then you have a very complex (and sometimes not too well designed) api system to simulate natively and thats near not as easy as implementing a pure simple posix api. Well, we are talking about why havent they changed the language, and the answer is clear: Source level bac
-
pasztorpisti wrote:
A lot of factors are involved when you have to decide which language...
I have been programming for 40 years. I have spent many years programming in all of the popular languages. I programmed in C# version 1. I programmed in Java 1.0.4 (before 1.4). I programmed in C++ before there was a ANSI standard. I programmed in C before there was an ANSI standard. I have also programmed in Fortran, Pascal, Perl, assembly (for various targets), SQL (a number of variants), and even created several small languages myself. I have been working in large systems for more than a decade. I specialize in back end systems and interfacing between sub-systems (many, many legacy systems.) And I have also spent a great deal of time actually seeking real knowledge about making technical decisions. So yes I am in fact aware of what factors are involved in making technical decisions. The conclusion I have come to is that 1. The VAST majority of time technical decisions are made subjectively. There is no objective basis for the decision. The users do it just because they want to. 2. The VAST majority of time it doesn't matter. And for many cases where it it might be considered to matter the problem domain drives the decision (you can't program in C# on a system which does not have libraries, .Net, etc no matter why you think it is a good idea.)
pasztorpisti wrote:
Without backward compatiblity it would be so easy to put together an extended-repaired C and cleaned C++, and even a good devenv
I have written small languages including a small C (used in a commercial application.) I followed the ANSI process for C and C++ extensively when that first occurred. I followed the path of Java as it attempted to reach a consensus and corporate acceptance of a accepted standard along with following the JCP from inception and following a number of topics in there throughout their lifetime. I have even written an IDE. So I know for a fact that it is not "easy".
jschell wrote:
I have been programming for 40 years. I have spent many years programming in all of the popular languages. I programmed in C# version 1. I programmed in Java 1.0.4 (before 1.4). I programmed in C++ before there was a ANSI standard. I programmed in C before there was an ANSI standard. I have also programmed in Fortran, Pascal, Perl, assembly (for various targets), SQL (a number of variants), and even created several small languages myself.
I have been working in large systems for more than a decade. I specialize in back end systems and interfacing between sub-systems (many, many legacy systems.)
And I have also spent a great deal of time actually seeking real knowledge about making technical decisions.
So yes I am in fact aware of what factors are involved in making technical decisions.Don't expect me to respect your technical knowledge based on the number of years you spent in the industry. Almost everybody have their areas of expertise here and noone is superman. There are some forum members here I really respect for their clear explanations and opinions despite the fact that I have no clue how old are they and how much have they worked on this and that. This is a discusson about the good and bad traits of C/C++ so please stick to that and don't drive this thread offtopic or into a personal tug of war because I wont participate in that. Please use your experience to list pros and contras about C/C++ thats what the OP is interested in.
jschell wrote:
1. The VAST majority of time technical decisions are made subjectively. There is no objective basis for the decision. The users do it just because they want to.
I wouldn't call a decesion so subjective when it is based on past experience. For example a technical meeting is quite enough to make a sum of everyones knowledge in a given area and to make a list of possible solutions and to list pros and contras for each. I think after this the subjective part of the decesion can considerably decrease. When you have to make decisions in unknown areas then its more subjective but spending 1-2 years in a given area make things more objective because you will know 1-2 definitely good solutions to more and more problems. This is however quite offtopic, its not about C/C++.
jschell wrote:
2. The VAST majority of time it doesn't matter. And for many cases w
-
So you would create a new language to create your new OS. Have you created a language like C before? And written the support libraries for that new language?
Yes I created a compiled and a dynamic languages as hobby projects but that time without much focus on design and safety. Havent created a full fledged runtime support though. Anyway, if you are about to create a new OS then its not a big deal to put together a C like low level language with the base libraries as a first step. The complexity of the compiler+lib and the OS are not comparable especially if we make use of a tool like gcc or llvm.
-
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).
-
Windows isn't written in Basic. So based on your reasoning why does Microsoft keep producing that?
Ah, sorry, I misunderstood your post so I correct my answer. I don't know the answer to that and I'm not really interested to research one because I'm not a big basic fan. I could just guess and I don't like doing that. You can however open a new topic for that and then everyone can tell their opinions or whatever they know about it. But how is this related to bad/good things in C/C++?
-
jschell wrote:
I have been programming for 40 years. I have spent many years programming in all of the popular languages. I programmed in C# version 1. I programmed in Java 1.0.4 (before 1.4). I programmed in C++ before there was a ANSI standard. I programmed in C before there was an ANSI standard. I have also programmed in Fortran, Pascal, Perl, assembly (for various targets), SQL (a number of variants), and even created several small languages myself.
I have been working in large systems for more than a decade. I specialize in back end systems and interfacing between sub-systems (many, many legacy systems.)
And I have also spent a great deal of time actually seeking real knowledge about making technical decisions.
So yes I am in fact aware of what factors are involved in making technical decisions.Don't expect me to respect your technical knowledge based on the number of years you spent in the industry. Almost everybody have their areas of expertise here and noone is superman. There are some forum members here I really respect for their clear explanations and opinions despite the fact that I have no clue how old are they and how much have they worked on this and that. This is a discusson about the good and bad traits of C/C++ so please stick to that and don't drive this thread offtopic or into a personal tug of war because I wont participate in that. Please use your experience to list pros and contras about C/C++ thats what the OP is interested in.
jschell wrote:
1. The VAST majority of time technical decisions are made subjectively. There is no objective basis for the decision. The users do it just because they want to.
I wouldn't call a decesion so subjective when it is based on past experience. For example a technical meeting is quite enough to make a sum of everyones knowledge in a given area and to make a list of possible solutions and to list pros and contras for each. I think after this the subjective part of the decesion can considerably decrease. When you have to make decisions in unknown areas then its more subjective but spending 1-2 years in a given area make things more objective because you will know 1-2 definitely good solutions to more and more problems. This is however quite offtopic, its not about C/C++.
jschell wrote:
2. The VAST majority of time it doesn't matter. And for many cases w
pasztorpisti wrote:
Don't expect me to respect your technical knowledge based on the number of years you spent in the industry.
Your knowledge is based specifically on your experience with C++. My knowledge is based on my experience with multiple languages, including C++, in addition to actively seeking out other sources specifically about technical advantages both in technology and process.
pasztorpisti wrote:
This is especially true for C++ beginners who just think its cool when you use all fancy C++ feature
Could be. That however has nothing to do with me. I am not a beginner with C++. Nor am I beginner with other languages. And I know the mistakes that people can make with all of them. And the "nice and useless features" that are added to languages besides C++. Matter of fact I would say that C++ is in fact much more restrained in that. Certainly much more restrained than C#.
-
pasztorpisti wrote:
Don't expect me to respect your technical knowledge based on the number of years you spent in the industry.
Your knowledge is based specifically on your experience with C++. My knowledge is based on my experience with multiple languages, including C++, in addition to actively seeking out other sources specifically about technical advantages both in technology and process.
pasztorpisti wrote:
This is especially true for C++ beginners who just think its cool when you use all fancy C++ feature
Could be. That however has nothing to do with me. I am not a beginner with C++. Nor am I beginner with other languages. And I know the mistakes that people can make with all of them. And the "nice and useless features" that are added to languages besides C++. Matter of fact I would say that C++ is in fact much more restrained in that. Certainly much more restrained than C#.
jschell wrote:
Your knowledge is based specifically on your experience with C++.
My knowledge is based on my experience with multiple languages, including C++, in addition to actively seeking out other sources specifically about technical advantages both in technology and process.Not true, I've worked with every language you mentioned extensively except fortran, but this drives this whole thread far offtopic.
jschell wrote:
Could be. That however has nothing to do with me. I am not a beginner with C++. Nor am I beginner with other languages. And I know the mistakes that people can make with all of them. And the "nice and useless features" that are added to languages besides C++. Matter of fact I would say that C++ is in fact much more restrained in that. Certainly much more restrained than C#.
Then we agree that C/C++ has obvious defects that shouldn't exist with todays technology.
-
jschell wrote:
Your knowledge is based specifically on your experience with C++.
My knowledge is based on my experience with multiple languages, including C++, in addition to actively seeking out other sources specifically about technical advantages both in technology and process.Not true, I've worked with every language you mentioned extensively except fortran, but this drives this whole thread far offtopic.
jschell wrote:
Could be. That however has nothing to do with me. I am not a beginner with C++. Nor am I beginner with other languages. And I know the mistakes that people can make with all of them. And the "nice and useless features" that are added to languages besides C++. Matter of fact I would say that C++ is in fact much more restrained in that. Certainly much more restrained than C#.
Then we agree that C/C++ has obvious defects that shouldn't exist with todays technology.