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

Modern C++ Won't Save Us

alexgaynor.net

Post reply on HN
Print view View original

381–390 of 395 posts

Re: Modern C++ Won't Save Us

#381

Post by daemin »

geezerjay wrote: post #374
daemin wrote: post #276

Earlier quoted context omitted.

There's an argument to be made for having basic so-called leaf modules in the standard library. That is it makes it far simpler to get a basic installation of C++ and start doing cool things with it. Experienced developers or people that need domain specific features would be using their own specialised libraries anyway. So instead of trying to figure out which one of the dozens of GUI frameworks to use in making a w…

> So instead of trying to figure out which one of the dozens of GUI frameworks to use in making a window and have it change colour, you just write it using the standard library. Congrats, now you're stuck with something like Xwindows or MFC or AWT.

They're standard for the OS but not a standard for the programming language library.

Granted AWT wasn't great but you could still make a GUI with it straight out of the box. It allowed you to make windows and buttons and start exploring the programming language.

Like I said having a standard library option won't eliminate third party libraries, it will just provide something in the box for people to start using straight away.

Re: Modern C++ Won't Save Us

#382

Post by geezerjay »

pjmlp wrote: post #378
geezerjay wrote: post #374

Earlier quoted context omitted.

> So instead of trying to figure out which one of the dozens of GUI frameworks to use in making a window and have it change colour, you just write it using the standard library. Congrats, now you're stuck with something like Xwindows or MFC or AWT.

Which while not ideal, are guaranteed to be present, contrary to third party libs.

That assertion is disingenuous at best.

That guarantee is only achievable at the expense of forcing compiler developers to maintain a GUI toolkig for all platforms. Who in their right mind believes that's reasonable or desirable?

Re: Modern C++ Won't Save Us

#383

Post by steveklabnik »

ncmncm wrote: post #369
steveklabnik wrote: post #365

Earlier quoted context omitted.

The equivalent of Ranges is already in Rust’s standard library, and has been forever. We call it Iterator. It also provides extra static guarantees against invalidation.

I see that you did not understand my question. I see, too, that there are plans for some support for generics in the near future. So the answer might become yes, in time.

Rust has also had generics for a very long time.

Re: Modern C++ Won't Save Us

#384

Post by daemin »

geezerjay wrote: post #382
pjmlp wrote: post #378

Earlier quoted context omitted.

Which while not ideal, are guaranteed to be present, contrary to third party libs.

That assertion is disingenuous at best. That guarantee is only achievable at the expense of forcing compiler developers to maintain a GUI toolkig for all platforms. Who in their right mind believes that's reasonable or desirable?

So instead of a GUI library what about a HTTP or a network library as part of the standard? Surely handling TCP and UDP connections is an order of magnitude easier to implement and maintain.

Re: Modern C++ Won't Save Us

#385

Post by pjmlp »

geezerjay wrote: post #382
pjmlp wrote: post #378

Earlier quoted context omitted.

Which while not ideal, are guaranteed to be present, contrary to third party libs.

That assertion is disingenuous at best. That guarantee is only achievable at the expense of forcing compiler developers to maintain a GUI toolkig for all platforms. Who in their right mind believes that's reasonable or desirable?

Everyone that wants a language to thrive instead of dealing with thousand incompatible implementations.

Many C++ targets don't support IO or networking, so lets not burden embedded compiler developers with standard library bloat.

Re: Modern C++ Won't Save Us

#386

Post by dejaime »

mannykannot wrote: post #20
jclay wrote: post #14

I really don't get all the hate that C++ gets. The suggested alternatives in the article are Rust and Swift. What if you need to develop a cross platform GUI, that has a backend running a CUDA or OpenCL algorithm? For the former, you can use Qt, which isn't without it's warts, but is pretty tried and true in my experience (see KDE, VTK, etc). For the latter, you'll end up writing your CUDA code in C++ anyways. I gues…

I do not think it helps to think in emotional terms such as 'hate'. There is nothing wrong with discussing potential problems, and the current utility of the language should not stop us asking whether we could do better in future. FWIW, I use C++, not Rust or Swift, and I have a fair amount of knowledge and experience vested in it, but I think these questions are worth asking.

Saying that C++ won't "save" us is already pretty emotional and, put simply, wrong. We are not really facing imminent doom or anything that would justify that word, other than an overemotional point of view, biased by personal feelings.

Re: Modern C++ Won't Save Us

#387

Post by leetcrew »

int_19h wrote: post #350
mjevans wrote: post #65

Earlier quoted context omitted.

My opinion on that, is that such code MUST NOT be optimized away. Instead it should be a compile error.

Why should it be a compile error? The pointer may be null, but is not guaranteed to be. If you mean that C++ should require a null check before dereferencing any pointer that is not guaranteed to be non-null, then that would break most existing C++ code out there, so it's a non-starter.

in the particular situation they're talking about, you have a pointer to a struct, which you dereference by accessing one of its fields. the null check happens after the dereference, almost certainly a mistake.

Re: Modern C++ Won't Save Us

#388

Post by int_19h »

ncmncm wrote: post #370
int_19h wrote: post #353

Earlier quoted context omitted.

Can you give an example of said "key core language facilities" that make some library implementable in C++, but not Rust? I can give an example of the opposite: language-aware macros. No amount of C++ TMP hackery can approach a well-designed Rust DSL.

Rust macros understand types now? Woohoo!

Can you clarify what you mean by "understand types"? The only thing I can think of in this context is compile-time reflection - but that's not in C++, either (yet).

Ideally, can you give a concrete example of some abstraction that can be implemented in C++ with templates, but not in Rust with generics and/or macros?

Re: Modern C++ Won't Save Us

#389

Post by hu3 »

clouddrover wrote: post #345
hu3 wrote: post #315

Earlier quoted context omitted.

Don't assume I haven't read it. I read the book. Wrapping unsafe code behind an API doesn't make it go away. It's still unsafe and needs manual checking. Also wrapping code with hints and annotations of some sort is a thing in numerous PL. It's a given, not a feature and certainly not a bug as you wrongly implied I stated. TLDR: it's still unsafe as the book and others pointed out.

Then you're misrepresenting what the book is saying, which is worse than not having read it. As an argument your position makes no sense. You might as well be arguing that there's no point in programming languages because sometimes you have to write assembly.

Since you replied with a personal attack and added nothing to the discussion:

It's still unsafe and if you think otherwise either provide an argument that refutes me, the book and othets on this thread instead of blindly dismissing us as: you're reading it wrong.

Your very copy-pasted paragraph from the book stated that's still unsafe and it's left to the programmer to get it right.

Re: Modern C++ Won't Save Us

#390

Post by noselasd »

simias wrote: post #248
noselasd wrote: post #212

Earlier quoted context omitted.

Sure, but that's not the issue. You should be using a std::optional like e.g. if (my_optional) do_stuff(*my_optional); Here's one (explicit)conditional. However if the dereferencing, *my_optional, should be safe, it too would need to perform a conditional check behind the scenes. But it doesn't - as C++ places that on the programmers hand to not sacrifice speed

This is solved in Rust by letting you test and unwrap at the same time: if let Some(obj) = my_optional { do_stuff(obj); } >However if the dereferencing, my_optional, should be safe, it too would need to perform a conditional check behind the scenes. But it doesn't - as C++ places that on the programmers hand to not sacrifice speed So basically that turns C++ optional types into fancy linter hints which won't actually…

C++ gives you all the options as usual.

  do_stuff(my_optional.value())
Is also safe, it throws if the value is absent, the safety check is performed behind the scenes.

But people might not want to throw an exception, so

  if (my_optional) 
         do_stuff(*my_optional);
Must also be allowed. The consequence is someone can also just do

  do_stuff(*my_optional)
No safety check is done and you get undefined behavior if the value is absent.

I don't know rust so I suspect it has a language construct which c++ lacks that prevents you from doing

  let Some(obj) = my_optional 
  do_stuff(obj);
Post reply on HN