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

341–350 of 353 posts

Re: We have C++14

#341

Post by infinite8s »

eco wrote: post #304
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…

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 memor…

It took python (which also doesn't have a deep-pocketed company backing it) about 15-20 years before it saw widespread adoption.

Re: We have C++14

#342

Post by cubbimew »

sillysaurus3 wrote: post #332
jonstewart wrote: post #328

Earlier quoted context omitted.

We're talking about the same book, _Exceptional C++: 47 Engineering Puzzles, Programming Problems, and Solutions_, by Herb Sutter. The takeaway I had from reading that book (a long time ago) was just to use RAII religiously, which also tends to make other things easier. So I'm curious about why you think RAII makes writing exception-safe code difficult?

Sorry for the confusion. I meant that writing exception-safe code is difficult, not that RAII makes it difficult to write exception-safe code. I should have been clearer about that. The book is excellent. For anyone who wants to use C++ exceptions, it should be required reading. But as someone who has gone through that gauntlet, I feel that I probably would've been better served by spending my time on something other…

> either people prefer both or prefer neither.

exceptions (specifically, exceptions from constructors) are part of what RAII is, so it's only natural that people "prefer both".

As another personal anecdote, in my experience working with a large (175MLoC at last count) mostly-C++ codebase, I can't imagine how painful it would have been if the code didn't use exceptions.

Re: We have C++14

#343

Post by nly »

maxlybbert wrote: post #313
masklinn wrote: post #284

Earlier quoted context omitted.

> Being careful is not enough. UTF32 will not help you much with that, save that you've got a separate type for "strings" and "bunch of bytes" Which you can have anyway, so do that, it's a good idea which doesn't require using UTF32. > But UTF-8 for in-memory strings has a long track record of being much harder to actually do correctly. As if other in-memory encodings had a better track record.

Nobody's ever accidentally tried to uppercase a UTF-32 string by passing each code point to C's toupper() function; but that constantly shows up in projects using UTF-8 for in-memory strings. And it's not always caught by unit tests. People never accidentally pass a UTF-32 string to a legacy API that expects char*'s in Latin1 encoding. I when I say "never" I don't mean "almost never happens"; I mean literally "anybod…

> Nobody's ever accidentally tried to uppercase a UTF-32 string by passing each code point to C's toupper() function

Note to put aside, since this was all about C++, the toupper() in is a template type that takes an arbitrary character type and a locale. There are also functions for locale sensitive collation and comparison. So, modulo bad implementation, you should be able to do basic unicode string handling in ISO C++.

The GNU stdlibc++ manual goes in to quite a lot of detail:

https://gcc.gnu.org/onlinedocs/libstdc++/manual/localization...

Re: We have C++14

#344

Post by maxlybbert »

masklinn wrote: post #337
maxlybbert wrote: post #324

Earlier quoted context omitted.

I didn't miss it. I simply know projects that use UTF-8 for in-memory strings, and none of the ones I'm familiar with uses a different type for it. It's all convention, and they all occasionally find that somebody flubbed the convention. Can you point me to any projects that manipulate UTF-8 encoded in-memory strings and actually use a different type for it them? I realize I won't convince you. That's what I meant in…

> I simply know projects that use UTF-8 for in-memory strings, and none of the ones I'm familiar with uses a different type for it. Which is relevant… how? > Can you point me to any projects that manipulate UTF-8 encoded in-memory strings and actually use a different type for it them? Rust does. Python 3.3 does something similar but slightly different (it switches internal representation between iso-8859-1, UCS2 and…

Thanks for the pointers.

Re: We have C++14

#345

Post by maxlybbert »

mpyne wrote: post #327
maxlybbert wrote: post #324

Earlier quoted context omitted.

I didn't miss it. I simply know projects that use UTF-8 for in-memory strings, and none of the ones I'm familiar with uses a different type for it. It's all convention, and they all occasionally find that somebody flubbed the convention. Can you point me to any projects that manipulate UTF-8 encoded in-memory strings and actually use a different type for it them? I realize I won't convince you. That's what I meant in…

> Can you point me to any projects that manipulate UTF-8 encoded in-memory strings and actually use a different type for it them? Glib seems to. https://developer.gnome.org/glib/2.37/glib-Strings.html Though in complete fairness the type appears to be just a "bags of bytes" type and so could hold anything, it's really meant to hold UTF-8 (as you can tell from the functions that append/prepend Unicode chars).

Thanks for the pointer.

Re: We have C++14

#346

Post by cubbimew »

srj wrote: post #127
kyllo wrote: post #86

Earlier quoted context omitted.

Like Google for example? Their C++ style guide is pretty restrictive, here's an expert C++ programmer's takedown of it: https://www.linkedin.com/today/post/article/20140503193653-3...

This article is a bit strange. Complex initialization in a constructor can make it more difficult to unit test a class. Copy constructors aren't prohibited, it's just recommended that you remove the implicit versions when your class shouldn't be copied. Some of the C++11 features were blacklisted because Google has had its own implementations. In some cases these C++11 features are now allowed and the previous implem…

The guide that's publicly available says "If your class needs to be copyable, prefer providing a copy method, such as CopyFrom() or Clone(), rather than a copy constructor" I think that's insane. Or, at the very least, surprising to encounter when working with someone else's code.

Re: We have C++14

#347

Post by lmm »

microtonal wrote: post #314
lmm wrote: post #244

Earlier quoted context omitted.

I thought much like that (and was a huge Python fan) until I found Scala. There are cases people cite as "more than one way to do it", but they're usually superficial syntax differences. You do have to choose between passing around objects and passing around functions, but that's a choice you make in Python as well. It can handle high-performance calculation or high-level scripting, but it never feels like these are…

Scala is different than C++ in the sense that Scala at its core is a simple language compared to C++ and most abstractions are built from that. That said, there are different Scalas to, Scala the 'a better Java' is a very different language from scalaz/shapeless Scala. This seems to be the curse of any powerful core language (Scala, Haskell, ...) - on the one hand they allow you to make all kinds of useful abstractio…

I think it's good that a library can become sort-of "standard" without having to be part of the language standard library (where, as the python folk say, modules go to die). We're starting to see this come together in Scala-land - if you want a Monad typeclass you use the Scalaz one, if you want a HList you use the Shapeless one, and if you want HTTP you build on top of the spray-http abstractions (I'm particularly pleased that Play intends to port to run on top of Spray). That's something that you don't really get in C++, with the possible exception of boost; there are still multiple ways to do threading, multiple ways to do event-driven, all with their own conventions.

Re: We have C++14

#348

Post by deong »

pkolaczk wrote: post #335
deong wrote: post #330

Earlier quoted context omitted.

I tossed out Clojure as a random language -- all my testing was done with the most efficient Java and C# I could write. The link is fine, but only shows micro-benchmarks. It's much easier to get a 3x difference in execution speed between compiler versions when you have a three-line example -- you're maybe exercising 5% of the optimizer? The current version of the C++ I was using comes in at around 50kloc. The Java an…

> It's much easier to get a 3x difference in execution speed between compiler versions when you have a three-line example Those three lines can be as well a bottleneck in a big program, responsible for 80% of its runtime. This example was to show that compiler-induced performance differences in a single language can be just as large (here: up to 4x) as differences between Java and C++ in microbenchmarks. Therefore 2x…

I'm not saying there's never a use case for Java. It's reasonably well suited for server-side work (and most of your examples are IO-bound server processes).

When your main problem is IO, thread contention, etc., Java gives you better tools to address those problems. It's just not at all well suited for the kind of client apps that people run on their desktop computers, and to a lesser (but still visible) degree, it's not well suited for CPU-bound things like a lot of scientific computing, which is more where my expertise lies.

Looking at Jake2, the author notes: "The 0.9.2 release shows a big improvent due to the new “fastjogl” OpenGL renderer. The new renderer reduces the number of native interface calls. JNI calls produce a considerable overhead and were the main bottleneck in our application." If he's doing enough JNI to make this the main bottleneck, then clearly quite a lot of the heavy lifting isn't being done with Java.

Re: We have C++14

#349

Post by syncsynchalt »

maxlybbert wrote: post #92
syncsynchalt wrote: post #77

Earlier quoted context omitted.

Unicode code points can only take 4 bytes in UTF-8, this has been true ever since the planes were capped at U+10FFFF. Or did you mean UTF-8 encoded surrogate pairs?

Thanks for the correction. I don't know where I originally got the "up top six bytes" number from, but I've been using it for a while. Apparently, it's out of date (looking at the original proposal, https://en.wikipedia.org/wiki/UTF-8#Description , some code points were expected to need 6 bytes, but as you say, that's no longer true).

It was true until 2003, so in this case reality has been retconned on you.

Re: We have C++14

#350

Post by stormbrew »

loup-vaillant wrote: post #269
jnbiche wrote: post #240

Earlier quoted context omitted.

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.

Ordinary C++ with good old RAII do use something akin to garbage collection: many classes, when constructed, allocate memory on the heap, then free that memory when they fall out of scope. Malloc() and free() aren't exactly predictable. If you really want guarantees, you need to write your own custom allocator, and if you don't need those guarantees, garbage collection is probably enough for your purposes. Basically,…

RAII is a form of automatic resource management, it's true. It is, however, a deterministic form of automatic resource management.

This is not to say that the underlying allocator is necessarily deterministic, but you're making a false dilemma here by putting it in opposition to making decisions about custom allocators and pool allocators. You can use RAII with custom allocators. You can use RAII with memory pools.

And that's where C++ really does shine. It's a niche that hasn't even really been attempted much, let alone that it's been surpassed in.

Post reply on HN