C++ killed my grandpappy - Is C++ hard and where are the C++ coders hiding?(hanselman.com)
hanselman.com
C++ killed my grandpappy - Is C++ hard and where are the C++ coders hiding?
http://www.hanselman.com/blog/CKilledMyGrandpappyIsCHardAndWhereAreTheCCodersHiding.aspx
11 comments
I believe that compilation problems you describe are caused by Microsoft's development tools (and by some weird quirks of Windows as a platform) and not by C/C++ itself. Every time I build something for Windows I get this feeling that it's actually hostile to code reuse across projects and that is the case even in .NET. Getting right import libraries (what are they for, anyway?) and getting IDE to actually know that you intend to link something/use some assembly seems horribly complicated in contrast to unix's #include <foo.h> and ld ... -lfoo
Also, having five different almost-compatible ABIs for C is something that really helps C/C++ programmers, especially in environment where it is common to ship compiled binaries, that are often very hard to rebuild from scratch.
Also, having five different almost-compatible ABIs for C is something that really helps C/C++ programmers, especially in environment where it is common to ship compiled binaries, that are often very hard to rebuild from scratch.
Have you looked into CMake to alleviate your compilation woes?
I recently started using it and its been very useful so far.
I recently started using it and its been very useful so far.
There's many reasons to criticize C++. None of them have to do with whether it's "managed" or not. Whether to use a "managed" (i.e., garbage collected and unable to perform unsafe memory access) language is an orthogonal issue; applicability of either approaches depends on the problem at hand. Some problems can't be solved without raw memory access, other problems can be solved but only at great performance and reliability cost, others don't benefit significantly from either approach yet others are dangerous or difficult to solve without memory management.
The real criticism of C++ is that it's an accidentally complex language (1) built by multiple warring tribes: one that wanted object orientation, the other that wanted static typing, yet another that wanted generic programming. What happened is that all of them won. Nonetheless, there is likely more than just a social reason no other language emerged for (relatively) high-level systems (2) programming (not that it hasn't been tried e.g., Modula-3 and most recently -- and promisingly -- Go). The only real alternative seems to be "C with objects" (e.g., glib or VFS layer in the Linux kernel).
That, however, still has nothing to do with what the article is about: is it me, or are the Windows C++ APIs just horribly designed? Qt, while far from perfect, is a just a lot easier to program to.
(1) It's fine for a language to be complex for a reason. Haskell is complex, yet that's because it's based on a very different paradigm which brings many advantages to the table. C is necessarily more complex than Python because it's meant to make systems programming possible.
(2) Nonetheless the domain of systems programming (which I'm going to ad-hoc define as something that requires dealing with memory addresses, the OS kernel and physical hardware) is shrinking. It's now possible (in terms of getting great performance) to write a database or a distributed lock manager in Java or a web server in Python or Ruby. So I am going to use "systems programming" here to mean operating system, driver, embedded, etc... development.
The real criticism of C++ is that it's an accidentally complex language (1) built by multiple warring tribes: one that wanted object orientation, the other that wanted static typing, yet another that wanted generic programming. What happened is that all of them won. Nonetheless, there is likely more than just a social reason no other language emerged for (relatively) high-level systems (2) programming (not that it hasn't been tried e.g., Modula-3 and most recently -- and promisingly -- Go). The only real alternative seems to be "C with objects" (e.g., glib or VFS layer in the Linux kernel).
That, however, still has nothing to do with what the article is about: is it me, or are the Windows C++ APIs just horribly designed? Qt, while far from perfect, is a just a lot easier to program to.
(1) It's fine for a language to be complex for a reason. Haskell is complex, yet that's because it's based on a very different paradigm which brings many advantages to the table. C is necessarily more complex than Python because it's meant to make systems programming possible.
(2) Nonetheless the domain of systems programming (which I'm going to ad-hoc define as something that requires dealing with memory addresses, the OS kernel and physical hardware) is shrinking. It's now possible (in terms of getting great performance) to write a database or a distributed lock manager in Java or a web server in Python or Ruby. So I am going to use "systems programming" here to mean operating system, driver, embedded, etc... development.
> is it me, or are the Windows C++ APIs just horribly designed?
There's your problem right there! Windows does NOT have an C++ APIs (if you put COM aside). They're all legacy plain-C APIs and they're difficult to fathom in our increasingly object-oriented world.
Keeping in mind backwards compatibility and isolation of memory management (no objects or memory allocations are passed across memory boundaries due to architectural reasons in the Windows platform itself and not due to the design of the API) between libraries, the Win32 API is actually remarkably well designed.
You've got C-based declarations for literally a hundred thousand functions, each with varying functionality depending on what you want to use it to accomplish. And it preserves backwards compatibility. And it has managed to keep up with the latest tech and features. Plus, half-way through, they went ahead and re-implemented each and every function in a Unicode version while keeping the old ASCII version fully available.
I used to think the same. I used to look at Win32 and groan. But when I realized the extent of its complexity, the domain constraints it was under (OS design, DLL isolation, etc) the requirements (backwards compatibility, static functions for literally everything).. it all made sense.
What gets me is new languages that have way worse problems without the same good reasons. Take a look at PHP and its strlen vs str_pad (why _ sometimes and sometimes no?) and its str_replace(needle, needle, haystack) vs strstr(haystack, needle)... that's uncalled for, badly designed, and with no excuse.
There's your problem right there! Windows does NOT have an C++ APIs (if you put COM aside). They're all legacy plain-C APIs and they're difficult to fathom in our increasingly object-oriented world.
Keeping in mind backwards compatibility and isolation of memory management (no objects or memory allocations are passed across memory boundaries due to architectural reasons in the Windows platform itself and not due to the design of the API) between libraries, the Win32 API is actually remarkably well designed.
You've got C-based declarations for literally a hundred thousand functions, each with varying functionality depending on what you want to use it to accomplish. And it preserves backwards compatibility. And it has managed to keep up with the latest tech and features. Plus, half-way through, they went ahead and re-implemented each and every function in a Unicode version while keeping the old ASCII version fully available.
I used to think the same. I used to look at Win32 and groan. But when I realized the extent of its complexity, the domain constraints it was under (OS design, DLL isolation, etc) the requirements (backwards compatibility, static functions for literally everything).. it all made sense.
What gets me is new languages that have way worse problems without the same good reasons. Take a look at PHP and its strlen vs str_pad (why _ sometimes and sometimes no?) and its str_replace(needle, needle, haystack) vs strstr(haystack, needle)... that's uncalled for, badly designed, and with no excuse.
The WinAPI is horribly designed. The choice of language has nothing to do with it. A plain C API can be a joy to work with (e.g. pthreads, or any POSIX API). There is just no excuse for the myriad of WinAPI functions that take 13 parameters in random order, most of which need to be set to 0, -1 or NULL to get it to work.
The excuse is backward compatibility, and it is also why linux binaries from 3 years ago doesn't work on new linux, and win32 binaries does (or at least did before vista age).
PS I prefer linux way (clean the api, no matter old binaries), but that's because I'm programmer, as a user I would love to just download old binary from net and have it work without worrying about dependencies.
PS I prefer linux way (clean the api, no matter old binaries), but that's because I'm programmer, as a user I would love to just download old binary from net and have it work without worrying about dependencies.
I was amazed to find that a version of the Zeus editor dating back to 1995 still runs fine on Windows 7 and that software is not even Win32. It's written in Win16.
And here is the link to prove it: http://www.zeusedit.com/z300/zeus-v103.zip
And here is the link to prove it: http://www.zeusedit.com/z300/zeus-v103.zip
My last windows was xp, bu I've heard win7 was supposed to have virtual machine with winXP to run older program. If so, this is cheating :)
Not really. You need to separately install the XP Virtual Machine software on Windows 7. He means it actually runs "out of the box."
(Windows 7's XP emulation mode is nothing like the super cool Rosetta on OS X)
(Windows 7's XP emulation mode is nothing like the super cool Rosetta on OS X)
I worked on a popular medical imaging application that was released with Win95 support and still working with Vista/Win7. That's some impressive longevity. Mind you there were adjustments along the way to support newer DirectX libraries etc. but the rest of the application was able to compile fine.
To compile fine is one level, the other is to run fine without recompiling - it's easy to break binary compatibility - http://techbase.kde.org/Policies/Binary_Compatibility_Issues...
Well while it may not have an explicit C++ interface, I've found that you can go very far using ATL & WTL. These form a very nice and thin C++ wrapper to the Win32 API and also give you some handy smart pointers and STL container adapters. I've used ATL & WTL with STL and Boost with no problems.
There's your problem right there! Windows does NOT have an C++ APIs (if you put COM aside). They're all legacy plain-C APIs
Ah. This brings back memories of checking to make sure the linker is de (or was it re) mangling the API names to make them work with C++
I've coded in C and C++ against the Win APIs. In fact, once I learned C, moved to windows (yay Petzold!) my first windows app was in Borland, home-grown C++ against the win api. Then I moved to OWL, then MFC.
One of the tough things about the C/C++/Win learning path is this: although it's probably 1/3 of the optimum shit to learn (functional programming, compilers, and algorithms are the another third, and set theory and databases the final third) it's also a freaking long haul from int a = 0; to Win COM programming. (And having said that I remain a C++ fan)
Ah. This brings back memories of checking to make sure the linker is de (or was it re) mangling the API names to make them work with C++
I've coded in C and C++ against the Win APIs. In fact, once I learned C, moved to windows (yay Petzold!) my first windows app was in Borland, home-grown C++ against the win api. Then I moved to OWL, then MFC.
One of the tough things about the C/C++/Win learning path is this: although it's probably 1/3 of the optimum shit to learn (functional programming, compilers, and algorithms are the another third, and set theory and databases the final third) it's also a freaking long haul from int a = 0; to Win COM programming. (And having said that I remain a C++ fan)
Yes, I am also another C++ coder coming out of the closet!
I first learned C programming on a technology course in around 1992/3, and then also learned C++ using the Borland compiler running on DOS. I've used C++ on and off ever since, both in commercial and hobby projects. I always disliked MFC, which seemed horribly non-standard, and in the last 5 years have been mainly using gcc as my preferred compiler. I briefly ventured in to the world of MS C++.NET, but the code looked utterly horrifying with all the .NET stuff crudely crowbarred into it.
I am completely aware of the advantages of managed code, and have also done quite a lot of coding in C# (mono), and some in Java. Having been a C# fanboy for a while I've recently reverted to C++ programming in the last year or so, mainly due to software patent concerns. However, I would not describe myself as a "language zealot", and have used multiple programming languages over the years in a highly pragmatic fashion.
I first learned C programming on a technology course in around 1992/3, and then also learned C++ using the Borland compiler running on DOS. I've used C++ on and off ever since, both in commercial and hobby projects. I always disliked MFC, which seemed horribly non-standard, and in the last 5 years have been mainly using gcc as my preferred compiler. I briefly ventured in to the world of MS C++.NET, but the code looked utterly horrifying with all the .NET stuff crudely crowbarred into it.
I am completely aware of the advantages of managed code, and have also done quite a lot of coding in C# (mono), and some in Java. Having been a C# fanboy for a while I've recently reverted to C++ programming in the last year or so, mainly due to software patent concerns. However, I would not describe myself as a "language zealot", and have used multiple programming languages over the years in a highly pragmatic fashion.
I suspect the majority of C++ programmers is older (44 myself), has gotten ranting and raving out of their system and are now quietly doing their jobs. I remember heated discussions about dynamic vs. static typing or templates vs. avoiding code bloat on Usenet but now I feel too complacent to pick any more fights.
I think part of it also has to do with the availability of free alternatives for all different paradigms. Back when a decent C++ compiler (Zortech!) would set you back hundreds of dollars it was easier to get defensive about your choice of programming tools and speak up.
When the job requires it I still use C++ but not as much as I did 10 years ago; 15 years ago I was using only C++. C++ has survived Java, seems to be on friendly terms with C# and will be still around when the functional bubble has popped.
I think part of it also has to do with the availability of free alternatives for all different paradigms. Back when a decent C++ compiler (Zortech!) would set you back hundreds of dollars it was easier to get defensive about your choice of programming tools and speak up.
When the job requires it I still use C++ but not as much as I did 10 years ago; 15 years ago I was using only C++. C++ has survived Java, seems to be on friendly terms with C# and will be still around when the functional bubble has popped.
I'm 24 and I've been coding C++ for the past 4 years, it was my first language and remains the one I use the most, though I've used Ruby professionally most recently, I'm trying to get a C++ gamedev job now.
So its not just the older crowd, it very much depends on what you're trying to do I think.
So its not just the older crowd, it very much depends on what you're trying to do I think.
The subtext of this article is "I found C++ daunting at first, but after I'd been programming for a number of years I revisited it and found it quite useful."
I'm not sure C++ coders are hiding. They are in plain site in many industries.
Yes, compared to today's scripting, languages, C++ is hard (but not impossible) to use. There are no soft, rounded edges to protect rash programmers who make incorrect assumptions. Basically, C++ makes us stop and really think about what we are asking the computer to do. It makes us evaluate data structures, types and how we use those things.
Ruby and Python hide those details to a large degree (I use and like them both) and there are times when that is OK, but we also need the rigor and requirements found in C++.
If I could only have two languages, I would choose Python and C++. If only one, then C++.
EDIT: Management sometimes want quick and dirty and out the door apps yesterday! I would not suggest C++ for that unless you have an expert team, but one of today's scripting languages would be fine for that sort of environment. I may also note that environments such as that will not keep expert development teams for long.
Yes, compared to today's scripting, languages, C++ is hard (but not impossible) to use. There are no soft, rounded edges to protect rash programmers who make incorrect assumptions. Basically, C++ makes us stop and really think about what we are asking the computer to do. It makes us evaluate data structures, types and how we use those things.
Ruby and Python hide those details to a large degree (I use and like them both) and there are times when that is OK, but we also need the rigor and requirements found in C++.
If I could only have two languages, I would choose Python and C++. If only one, then C++.
EDIT: Management sometimes want quick and dirty and out the door apps yesterday! I would not suggest C++ for that unless you have an expert team, but one of today's scripting languages would be fine for that sort of environment. I may also note that environments such as that will not keep expert development teams for long.
> Yes, compared to today's scripting, languages, C++ is hard (but not impossible) to use. There are no soft, rounded edges to protect rash programmers who make incorrect assumptions. Basically, C++ makes us stop and really think about what we are asking the computer to do. It makes us evaluate data structures, types and how we use those things.
To me it looks like you're talking about C, rather than C++.
C++ always makes me stop and think how the compiler will react to certain code, and how it is supposed to behave with regards to the ISO standard(s). Actually reading the standard usually makes things worse (again, for me), so I'd choose python anytime.
EDIT: (formatting)
To me it looks like you're talking about C, rather than C++.
C++ always makes me stop and think how the compiler will react to certain code, and how it is supposed to behave with regards to the ISO standard(s). Actually reading the standard usually makes things worse (again, for me), so I'd choose python anytime.
EDIT: (formatting)
I see that some people in the comments on Hanselman's site are using the terminology "C/C++". Back when I was learning C and C++, it was described as poor form, and a sign that that the writer didn't know either language very well.
Has it become more acceptable to conflate the two languages in recent years?
Has it become more acceptable to conflate the two languages in recent years?
No....what you're seeing is a side-effect of the fact that most critics of C++ these days don't actually know the language. It's still wrong to conflate C and C++, but since most students now come up learning Java, they rarely encounter C++ as its own language. It gets grouped together mentally with those "nasty, C-like languages", and the stereotypes linger.
Has it become more acceptable to conflate the two languages in recent years?
[deleted]
Its not the antichrist; its not a panacea; its just another language. Its like my yellow framing hammer; useful for one job, but I have other hammers too.
Yay, you can write real app in C++.
Still - writing code againist windows api is begging for portability problems. Why even bother with all those quirks, when there is qt and gtk, working on Macs and Unices as well, and better designed?
I can only understand this, if it's just for fun. Peple have weird hobbys :)
EDIT: I also love, how they speak about .Net like it was the only alternative to C++.
Still - writing code againist windows api is begging for portability problems. Why even bother with all those quirks, when there is qt and gtk, working on Macs and Unices as well, and better designed?
I can only understand this, if it's just for fun. Peple have weird hobbys :)
EDIT: I also love, how they speak about .Net like it was the only alternative to C++.
Scott Hanselman is a .NET guy, most of his readers are .NET developers, he was simply contrasting it with what the majority of his readers use.
C++ in "it's a real language" shock!!!
C++ is great. It's very powerful, it's very fast, and actually, very easy to use. Especially on Windows.
If you want quick and dirty access to system functions, if you want to be able to quickly open a pipe, write raw data to it, and be on your way. If you want low-level access to a buffer, to the memory, to a file. If you want to do basic string parsing. It's all there.
.NET is certainly a better platform but it's not as inherently powerful. On Linux, it's rather different because at this point you can do anything in Python or Java that you can in C++ (except drivers and kernel modules, etc.). On Windows, that's not exactly the case.
I love the control that C++ gives me. I can decide when a object is passed by reference and when it's by value. I can send a object as constant by reference explicitly and therefore make no mistake about it. I can use pointers to fly to pre-determined locations in a buffer. I can jump pointers to access hard-coded offsets in a struct. I choose not to use templates willy-nilly and to never do multiple inheritance. I don't use things that are hard to maintain, but I take pride in using quick and dirty innovative solutions where it's short on steps, but not short on self-explanatory functions (i.e. shortcuts in functionality, not in LoC).
C++ is as complicated as you make it. It gives you a lot of rope to hang yourself with. It gives you a lot of flexibility. It gives you a lot of power. When writing a filesystem monitor that parses hundreds to thousands of events per second, I use raw char* pointers and manual memory allocation (with a 3rd party allocator, no less). When doing userland apps, I use automatic memory management with smart pointers.
I have all the flexibility and automation of .NET and Java - but I also have the choice not to use it.
But stick a beginner in C++, and they'll fail to see that there are many options, some of them even easier than their managed counterparts. They'll get lost battling pointers and confusing their laws of inheritance, and they won't see the forest for the trees. They'll overuse templates when they're not necessary, and not use the well-syntaxed and to-the-point STL algorithms when they're available.
In .NET, I find myself longing for raw memory access at times. I find myself wishing that the .NET team bothered themselves to add wrappers to even more Win32 functions and that I don't have to have a class full of 50 to 100 P/Invokes in order to get access to what I consider for my needs to be essential Win32 calls.
But .NET makes working with a team easy. It makes it easy to set standards and stick to them. It makes it easy to keep track of objects. It makes it super easy to integrate GUI and code in a way that makes sense (MFC begone!). I can use .NET to write a terribly complicated app in a matter of an hour and have it deployed with minimal effort spent on error proofing the application. I don't have to worry about checking the return value of each and every call I make - a single catch() that's well written will take care of it all. I don't need to worry about finding headers that fit my coding style or bother myself with linker errors. A ton of libraries exist only a "using ...." away.
The worst thing about C++, without doubt, isn't the language or the syntax: it's the compilation problems. When you have multiple cyclic dependencies. When you have functions to export, and similar functions already imported from one of the dependencies you already have. DLL hell. Conflicting versions of the CRT. Having to search for the source code of a module you wrote years and years ago in order to re-compile it against the same C runtime that you're using in your current project. Having to keep a copy of both .h and .lib files for all your DLLs in order to use them again in a later project. Stuff like that is where I really appreciate the .NET way of doing things.