Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We have C++14

isocpp.org

Post reply on HN
Print view View original

301–310 of 353 posts

Re: We have C++14

#301

Post by pjmlp »

loup-vaillant wrote: post #300
pjmlp wrote: post #297

Earlier quoted context omitted.

Companies don't want to pay for training.

Not even 4 weeks worth of semi-productive self-learning? That sounds quite pathetic. There must be something else, like fear of the unknown, risk aversion, "nobody got fired for choosing IBM"…

I know consulting companies that bill the customer the hours developers spend getting up to speed with a given technology.

In the cases the customer is not willing to pay, developers get asked to learn off work hours, if they want to stay on the project.

Re: We have C++14

#302

Post by eco »

jnbiche wrote: post #240
PaulFreund wrote: post #217

Earlier quoted context omitted.

Don't forget D

D is fine language and a pleasure to program in, but with it's required garbage collector, it's not really in the same niche as C/C++/Rust. I think the hallmark of this niche is the ability to run without a garbage collector penalty and the accompanying lack of determinism.

You can use D without using the GC. I'm not sure why this myth keeps coming up. It's always supported manual memory management. You have to sacrifice some language features that aren't even available in C++ and some parts of the standard library use the GC but that is easy to avoid with yesterday's 2.066 release and the @nogc attribute. 2.067 should also have a lot of the standard library switched to using lazy algorithms where possible which means the caller gets to determine the allocation strategy (and can often avoid allocation entirely).

void main() @nogc { /* ... */ } // this program doesn't use the GC

Re: We have C++14

#303

Post by ufo »

jonstewart wrote: post #110
zak_mc_kracken wrote: post #102

Earlier quoted context omitted.

It was the right default twenty years ago for performance reasons. These days, the economy of a vtable pointer is not really a good reason, and all languages that have the opposite default (such as Java, as you point out) are doing quite fine. Because of this default, I can't count the number of times where I've seen "#define private public" and other horrors that developers used to be able to extend classes that the…

I'm very glad that virtual is not the default. Most of the classes I write are simply value classes and do not use inheritance at all. Once you start using virtual, you really have to embrace traditional inheritance idioms whole hog, and then you've got std::vector > instead of std::vector . If anything, the performance difference between std::vector > and std::vector is even greater today than it was twenty years ag…

On the flipside, if you are not using inheritance then you could have solved the same problem with abstract data types. The only big problem is that in C++ the method call syntax is much more convenient to use: foo.frob() vs Foo::frob(foo). IMO, the correct way to fix this is by adding syntax sugar to the language, not by making methods non virtual by default.

Re: We have C++14

#304

Post by eco »

microtonal wrote: post #182
CountSessine wrote: post #175

Earlier quoted context omitted.

Ecosystem really is the whole problem, though. You can never make it big without having lots of friends. Rust is a pretty cool language, but I can't help being reminded about another very well-designed but ultimately unsuccessful C++ challenger, D. The parallels are really hard to ignore. D, like Rust, had great syntax and was a breath of fresh air after coding with C++98. Neither Rust not D has a sponsor with really…

There are important differences: D threw away one of the most important features of C/C++ (for the target audience): usability of the language without a garbage collector. Also, Mozilla has much deeper pockets than Digital Mars. Still I agree with you that it is very likely that Rust will follow a parabolic trajectory. The advantages as perceived by the industry compared with C++11/14 will be too few. At the same tim…

Could you be specific about what in D isn't useable without the GC? You can use manual memory management in D. It has Unique (unique_ptr) and RefCounted (shared_ptr). It has Array. It has malloc and free. None of these use the GC.

People complain about the GC being available to use while simultaneously complaining that to avoid it you have to manage your memory yourself. You can't have it both ways. There is no memory allocation strategy that works best in every situation. Sometimes ref counting is best, sometimes stack allocation, sometimes RAII, sometimes memory pools, sometimes its the GC.

Rust has done some cool work with memory but even it doesn't free the programmer from having to consider and choose which memory allocation/ownership option is going to deliver the best performance on a case-by-case basis.

You're right about Rust and Go having much deeper pockets. D isn't backed by any corporation. It's 100% a community project. Maybe it won't ever gain a significant market share because of this. I don't know.

Re: We have C++14

#305

Post by wfunction »

exDM69 wrote: post #282
wfunction wrote: post #162

Earlier quoted context omitted.

You say "if you build the cross-compiler" as though it's as simple as "if you cross the street". Have you ever tried building GCC? I've wasted days on it and in the end still failed to make it work.

> Have you ever tried building GCC? I've wasted days on it and in the end still failed to make it work. I've hand-built GCC for half a dozen of different target architectures over the years and it's perhaps one of the most stable pieces of software when it comes to building it. I've only had one build failure over the years and that was unstable from git (even that usually works no problem). To build GCC, follow the…

I don't know how you manage it, but I can tell you it is not reasonable to expect people to compile every compiler they want to use on every system they want to use it.

Re: We have C++14

#306

Post by wfunction »

zak_mc_kracken wrote: post #179
wfunction wrote: post #163

Earlier quoted context omitted.

Seemingly off-topic, but I'm curious -- what language has the majority of your 20+ years of development been in?

Professionally, Java for most of the time. Recreationally, Scala and Haskell. I did about 5 years of C++ overlapping with Java before that.

Ok, that explains it. When you're used to Java it's easy to expect inheritance to be a big deal. The fact of the matter is that run-time polymorphism (aka virtual) is much more rarely necessary in the C++ world than the Java world. The only reason it's common in Java is that it's the only tool available for many job that C++ has other tools for, and it also avoids an extra composition overhead that doesn't exist in C++.

tl;dr: Just because it's "infinitely more valuable" in Java doesn't mean the same for C++.

Re: We have C++14

#307

Post by wfunction »

chetanahuja wrote: post #203
sillysaurus3 wrote: post #164

Earlier quoted context omitted.

Yes, RAII is the only way to make an exception-safe class. Good luck doing it. It's not easy. I know; I've tried. There are all kinds of corner cases and special considerations that you have to take into account. People have written huge tomes about that exact topic detailing exactly why it's a hard problem and why you're probably not going to solve it correctly by accident. You're far more likely to introduce a memo…

"Good luck doing it. It's not easy. I know; I've tried" Completely unsupported assertion (no pun) without evidence. Other people have tried it, and have succeeded. I could start listing all the software written in C++ that you use in your everyday life, perhaps 100's of times a day... but that'll quickly exhaust my word limit for this post. "That's why C++ is overly cumbersome unless you ignore most of its capabiliti…

Actually that statement has a point. Have you ever tried implementing std::vector and java.util.ArrayList and comparing the two implementations? One of them is trivial, the other one is most certainly not. One of the reasons is exception-safety guarantees. I'll leave it for you to figure out which is which.

Re: We have C++14

#308

Post by abdulhaq »

deong wrote: post #268
microtonal wrote: post #182

Earlier quoted context omitted.

There are important differences: D threw away one of the most important features of C/C++ (for the target audience): usability of the language without a garbage collector. Also, Mozilla has much deeper pockets than Digital Mars. Still I agree with you that it is very likely that Rust will follow a parabolic trajectory. The advantages as perceived by the industry compared with C++11/14 will be too few. At the same tim…

I would also say that D did itself irreparable harm with the whole v1-v2 standard library debacle. Right when it was receiving the most attention, it came right out and said to anyone who might have considered it, "we have two incompatible versions of the standard library: one which we don't support anymore and one you can't use yet."

That was then and this is now, there is one standard library and the language has come on leaps and bounds. D is a great language.

Re: We have C++14

#309

Post by eco »

deong wrote: post #268
microtonal wrote: post #182

Earlier quoted context omitted.

There are important differences: D threw away one of the most important features of C/C++ (for the target audience): usability of the language without a garbage collector. Also, Mozilla has much deeper pockets than Digital Mars. Still I agree with you that it is very likely that Rust will follow a parabolic trajectory. The advantages as perceived by the industry compared with C++11/14 will be too few. At the same tim…

I would also say that D did itself irreparable harm with the whole v1-v2 standard library debacle. Right when it was receiving the most attention, it came right out and said to anyone who might have considered it, "we have two incompatible versions of the standard library: one which we don't support anymore and one you can't use yet."

Yeah, that certainly hurt D's reputation. People still bring it up even though it's been resolved for years.

Re: We have C++14

#310

Post by abdulhaq »

72deluxe wrote: post #206
PopsiclePete wrote: post #98

Earlier quoted context omitted.

Too bad it's a mirage. No, really. "Modern C++" doesn't exist outside of blog posts, books, and tutorials. Real-world C++ is an array of sometimes mututally-exclusive dialects, patterns, rules, sub-dialects. Reading MFC is nothing like reading Qt which is nothing like WxWidgets which is nothing like Boost which is something (but not quite like) the STL which is way different from Apache C++ libs which is way differen…

I have furniture at home made of wood. Oddly, my table looks nothing like my broom handle, so does this mean that wood is a terrible choice for both items? "The industry would be better off without wood!!" Surely libraries in other languages have the same problem? They don't look anything like each other. wxWidgets and Qt look nothing like each other but it isn't a problem at all. The signalling mechanism / event han…

Forget about the downvotes, if you're not trolling then know they are a red herring.
Post reply on HN