It seems that people are so intimidated by the infamous complexity of C++ that they don't even want to bother getting more familiar with it.
So, although technically the existence of C doesn't make sense, as it is superseded by C++ (except couple of things), C is winning in the branding department.
I don't know if this is the reason why people choose C over C++ for some projects, but if language complexity is the reason, it isn't that people are just "so intimidated by the infamous complexity of C++ that they don't even want to bother getting more familiar with it".
In the 90s, C++ was much more popular than it is now. It was used as the go-to general purpose language for all kinds of "serious" software (not addressed by VB or Delphi). Early on, almost everyone was very impressed with the power C++ brought, but after a few years, as codebases aged, it became immediately clear that maintaining C++ codebases is a nightmare. The software industry lost a lot of money, developers cried for a simpler, less clever language, and C++ (at least on the server side) was abandoned en-masse -- almost overnight -- in favor of Java, and on the desktop when MS started pushing .NET and C#. So while today C++ is servicing its smallish niche quite well, as a general-purpose programming language for the masses it actually proved to be an unmitigated disaster. It is most certainly not the case that C++'s infamous complexity is "intimidating"; C++'s complexity is infamous because of the heavy toll it took on the software industry. Which is why, to this day, a whole generation of developers tries to avoid another "C++ disaster", and you see debates on whether or not complex, clever languages like Scala are "the new C++" (meant as a pejorative) or not.
I also feel like a lot of people are biased because of Stallman and Torvald's stance on C++. I kind of have an irrational distaste towards the language, mostly due to their influence.
I find funny that the by investing into JITs instead of optimizing compilers for Java and .NET, C++ managed to get a spot in HPC.
Now both Java and .NET eco-systems are getting there AOT optimizing compilers. .NET with MDIL and .NET Native, Java targeted for Java 10 (if it still goes to plan).
Also, thanks to Oracle's disregard by mobile platforms by not providing neither JIT nor AOT compilers for Java, C++ became the language to go for portable code across mobile OSes when performance matters.
> I find funny that the by investing into JITs instead of optimizing compilers for Java and .NET...
But that's because Java is meant to cover a very wide "middle" -- plus maybe a few corners where possible -- rather than every possible niche.
> Also, thanks to Oracle's disregard by mobile platforms by not providing neither JIT nor AOT compilers for Java
Well, it didn't start out that way, did it? But mobile platforms -- because they're rather tightly controlled -- are, and have always been, much more driven by politics than technical merit.
I am (or at least used to be, at some point) fluent in C++ and have built large applications with it. But I'd still rather write C, because its infamous simplicity is of a lot of use to me -- whereas I found that much of C++'s complexity tends to solve a lot of problems UML designers think we have, and very few problems that we actually have.
Not really. I'm sure this happens some of the time, but I suspect that's more common with developers who haven't written either.
In my experience, a lot of the developers who prefer C to C++ are developers who wrote a lot of C++, found that it only improved productivity in solving problems that it created, and went back to C and realized how much easier it is to write software in C.
C++ gets you caught up thinking about problems that don't even matter.
I would recommend you to first read "Tour of C++" or another book that explains better the new features on C++11. Meyers explain very well some of edge cases of move semantics but if you don't understand the concept first then you might not have a good experience reading the book.
>"says that 'don't use malloc and free, unless you want to debug 1980s' problems."
The problem with malloc and free is that they left to the developer to keep track of the references and memory corruptions bug are not pleasant to debug. RAII idiom actually helps a lot in that context, and that is what Strouptrup was referring to.
Also that example uses a Factory pattern which is actually verbosing the example, but it's like comparing apple and oranges since that's OOP which you actually wouldn't be doing in C.
Of course that is a stupid example; However things gets more interesting when you have pieces of code sharing the same structure (threads maybe?) and you don't know exactly which code should be the one in charge of releasing the pointer.
instead of a simple malloc and free, you will invariably end down the rabbit hole learning about rvalues. perfect forwarding, move semantics, lvalues - the list goes on - these topics arise from the simple concept of RAII.
>i think you misunderstand.
>clearly, it is C++, not C.
I got that, what I said is that you wouldn't have that problem in C because it arises when you are doing OOP, and most C devs would not use OOP. Also, keep in mind that it is perfectly fine not using OOP in C++.
> instead of a simple malloc and free, you will invariably end down the rabbit hole learning about rvalues
That's not true. Actually you can be a very decent C++ developer without knowing the notion of what an rvalue is. Move semantics is just an optimization to avoid extra copy of objects, so it is completely optional.
At the moment of writting this, there is an entry on the front page with an example of a modern C++ piece of code. You would notice that there is not a single explicit heap allocation nor any other crazy stuff.
i think moving data around in memory is not an exclusive feature of OOP and i hesitate to guess why you think that operations similar to those exposed by the 'move semantics' are not something undertaken (regularly!) by c developers using malloc and free.
> instead of a simple malloc and free, you will invariably end down the rabbit hole learning about rvalues
truth is subjective to me, in my experience, when you program C++ you will end up exploring a myriad of vast expanses of language features. you may feel that someone can be a very decent C++ developer without knowing that, plenty others would be aghast that someone ignorant of rvalues would describe themselves as 'very decent'.
remember the ostensible creator of the language rates himself at 8/10.
i think that front page example is rather interesting, given the number of #using directives - it gives an indication of the time that developer has spent learning the language. most of them are not trivial to understand to the degree that this guy has. also reading his background, i'm quite sure he knows what an rvalue is.
as you can imagine, i don't really mind explicit allocations - as an awful lot of knowledge is required in C++ to deal with implicit allocations.
in my opinion, there's a lot of 'crazy' stuff there, the short linecount is a product of the author having done his homework.
i get the impression that you and i would use very different subsets of C++. mine would be far smaller! i usually confine myself to whatever idoms the libraries i pull in use and go no futher.
The exietence of C makes perfect sense thanks, it's a relatively small and simple language with masses of flexibility.
C++ adds masses of complexity and implicit behaviour. While development in C++ can be quicker and might be 'safer' it can also produce all sorts of unexpected problems.
It also encourages all sorts of nested template types that can make existing codebases incredibly hard to read.
Further, in embedded situations, you may not have space for its standard library.
And a lot of complexity, obfuscation and implicit behaviour.
I have developed and enjoyed developing in both. C has an elegant simplicity about it and you can do literally anything. C++ can be quicker, and it has a bunch of useful standard stuff, but it does have some downsides and quirks. There's room in the world for both.
> So, although technically the existence of C doesn't make sense, as it is superseded by C++ (except couple of things), C is winning in the branding department.
Programming Languages are in the ___domain of UX. Type systems, syntax, RAII -- they all just a serve a means to an end, which is useability.
The title needs rephrasing, but I wouldn't expect someone to say that we're almost there with AI, as it would sound ridiculous, so I used my natural intelligence to correct the meaning of the title and understood it as the author had intended.
A certificate given by the ___domain registrar makes a lot of sense to me. My registrar holds my data and indeed can certify the identity of the ___domain.
Maybe MS desktop OS division was sort of douche, or maybe desktop MS office is not all that innovative.
OTOH, MS Research was always very cool (and they started contributing to e.g. OpenBSD many years ago), OS kernel has always been much better than a glance over win32 API shows you, and Office365 is definitely world-class.
I suspect that the engineering culture in MS has always been rather good (with engineers like you and me, and many of them a good deal better); the radical transformation is probably mostly within the top management.
The kernel is _very cool_. I get to work near it, and their description of the NT multi-headed setup helped change my mind about Microsoft engineering. e.g. the POSIX subsystem is just another NT usermode head, so it's incredibly performant.
I am not up to date on the latest kernels - I last wrote an NT driver in 2002 (Win2K/XP compatible), but based on that experience I beg to differ.
My no-stalgia: It was an overengineered beast at the time, with an original grand vision that wasn't performing well enough, and seemed to be fixed with duct tape.
The Video Driver + GDI, originally conceived to be outside the kernel, was too slow - so it was moved back in, causing a lot of problems.
The IO subsystem was nicely abstracted with IRPs. Except it was too slow, so they added the "FastPath" interface, which fixed the speed but made it impossible to safely unload or stack drivers. IIRC, they were the main reason for the "PlugFest" parties, where microsoft would invite vendors to come to place and then install their drivers in random orders and to debug the collisions -- the fact that microsoft needed to organize these parties is an indication of how bad it was.
The POSIX subsystem was removed in XP/Server 2002. Perhaps you mean SFU? That was discontinued in 2004. Oh, you mean SUA (nee Interix). Well, that was removed in 8.1.
And your experience might be different, but "incredibly performant" is quite the opposite of my experience with the POSIX subsystem.
You certainly work(ed) closer than I do, my experiences are mostly based off of what I see around me. I assume the kernel has changed quite a bit since Vista. I imagine that the POSIX system hasn't been entirely killed off quite yet, given it's already come back twice.
The POSIX subsystem was never there for technical reasons. It was there for political reasons - back in the day, a lot of government and army contracts mandated a POSIX system, so Microsoft made sure they comply with the letter of the law. (The intended spirit of the law was to require a standard OS to avoid vendor lock in....)
And they've been trying to remove it since that political requirement was off the table. Except it turns out that it was actually in used by some customers, so they keep bringing subsets back.
I wish they shipped their superb kernel as a separate product allowing third-party shells, as their UI design division has gone off the rails.
Actually, I think there should be a law for making OS kernels replaceable and separate from UI shells. I have to use Windows as certain software and drivers are not available/performant enough under Linux, so I have to deal with the crazy Windows 8.1 UX.
Pointers can be easily mapped from and into integer indices or file offsets in-place, so there is no big difference really.
I think it is generally not a good idea when in-memory representation of objects is identical to the serialized representation. This approach tends to backfire in a number of ways, such as format incompatibility between software versions, or hardware architecture differences, so it is always better to assume that your serialized representation will be different from in-memory representation.
This is such a retarded opinion. A person expressing it probably doesn't know shit about C++ or just plainly an idiot.