Comments on: C++ creator upbeat on its future
Bjarne Stroustrup claims that the programming language has never been bigger, but not everyone agrees.
Bjarne Stroustrup claims that the programming language has never been bigger, but not everyone agrees.
December 26, 2009 10:04 AM PST
December 26, 2009 9:10 AM PST
December 26, 2009 12:00 AM PST
Add headlines from CNET News to your homepage or feedreader.
More feeds available in our RSS feed index.
Related quotes
More developers are using C++ now. It's relative position does not change that fact.
2. your making something low level that isn't a game hack...perhaps a hardware driver.
3. it's the only language you know and don't want to learn others.
4. your forced to by your employer
For everything else...any language but c++ is a smart choice.
Heck their are even direcx games coming out now that are written in c#. And guess what language is gonna be extensibly used in Longhorn...c#.
However their is something weird about c#...it's very similiar to c++ and yet better. It is what c++ should of been all along and is the product of innovation along those lines...sortof a merger of c++ and what made java easier.
And guess who is making Longhorn? Microsoft. And guess who created C#? Microsoft. So where is the surprise?
"sortof a merger of c++ and what made java easier."
Yes, Microsoft made C# so they wouldn't have to license Java. When new languages are created they try to borrow the best from what is currently available.
C++ is both a high and low level language. It's faster than Java and more portable that Microsoft's languages.
The biggest reaon why C# will not be that popular is that it is designed to not be platform independant. All major languages share this trait, regardless of whether it is a compiled, intrepreted, or hybrid langauge, they all can be platform independant with a little care and foresight. Few programming houses will ever move to C# since it ties them to MS and makes it extremely difficult to move to something else down the road. The ability to easily move from one platform to another can not be overstated. Mono is still a work in progress and who knows how well it will handle porting a large C# program over to Linux.
It is not what C++ should have been all along. Most high end 3D games are still written in a mix of C and C++, and will continue to do so for quite some time. Real time systems will never be written in C#, not Java for that matter. Ditto for embedded systems, although C++ is not the best choice for that, C normally is. Visual Basic is such a joke it is not worth mentioning. It is a programming language for non-programmers.
The problem with C++ is that it is a huge, sprawling language that has gotten out of control. If the standards committee would trim it down and add a few safety features, it would be used even more often.
The reason universities teach Java in their introductory course is because in Java there is no need to deal with pointers nor clean up dynamically allocated memory. Those are two of the biggest issues for newbie programmers(given the problems at large corporation like MS, it exists for supposedly professional programmers as well). But nearly all universities do teach C++, after the student has taken a few digital design courses as well as assembly. With those classes as a background, the concept of pointers and cleaning up memory are easier because the student has a firm grasp of what is happening in all parts of memory and in the registers in the processor.
C++ being only good for hacks, and that C# is a better
language. What an un-informed mind. C# is definitely easier to
use, but it is limited in performance and application.
Just like VB, I can create certain types of applications in
lightspeed, compared to C++. However, C++ could be just as
fast if code wizards were used in the IDEs.
The other comment the post made, was that C++ programmers
use C++ because they don't know any other language. This is
not personal, but that was the most single stupid remark in the
post. By and large, and I mean large, C++ programmers can
pick up any other language far quicker than any other
programmer that uses a different language. That is because it
inherently forces you to learn more about actual programming
practices than some language that you put together like a
numbered painting toy.
If you have time, C++ is always the right choice for serious
applications, that can be re-compiled on multiple platforms,
and/or be free from the whims of a high-levell language
provider (can we say Microsof) . I need a quick web service on
windows, a windows service, a web service client, then C#-.Net
is the right choice. I need a quick windows stand-alone desktop
application, then VB is the right choice.
The are a lot of right choices. But i think you should remember
nearly all of these high-level languages are written in either C,
C++, or Objective-C. Don't be fooled by C#. I please, don't
think that C# is THE language of the future, unless you plan to
paint yourself into a corner.
Learn, learn and learn more.
C/C++ was one of the first languages I ever learned, and I have to say that I wouldn't be able to do what I can today without it. To all those of you so lazy that you refuse to utilize the mostly cryptic and mostly faster C/C++ over Java and the like, I wish you the best of luck. I will stick with my first, and the fastest, until the day I stop coding.
depends on the purpose and preference. For instance,
a compiler and BIOS will be written in C. Apps
can be written in any of the above.
C++ does not live or die at Microsofts whim.
http://www.hotgigs.com/marketing/template.cfm?page=searches&inc=rpt_drill_skill&Location=1&item=Dev-PC+%26+Desktop
I used to read "C++ Report" and would follow the missives of Stan Lippman, Mike Meyes, Doug Schmidt et al there.
The reality was, few people I encountered knew C++ well. At least not enough to design good classes. Much less to absorb a book such as DESIGN PATTERNS from Gamma et al and increase their productivity by some multiple.
I even spent 2-1/2 years at Microsoft and I have to say, the majority of MS employees who were doing C++ coding did NOT knew C++ well. Oh sure, there were some, but they were in the minority.
Many people claimed C++ was too complex but given that Java has had feature creep over the years and now sports many of the exact same language features that C++ had from the start, any argument that Java is better because is simpler does not fly with me.
With so many libraries freely available now and with Moore?s Law eroding the argument for being at ?the metal? (low level APIs) I would be hard pressed to want to write a straight Windows C++ application like the old days. And with the proliferation of skinned applications, the idea that something doesn't conform to a particular "look" just doesn't hold water in my book. I would not be apprehensive about using something like this to create Windows application:
http://gtk.php.net/
The argument that "C++ is fast" just doesn't hold water. Fast at what? For doing? Considering what some well crafted regular expressions and a few statements can do for me in PERL if I were processing log files, I would be hard pressed to want to solve such a problem with C++. ?Oh, but that?s not C++?s forte? some might burst out. Problem is, C++ does not have many fortes anymore (if any). The argument for speed just doesn?t hold water. I mean, who the hell writes assembly code anymore? MS used to carry an assembler product but they dropped that years ago. Anyone remember the days when PC Magazine used to publish the assembly language source to their utilities in the days of MS-DOS? You would be hard pressed to see PC Magazine wasting pages in that fashion nowadays.
Given that lots of application development nowadays is very web centric, the proliferation of application servers with their robust support frameworks (classes) does not leave much room for C++ in that space.
And lastly the problem I have observed with *all* programming languages - few people learn the programming language they claim to know well. After being in technology for 10+ years, this has played itself out many a time. When I first started using the "new" cast operators, i.e. const_cast, reinterpret_cast, etc. (years old at this point) as well as the Standard Template Library I had people at MS scratch their heads and want to rewrite my code instead of understanding what was before their eyes. Never mind that the help system in Visual Studio clearly documented what all this was;
And Lord knows how many people I've interviewed who said they knew C and could not nor would not even attempt to write strcpy. When I posed the question I was not interested in conformance to the strcpy ANSI prototype or parameter checking, I simply wanted to see if someone understood pointers. Anyway for brevity?s sake:
void strcpy( src, dest )
{
while( *dest++ = *src++ );
}
Every person I've asked to do this has not done it.
Yeah, hard to believe, well it used to be hard to believe... then I realized that mediocrity and average are synonymous in my field.
Now if you add all the expressiveness of C++ and some of the deep semantics, forget it. Lord knows how many times I had people say they were experts at C++ and could not tell me why on earth you would want to write a copy constructor.
People have complained about C++?s complexity but I liken this to being articulate and well read in the layman?s wold. A country bumpkin is not likely to understand Shakespeare whereas a well rounded and well read college educated person is at least capable of some semblance of what?s going on... where do you see yourself? The bumpkin or the (semi)articulate person? Sadly, it seems complacency is the norm in the IT field and many developers usually fall under the "bumpkin" category.
-M
PS:
mov bp, sp
mov cx, [bp+3]
mov di, [bp+1]
mov si, [bp+2]
rep movsb
ret
That was strncpy in Intel 80x86 assembly.
The 'feature creep' in Java has not been bad until 1.5.0. It is still far and away from streamlined then C++.
I understand what you are saying with people having trouble writing library functions, but if anyone asked/told me to use(as opposed to writing my own) strcpy(), they would lose any respect I had for them. But I digress, I am still a CS student but I spend a lot of my free time writing library functions(I get a lot of assignments that do this as well) and getting them to run as fast and securely as the standard library functions. I am currently working on a math library that covers the basic data types as well as wrapper classes, as well as classes that allow for infinite size integers and floats. Not just basic math functions like power, but trig, logs, and some basic calculus functions. It is hard going but covers so much it is more then worth the hassles of doing it.
I am not sure it is correct to say its heyday is over, after all, many projects are started everyday that use at least some C++, not too mention all the legacy code out there.
Yes, it is well known that there are many mediocre programmers, at Microsoft and everywhere else. That is the #1 issue, IMO. People just want to learn the basics of a language and the basic library functions, and think they are adequate programmers. The why and how are most important, but people just don't want to learn it. The one statement that makes me cringe, and I hear it, far too often, and from people who should know better is: "It compiled, why isn't it running correctly".
OK. But, that brings me my problem. When folks (nowadays) talk about C/C++, all you hear is about its "speed, ubiquity, compatability, ", yada, yada. Oh, and C is not in the group of tools for lightning-quit results. . .
Hey, I see your 8086 code for a strncp(), so... Talk about virtues! Why don't nobody crow about the fact that C allows PROGRAMMERS to actually visualize the instructions that will be generated by the compiler? . . .
Hey, and you and I know THAT aspect went down the drain with C++! (Check out helloworld.c in C++. sigh.) . .
I can't stop! Truth is, I failed to see people using C++ to any advantage beyond what I was doing in C. So I didn't. . . .
I could use C to generate a perfect replica of the CP/M "Great Hook" dispatch structure at 0x0005, also C let me use an actual CPU register for my *pointer, to paste up a screen very quickly.
The point is... C++ lost some the beauty of C. Also the book wasn't written nearly as well.
kd4yum@com...
Each language has its own strength, even more so when combined with an industrial strength codebase, such as Mr. Goodnight's SAS environment. Yes, SAS is also a language, as well as an environment/system.
Even Assembly on an IBM mainframe is expecially powerfull, given its strings capability and memory search & replace commands.
PERL is great with CPAN. JAVA with SWING. C# with DotNet. etc ....
C++ lost out quickly because STL was not part of the language specification or support structure until far later. [ and Borland supported TEMPLATES way before Microsoft did ].
I guess I'm trying to say that until you program in all the various languages, it's hard to know for sure. I want to qualify this by saying that I have programmed with almost all of them, including IEF CASE, 4gl, scripting, lisp, prolog, scheme, and many others. Even Microsoft's visual C/C++ and (yes) SAS.
Languages are like fashion/style in various cultures. To each his/her own as suits the nature of the moment.
C++, like any other languages, is only important if it gets the job done: within budgetary constraints, timeliness, and project requirements. But it doesn't stand alone; however, because it requires database backends, network infrastructure, complex algorithms and various infrastructure components to be able to get the job done.
That can be said of any language, just pick your favorite one.
Without any of the support environment, each language is simply a textual representation of a finite state machine, Turing nomenclature. So in that sense, the only difference is the syntactical representation of the basic action of a finite state machine: store, if, apply, retrieve, go.
In terms of maturity, I would place my money on the language that has the best support in terms of how solid the infrastructure is relative to cost of implementation.
IEF was a good tool to use, but at $275,000.00; that was too high of a burden to place on today's IT budget [ yes, I had purchased that ].
VB is great, until you realize that all the ActiveX components had a price tag attached.
For now, Java is uncertain, since SUN owns it.
C++ is free, if you consider GNU. But, note that the GCC compiler actually compiles not just C/C++, but also Fortran, AND Java. [ as well as many other languages ] Surprise!!!!!!
Until you design microchips, where the actual manipulation of data occurs, you won't appreciate how lucky you are to have that many choices. Yes, I have also done VLSI circuits.
At the bit level, of binary zero's and one's, it doesn't really matter what the language was that generated the bitcodes and byte-patterns. What matters are the piping and buffers that move those bits to generate video images, sound, movements, reactions of a fighter plane, hospital records, and tangibles of our world.
Truthfully, I still keep a slide-rule (with instructions) handy, in the event of a total nuclear meltdown.
Everyone has a valid point in their comments. I simply would like to ask that each take the time to think of what it is that gives them so much leverage with their language of choice.
Now, I think that Microsoft did something right by requiring all the Visual Studio languages to compile into IL. The key is the presence of the DotNet environment, independent of the language.
In fact, I just order a copy of the Visual Studio 2005 Beta2 to give it a spin.
Having worked with preDos, Dos, win2.0, win3.1, Solaris, MacOS, Sco, linux, SAS, and others, I think that Microsoft is heading in the right direction, even if it means a monopoly in the development space. Mono from Novell would not allow that to happen, because Mono can generate IL from just about any other NON-microsoft languages, such as PHP#, Perl#, TK#, and many, many more, all running on NON-microsoft platforms.
If everyone would chip in and make the DotNet (heaven forbid I just said that!) environment robust enough to entice Sun/HP/IBM/etc... to make their middleware, OS, and networks native to DotNet, then everyone will benefit. If you don't want to support Microsoft, you still have the option of using MONO.
Look at how cool it is to use tcp/ip today.
Just remember that a few years ago, you would have to figure out if you were writing code for banyan, ipx, ip, netbeui, appletalk, DEC, token ring, and a partridge in a pear tree!!!!
Common infrastructure benefits EVERYONE.
BTW, mono works!!!!!!!
Hey, don't flame me. Mono is an environment, not a language.
C#, VB.NET, and really even Java are all languages that run as managed code. As long as the environments themselves don't have problems, you'll never have a memory leak. Not having to worry about pointers and memory make it easier to write software faster. A Web app benefits from this, but a 3D game needs the control of C++.
whatever gets it done fastest and most reliably is usually the
best way.
I primarily code in C, but I also use a lot of Perl, various shell
scripting languages, awk, SQR, and PL/SQL (Oracle stuff). It
really depends on what I'm doing what I use.
I do have to say I haven't been very impressed with Java. For
whatever reason, many java implementations are system hogs.
Saving CPU cycles is not as important as it once was, but even so
I've seen quite a few Java programs that will bring a fast system
to its knees. I really can't see anyone writing outside of web
interfaces to databases and such in java. Possibly its the type of
volume and environment i write in (logistics).
It's also worth noting what most of the applications and virtually
all of the OS and utility programs are written for under unix - C/
C++. There are lots of perl, python, and java apps on the front
end but most of the background work is done by programs
written in C++.
You have a requirement for some very tight & fast algorithms that are heavily used? C++ supports inline assembler and allows you to glue your tight&fast assembler routines with your high-level objects. Of all the other languages mentioned, only a few other can make that particular claim.
OK, so maybe your requirements don't need code that's "close to the metal" for speed reasons. But maybe you have requirements for an app that will be very IO-bound (instead of CPU-bound) and require direct access to the OS system calls. Again, C++ is right there for that with all OS's for which there's a compiler. Infact, this is particuarly important today because many OS's implement thread libraries to be handled at the OS level, and not the language level. In the past, I've found it particularly handy to access the native system-calls and C++ was the best and fastest way to handle a ton of worker threads, while keeping track of my user interface state. Today, there's better support at the language level for threading, so this argument is less important today.
OK, so your requirements don't require talking directly to the OS because maybe you're using some sophisticated library environment to shield your form the particulars of the machine. C++ can handle that quite well. You can write fully 100% object-oriented code that is portable, if you want. You don't HAVE to use pointers if you don't want to. Nor do you HAVE to use explicit casting, if you don't want to. I'll admit that it requires a more disciplined and experienced programmer to do this. But the point being, the language supports it, if you want to take advantage of it. Your choice. (My favorite word -- choice.)
Regarding pointers and/or other "unsafe" language features. As I already said, you don't have to use them if you don't want to. But they make implementing certain algorithms so fast and easy that would otherwise be a headache with pure object-oriented syntax. Pointers also make interfacing with C libraries convienient.
But it's true undisciplined and/or unexperienced programmers can missuse them. But is that a language problem or a people problem? Is it right to bash the language for a people problem? This gets into other areas, such as project management in the IT world where non-technical managers are commonplace and have no idea the difference between a disciplined programmer and one who instantiates objects without regard for deleting them. You could get around this problem using Java I suppose. But Java brings other problems with it -- mostly the fact it's such a resource hog (both CPU and main memory) which requires spending (possibly) millions of dollars worth of of hardware to compensate for the slow and inefficient nature of java.
Anyway, my larger point is the fact C++ can handle 99% of any programming language need you'll encounter. Which other languages can make that claim?
With that said, I also am a firm believer in using "the right tool for the right job." I know there are particular situations that C# may be more appropriate, or Perl or Java. Fine; I have particular loyalty to the language. I just admire the fact that no matter what the problem, C++ is ALWAYS a potential candidate -- it's just a matter of determining whether there's something better.
I like the language, the environment, but I'm worried less and less developpers are using it.
Does anyone have info about it ?
- ...
- by Everfrost June 14, 2005 10:05 AM PDT
- Programming languages have their forte and really cannot be based on popularity. Each programming language has its uses and is really based what needs to be programmed.
- Like this Reply to this comment
-
(40 Comments)