Live data from Hacker News

GCC 10.1 Released

gcc.gnu.org

101–110 of 145 posts

Re: GCC 10.1 Released

#101

Earlier quoted context omitted.

Let me quote exactly the page you linked : > The GNU C++ compiler, g++, has a compiler command line option to switch between various different C++ ABIs. This explicit version switch is the flag -fabi-version. If you want to target a given distro, you -fabi-version this distro's ABI, just like you set -mmacosx-version-min on mac or set _WIN32_WINNT on windows

That's something that might be useful for one of those rare end-users who for some reason want to try to build something with a bleeding edge compiler. That is also mind-numbingly absurd to force upon the vast majority who couldn't care less about the bleeding edge and want a stable platform to act as a fixe target without risking random ABI breakages. I should not be forced to endure a brittle and fragile and overly…

The ABI (the itanium ABI) is fixed, but somtimes there are bug in the compiler and gcc deviates from the abi in some corner cases. When the bug is fixed the gcc abi version is bumped which most of the time doesn't matter but if the bug fix affects you (and very often it doesn't), you can 'roll it back' by selecting a specific ABI version. Not fixing the bug is not an option because it means that GCC would be incompatible with other compilers that don't have the bug.

Re: GCC 10.1 Released

#102
post #10

Earlier quoted context omitted.

You Rust borrow checker requires special annotations and restrictions put on the code to do its job. I don't think you could something like that automatically on a C or C++ full codebase without having to manually annotate and refactor it somewhat. There are many common (and safe) C and C++ patterns that would be outright rejected by Rust's borrow checker, for instance initializing a structure or array partially if y…

> Rust borrow checker requires special annotations and restrictions put on the code to do its job. This is a good thing, because it makes lifetimes and ownership explicit and visible in the code. It serves the similar purpose as type annotations in function signatures. > Or having multiple mutable pointers/reference to the same object Sure you can have that with `unsafe`. And this is a good thing, because multiple mu…

> This is a good thing, because it makes lifetimes and ownership explicit and visible in the code.

No, it is additional burden. If it was possible to do it without annotations, you bet we would do it!

Re: GCC 10.1 Released

#103

Earlier quoted context omitted.

i don't know if you are being ironic or not, but the non-english speaking world will love it.

There are lots of other languages that support full UTF-8 in identifiers (e.g, Go) and the non-English-speaking world doesn't take advantage.

Some do: https://news.ycombinator.com/item?id=14276891

Re: GCC 10.1 Released

#104

Earlier quoted context omitted.

> That is also mind-numbingly absurd to force upon the vast majority who couldn't care less about the bleeding edge and want a stable platform to act as a fixe target without risking random ABI breakages. but why would you have "random ABI breakages" ? there isn't any issue with using e.g. VS2010, 2012, 2015, 2017, 2019 to make a windows software for instance, so what makes you think Linux would be any different if y…

> there isn't any issue with using e.g. VS2010, 2012, 2015, 2017, 2019 You're conflating things and in the process making absurd comparisons. Windows is not Linux and GCC is not msvc++. GCC is very vocal on how they don't support ABI compatibility, and Microsoft was very vocal ensuring they enforce ABI compatibility from Visual Studio 2015 onward. There's a fundamental difference in multiple dimensions, which isn't b…

> GCC is very vocal on how they don't support ABI compatibility,

What? Apart from bugs, GCC has maintained backward compatibility for more than a decade, for both the compiler ABI and the standard library.

They were forced to break ABI for c++11 to implement the new string and list semantics, but the old ABI is still available.

Re: GCC 10.1 Released

#105

Earlier quoted context omitted.

> That is also mind-numbingly absurd to force upon the vast majority who couldn't care less about the bleeding edge and want a stable platform to act as a fixe target without risking random ABI breakages. but why would you have "random ABI breakages" ? there isn't any issue with using e.g. VS2010, 2012, 2015, 2017, 2019 to make a windows software for instance, so what makes you think Linux would be any different if y…

> there isn't any issue with using e.g. VS2010, 2012, 2015, 2017, 2019 You're conflating things and in the process making absurd comparisons. Windows is not Linux and GCC is not msvc++. GCC is very vocal on how they don't support ABI compatibility, and Microsoft was very vocal ensuring they enforce ABI compatibility from Visual Studio 2015 onward. There's a fundamental difference in multiple dimensions, which isn't b…

> GCC is very vocal on how they don't support ABI compatibility

Source? They very rarely break ABI. They even release ABI break fixes sometimes.

> Microsoft was very vocal ensuring they enforce ABI compatibility from Visual Studio 2015 onward.

They try to keep ABI stable, but nothing is promised until the actual releases happen.

Always expect a new ABI version at some point in the future!

Re: GCC 10.1 Released

#106

Earlier quoted context omitted.

> Rust borrow checker requires special annotations and restrictions put on the code to do its job. This is a good thing, because it makes lifetimes and ownership explicit and visible in the code. It serves the similar purpose as type annotations in function signatures. > Or having multiple mutable pointers/reference to the same object Sure you can have that with `unsafe`. And this is a good thing, because multiple mu…

> This is a good thing, because it makes lifetimes and ownership explicit and visible in the code. No, it is additional burden. If it was possible to do it without annotations, you bet we would do it!

It's only a burden to the extent that type annotations are a burden. It's definitely possible (including in Rust) to do away with both, but that has downsides of its own.

Re: GCC 10.1 Released

#107
post #62
post #58

Earlier quoted context omitted.

As a non-English programmer who has seen a lot of code not written using English please, god, NO. The mixture of English and other languages identifiers in the external libraries makes me cry.

Yep, writing non english keywords in C++ is like having prolog code inside c++ :-) (but as a non english person, I find it very helpful to be able to have unicode in strings)

that's fine, keep using english.

But do not expect people that do not speak english to learn it if there's an alternative. Someday we might have multilingual frameworks and not restrict programming to the privileged few that could learn a second language.

Entitled programers are so into their broculture they can't see their own problems as being socially constructed.

On one hand they complain "reading mixed language code is hard, despite me being fluent on both! everyone should speak what is more convenient to me!" without realizing they are leaving billions of people that do not know english out. Then on this very same thread they also complain that "reading math with greek letters is too hard" despite that being an arbitrary rule set in place by the people that used greek and latin knowledge as a way to make their privilege less accessible. The irony is dense!

...don't even get me started on a programmer workers union.

Re: GCC 10.1 Released

#108
post #96

Earlier quoted context omitted.

He didn't say "english letters", he said "english" which is a language. The implication is that we should use conventions (including potentially whole words) that are familiar to the English-literate world and not Greek glyphs.

> The implication is that we should use conventions (including potentially whole words) that are familiar to the English-literate world and not Greek glyphs. The "english-literate" world (emphasis on literate) is, or historically has been, very familiar with Greek glyphs. And that's just for humanities. The mathematic and physics -literate world, doubly so. Everybody uses pi, theta, sigma (e.g. the summation formula)…

> The "english-literate" world (emphasis on literate) is, or historically has been, very familiar with Greek glyphs.

I would be shocked if even 1% of native English speakers could list the full Greek alphabet much less have a comprehensive familiarity with what each letter means across all branches of mathematics. I would be shocked if even 5% of native English speakers could tell you what theta generally means in geometry, much less all its other meanings.

Re: GCC 10.1 Released

#109
post #96

Earlier quoted context omitted.

> The implication is that we should use conventions (including potentially whole words) that are familiar to the English-literate world and not Greek glyphs. The "english-literate" world (emphasis on literate) is, or historically has been, very familiar with Greek glyphs. And that's just for humanities. The mathematic and physics -literate world, doubly so. Everybody uses pi, theta, sigma (e.g. the summation formula)…

> The "english-literate" world (emphasis on literate) is, or historically has been, very familiar with Greek glyphs. I would be shocked if even 1% of native English speakers could list the full Greek alphabet much less have a comprehensive familiarity with what each letter means across all branches of mathematics. I would be shocked if even 5% of native English speakers could tell you what theta generally means in ge…

Except for "full alphabet", all of that applies to the English alphabet as much as it does for the Greek alphabet. But both of you seem to disagree on what "literate", "very familiar" and "historically" really mean. Which is fine, language is not made to be precise - luckily we can use precise symbols where precise meaning matters, not English phrases. For example in math and physics.

Re: GCC 10.1 Released

#110
post #62

Earlier quoted context omitted.

Yep, writing non english keywords in C++ is like having prolog code inside c++ :-) (but as a non english person, I find it very helpful to be able to have unicode in strings)

that's fine, keep using english. But do not expect people that do not speak english to learn it if there's an alternative. Someday we might have multilingual frameworks and not restrict programming to the privileged few that could learn a second language. Entitled programers are so into their broculture they can't see their own problems as being socially constructed. On one hand they complain "reading mixed language…

I really disagree with the idea that math uses greek letters just to make things less accessible. If you have a better symbol than the large S for an integral, or Sigma for sums, I'd love to hear it.
Post reply on HN