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

Type-Safe Unions in C++ and Rust

genbattle.bitbucket.org

Post reply on HN
Print view View original

101–110 of 140 posts

Re: Type-Safe Unions in C++ and Rust

#101

Post by jjnoakes »

pcwalton wrote: post #96
jjnoakes wrote: post #93

Earlier quoted context omitted.

Please don't tell others what not to do. First, there are cases where compiling other languages to C or C++ is better than via LLVM; interoperability and portability are two (yes, C and C++ are more portable than LLVM). Second, I'm not really talking about compiling some wildly different language to C++. I'm talking about some simple syntactic sugar. The same syntactic sugar that would be in an existing C or C++ comp…

Effort in this direction would be better spent just adding new features to clang (or GCC). It'll be so much easier than writing a new parser and semantic analysis for C++, which you will have to do if you want the new feature to behave properly in the presence of templates, etc. You'll end up wanting to just use clang's front end to help you, like most C++ tools do—and at that point why not just modify clang itself?…

> Effort in this direction would be better spent just adding new features to clang (or GCC).

In your opinion. This isn't a fact. For example, I know first hand of code that has to compile with compilers that are not in the set { gcc, clang, msvc }. What do I do then? (Oh, and those compilers are closed-source).

> You'll end up wanting to just use clang's front end to help you

Probably, although there are other options too

> and at that point why not just modify clang itself?

The changes I make, if useful to the community, would probably end up back in clang. But they would also remain a separate tool, because of all those other pesky compilers I work with.

> you can always revive the LLVM C backend

I'm not sure how that helps me; not only does it seem a terribly roundabout way to get what I'm looking for (instead of sugar -> c++ -> my c++ compiler, you are proposing sugar -> clang -> llvm -> c -> my c compiler), but I don't think objects produced by that pipeline would link with C++ objects produced from my native compilers, among other issues.

> The fact that nobody has bothered to revive it and keep it up to date enough to be merged into LLVM proper, to me, is a strong indication that few people need support for these obscure platforms.

Or, is it evidence that people using more obscure platforms (we're talking fortune 500 companies here) stick to languages that exist on their platforms for various reasons?

Re: Type-Safe Unions in C++ and Rust

#102

Post by jjnoakes »

pix64 wrote: post #97
jjnoakes wrote: post #51

Is there any demand for a syntactic sugar layer on top of C++? Something to make these new features more ergonomic? Something one could opt-in to for newer code, or code that doesn't need to be backward compatible to 1990? Something that outputs valid C++ and so works with any tool chain?

I think at that point you're creating a new language or at least a new (incompatible) version of the language. In this case, why limit yourself to C++ at all?

I don't see the distinction you are suggesting. Call it a new language if you like, but if it compiles to C++, looks 99% like C++, and just smooths over the warts, then whatever you call it, that's what I'm suggesting.

(I want it to compile to C++ so I can use the compilers I use and it can interoperate with the C++ code it has to interoperate with and C++ programmers that work on this code wouldn't have to learn more than a few extras that might make their lives easier).

Re: Type-Safe Unions in C++ and Rust

#103

Post by amluto »

alexeiz wrote: post #79
hellofunk wrote: post #12

Earlier quoted context omitted.

They are implemented completely differently. The only real similarity is in the name and API. Boost variant suffers from significant performance penalties that the new std::variant does not have.

If you look at http://www.boost.org/doc/libs/1_62_0/doc/html/variant/design... , Boost variant has no performance penalty due to backup storage if any of its bounded type is nothrow default-constructible. In practice, you just need a single nothrow default-constructible type in boost::variant to satisfy that requirement. This can be `int` or `boost::blank`. And that's that - no performance penalty.

> Boost variant has no performance penalty...

I have a big project that uses boost::variant. The runtime performance may be fine, but I swear that just compiling the header took about 5 seconds.

Pre-C++-11 fake variadic templates are just painful.

(IMHO two of the major missing features in Rust that are really need are integer generics and varidic generics. Without integer generics, arrays over 32 elements don't work correctly, and that's really annoying sometimes.)

Re: Type-Safe Unions in C++ and Rust

#104

Post by nambit »

jjnoakes wrote: post #102
pix64 wrote: post #97

Earlier quoted context omitted.

I think at that point you're creating a new language or at least a new (incompatible) version of the language. In this case, why limit yourself to C++ at all?

I don't see the distinction you are suggesting. Call it a new language if you like, but if it compiles to C++, looks 99% like C++, and just smooths over the warts, then whatever you call it, that's what I'm suggesting. (I want it to compile to C++ so I can use the compilers I use and it can interoperate with the C++ code it has to interoperate with and C++ programmers that work on this code wouldn't have to learn mor…

You're looking for some sort of code generator for C++ which only adds syntactic sugar? Interesting idea but I don't think a good one exists yet.

Re: Type-Safe Unions in C++ and Rust

#105

Post by sidlls »

oldmanjay wrote: post #83
sidlls wrote: post #77

Earlier quoted context omitted.

Ah, I see now. Thank you for clarifying. Not that I agree entirely, mind, just that your initial comment was clarified.

I'm always fascinated when people decide to have an opinion on facts. That little spark gets fanned into the flames of religion so easily, and it's no exaggeration to say it is a primary driver in the shape of our civilization.

I'm almost never fascinated when folks mistake opinion for fact. It's the primary driver in many language wars, as I see it. Some come to recognize that no language is perfect, especially their favored one. Others don't.

Re: Type-Safe Unions in C++ and Rust

#106

Post by oldmanjay »

sidlls wrote: post #105
oldmanjay wrote: post #83

Earlier quoted context omitted.

I'm always fascinated when people decide to have an opinion on facts. That little spark gets fanned into the flames of religion so easily, and it's no exaggeration to say it is a primary driver in the shape of our civilization.

I'm almost never fascinated when folks mistake opinion for fact. It's the primary driver in many language wars, as I see it. Some come to recognize that no language is perfect, especially their favored one. Others don't.

Language wars are just another religion, so I agree.

The real tragedy of being human is that no amount of intelligence can save you from being religious.

Re: Type-Safe Unions in C++ and Rust

#107

Post by optimuspaul »

bluejekyll wrote: post #63
optimuspaul wrote: post #53

Earlier quoted context omitted.

sorry if this is a dumb question, but what classifies a language as a research language?

That's a great question! I would probably restate it though. What is research vs. a product. I just read about 1nm transistors, but we're probably looking at 10 years before Intel, et al, have built all the infrastructure to reliably deliver a CPU based on it. In the case of a language, I would say it's similar, do you have the support infrastructure in place? Rust is amazing in this regard: Cargo, crates.io, docs.rs…

Thanks!

It seems very obvious now. I was thinking the purpose of the language was for performing research, but that didn't make much sense. I see now that it's the language itself that is the subject of research, not the tool. English is fun.

Re: Type-Safe Unions in C++ and Rust

#108

Post by tomne »

froydnj wrote: post #68
bluejekyll wrote: post #64

Earlier quoted context omitted.

I feel like this point is often made about C++: "in the future we will have that feature too!" If you don't want to wait, want to experiment with something else, learn a new language, etc., Rust is awesome. Obviously the counter argument to this is, "but there's 30+ years of C++ in production", but be honest, who actually wants to work on a 30 year old codebase?

GCC is very close to the 30-year mark (0.9 released 22 March 1987). Linux turned 25 this past year; Firefox (the C++ parts, at least) is very close to 25, depending on what code you want to count. Apache is 20ish years old. Even LLVM, which I think of as a relatively young project, is getting close to 15 years. Maybe (hopefully?) very little code survives from the initial versions, but they've all withstood the test…

The one thing I like about Rust is the fact that you can easily expose a C-like interface for libraries, which allows you to contribute to old codebases without much of a problem, best of both worlds (It has a non-trivial cost when starting, sure, but so does keeping C++).

Re: Type-Safe Unions in C++ and Rust

#109

Post by dbaupp »

nickpsecurity wrote: post #95
Jweb_Guru wrote: post #82

Earlier quoted context omitted.

This system does not support recursion. It also does not have to reason about atomics and so on because it is not intended for multicore systems; indeed, it assumes that all access is serialized through a mutex, and doesn't consider the existence of types like single-threaded reference counters (like Rust's Rc). It is describing threads with exclusive access, and a scheduling mechanism for waiting on locks, but the m…

"I agree that people have a strong tendency to not know what past work has been done, and Concurrent Pascal is admirable, but what Rust does is not the same thing. " I'm not saying it does. The claim I replied to said preventing things like data races was done till well into the 80's. I showed systematic investigations of the problem plus a production solution had been done by mid-70's. You've nicely showed how far a…

> The claim I replied to said preventing things like data races was done till well into the 80's

No, it definitely didn't: it said data races as a concept seemed to not be formalised until the late 80's.

Re: Type-Safe Unions in C++ and Rust

#110

Post by dbaupp »

nickpsecurity wrote: post #98
dbaupp wrote: post #80

Earlier quoted context omitted.

I don't have time to read it in full right now, but a quick glance over that paper doesn't show any formalisation of data races, which is specifically what that parenthetical is about, not just general "concurrency safety". Having a detailed description of concept seems important because Rust is fairly precise in what it defends against, possibly giving the programmer more flexibility and power than in a system that…

It's in the disk buffer and monitor examples. Here's a relevant quote: "A disk buÆer is a data structure shared by two concurrent processes. The details of how such a buÆer is constructed are irrelevant to its users. All the processes need to know is that they can send and receive data through it. If they try to operate on the buÆer in any other way it is probably either a programming mistake or an example of tricky…

None of that looks like a formalisation or even a description of a data race, at least not in the modern sense.
Post reply on HN