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

GCC 10.1 Released

gcc.gnu.org

Post reply on HN
Print view View original

131–140 of 145 posts

Re: GCC 10.1 Released

#131

Post by canarypilot »

FullyFunctional wrote: post #111

memory.c: In function ‘mk_entry’: memory.c:116:12: internal compiler error: in saved_diagnostic, at analyzer/diagnostic-manager.cc:84 116 | return (struct entry) {safe_calloc(end - start, 1), start, end}; | ^ Please submit a full bug report, Goes to look at README.Bugs. Holy cow, I don't have time to to check all those places to see if it has been reported already.

The GCC community is normally very good (if blunt) at picking up duplicate bugs and linking them to the right place. https://gcc.gnu.org/bugzilla/ Is all you need. Just don’t feel bad if your bug is closed!

Re: GCC 10.1 Released

#132

Post by fnord123 »

MaxBarraclough wrote: post #68
fnord123 wrote: post #51

Earlier quoted context omitted.

eh, no. the OS package manager is for sysadmins. LTS is for sysadmins to not have to worry about versions changing under their feet rapidly when they apply security updates. If you want to develop an application, you use your own toolchain. But yes I know most C++ people don't d this because C++ tools don't easily support it. But that's on C++ for not having pyenv, rustup, multiruby, etc equivalent.

C++ lets you statically link the standard library though, right? Or am I missing your point?

Yes, but I'm quite sure GP is talking about using LTS so the installed libraries are the same as you built with.

IIRC there's still an issue with gethostname which must be dynamically linked.

Re: GCC 10.1 Released

#133

Post by e12e »

purerandomness wrote: post #42
e12e wrote: post #28

Earlier quoted context omitted.

Well, you might want to run a newer/non-lts release via lxd/lxc. It's probably a much better idea than pulling in willy-nilly ppa's.

But at this point, why not simply run Arch Linux?

I'm not sure I understand. You want a stable host system without the need for forced, sometimes breaking, upgrades - so an lts release "on the outside".

You want to develop with new tooling, so a newer release under lxd/lxc. But you probably want to deploy on an lts release - maybe the one comming in a year?

You could of course develop under arch in lxd/lxc - then validate for an lts release once your code is "done".

But I don't think you'd generally would want to deploy to arch - as you'd have to play catch-up in order to keep up with security patches (or backport yourself)?

Re: GCC 10.1 Released

#134

Post by slavik81 »

gumby wrote: post #130
staticassertion wrote: post #127

Earlier quoted context omitted.

It would be cool if more papers had a glossary for the symbols they use, though. If you're going to use a bunch of single character symbols, at least put somewhere what they are.

The abstract and introduction to a math paper usually does so, though sometimes they slip up and in then in the middle of the paper you find some strange symbol and have to manually binary search for it.

I wish I could click on a symbol in an equation and have it either pop up a full name / definition for standard symbols, or scroll to where the variable was defined for paper-specific symbols.

When studying papers, I spend way too much time trying to answer questions like, "what was 'n' again?"

Re: GCC 10.1 Released

#135

Post by gumby »

slavik81 wrote: post #134
gumby wrote: post #130

Earlier quoted context omitted.

The abstract and introduction to a math paper usually does so, though sometimes they slip up and in then in the middle of the paper you find some strange symbol and have to manually binary search for it.

I wish I could click on a symbol in an equation and have it either pop up a full name / definition for standard symbols, or scroll to where the variable was defined for paper-specific symbols. When studying papers, I spend way too much time trying to answer questions like, "what was 'n' again?"

I usually write notes as I read anyway — not just marginalia but typically on the back of the first page or in my notebook. Back of the first page is an excellent place for things like that.

Re: GCC 10.1 Released

#136

Post by alufers »

q92z8oeif wrote: post #107
wiz21c wrote: 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…

> Someday we might have multilingual frameworks and not restrict programming to the privileged few that could learn a second language.

I seriously doubt it, English is really easy to learn (sure the pronunciation is weird, but who needs it when you are writing code), and by learning English you can understand all the code with identifiers in English, written not only by native-speakers. Additionally, I wouldn't want a person who couldn't be bothered to learn a natural language to be a programmer in my company (if it was based in a non-English speaking country, of course).

> "reading mixed language code is hard, despite me being fluent on both! everyone should speak what is more convenient to me!" > leaving billions of people that do not know english out.

How is writing bilingual code including more people? You are limiting the total amount of people who speak English to the subset of people who know both the language.

Re: GCC 10.1 Released

#137

Post by jfkebwjsbx »

Rusky wrote: post #106
jfkebwjsbx wrote: post #102

Earlier quoted context omitted.

> 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.

I am not saying you cannot write code without them, but that you cannot do away with them without losing what they bring.

Re: GCC 10.1 Released

#138

Post by shaklee3 »

cormacrelf wrote: post #53
verdagon wrote: post #36

Earlier quoted context omitted.

Can you explain why multiple mutable pointers is bad practice? I understand the benefits and the risks of them, and understand how Rust prevents both, but I dont yet understand why it's bad practice, and am interested to learn why.

The one that affects you as a programmer most is Iterator invalidation. Iter borrows from the vector, you mutate the vector, iter blows up. Simple really. But a lot of code is like this. Borrow from hashmap, insert into hashmap, the slot gets moved around and your pointer is now invalid. That’s just vectors and hashmaps; imagine the possibilities in a much more complex data structure. There are compiler optimisations…

I feel like this is something common c++ developers know, and it's not worth all the baggage to tag it. You just control the iterator inside the loop instead of in the loop declaration.

Re: GCC 10.1 Released

#139

Post by verdagon »

cormacrelf wrote: post #53
verdagon wrote: post #36

Earlier quoted context omitted.

Can you explain why multiple mutable pointers is bad practice? I understand the benefits and the risks of them, and understand how Rust prevents both, but I dont yet understand why it's bad practice, and am interested to learn why.

The one that affects you as a programmer most is Iterator invalidation. Iter borrows from the vector, you mutate the vector, iter blows up. Simple really. But a lot of code is like this. Borrow from hashmap, insert into hashmap, the slot gets moved around and your pointer is now invalid. That’s just vectors and hashmaps; imagine the possibilities in a much more complex data structure. There are compiler optimisations…

Is this still bad practice if the container can detect when this happens, like Java's? Not saying that it always has to throw like Java, I could imagine implementing a weak iter which we'd check before each operation.

Re: GCC 10.1 Released

#140

Post by verdagon »

pkolaczk wrote: post #49
verdagon wrote: post #36

Earlier quoted context omitted.

Can you explain why multiple mutable pointers is bad practice? I understand the benefits and the risks of them, and understand how Rust prevents both, but I dont yet understand why it's bad practice, and am interested to learn why.

Because it leads to hard to understand code. If N unrelated (or loosely related) things can mutate the same object, then you get a O(x^N) explosion of potential mutation orders and in order to understand that, you need to understand all the (sometimes complex) time-relationships between these N objects. This gets even much worse when some of these objects are also pointed from M other objects... On the flip side, in…

Dont we in Rust still conceptually modify the vector multiple times, just through different means (usually a generational index or something)?
Post reply on HN