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

Wrapping Up 2021. Leaving C++

izzys.casa

Post reply on HN
Print view View original

221–230 of 251 posts

Re: Wrapping Up 2021. Leaving C++

#221

Post by exitcode0 »

ncmncm wrote: post #207
exitcode0 wrote: post #18

You will always be welcome in the Ada++ community : ) http://www.adapplang.com/

I got as far into the tutorial as "Ada++ requires variable declarations to be made in a specific area called the declarative part", said "that's stupid" (actually out loud), and abandoned it. Then wrote this. (You're welcome.) Even C ditched its separate section for variable declarations.

The advantage of declare blocks would be the structure they provide - both in terms of understanding how much memory usage a subprogram can have in branching scenarios, but also as a way of showing the programmer possible areas where the problem might be better broken up into smaller pieces.

Note that within these declare blocks you may also declare new types and further subprograms - something which cannot be done within the body of a C function. Imagine the possibilities there : )

Re: Wrapping Up 2021. Leaving C++

#222

Post by pyjarrett »

ncmncm wrote: post #207
exitcode0 wrote: post #18

You will always be welcome in the Ada++ community : ) http://www.adapplang.com/

I got as far into the tutorial as "Ada++ requires variable declarations to be made in a specific area called the declarative part", said "that's stupid" (actually out loud), and abandoned it. Then wrote this. (You're welcome.) Even C ditched its separate section for variable declarations.

I understand how it can be frustrating, but it can also be super helpful.

I'm not super familiar with Ada++, but in Ada all declaration areas are the same. You can declare anything (types, functions, variables, tasks i.e. threads, or even full packages) in any declaration area. This is actually somewhat powerful in being able to write everything locally and then refactor it out to where it belongs.

Writing tasks in declarations is interesting because they operate like C++ jthreads, so the related block of statements won't exit until all threads complete. You can get around this by detaching work by using allocators, but that's more advanced.

Re: Wrapping Up 2021. Leaving C++

#224

Post by rurban »

flohofwoe wrote: post #173
rurban wrote: post #166

Earlier quoted context omitted.

WG 14 is C, WG 21 is C++. You are probably aware of the pace of evolution in the C language. Nothing happens, and if it's a horror show. The maximally take the easiest thing from C++, but usually the worst.

On the other hand, the advantage of the glacial pace of change in the C standard is that the language hasn't been ruined yet. One of the most important tasks of the committee should be to say "no", even if that's not a popular thing to do. The right place for experiments in the C ecosystem is outside the standard, in libraries and language extensions.

They should have said no to Unicode identifiers with C11. They have now a big security mess.

They should have adopted u8 instead if wchar.

Re: Wrapping Up 2021. Leaving C++

#225

Post by einpoklum »

nyanpasu64 wrote: post #220
einpoklum wrote: post #58

> I have ... extremely high standards for everything ... it causes me extreme distress ... to have to deal with things that are less efficient ... That's somewhat of a curse when it comes to (most) software engineering, but doubly so for languages like C++ which: 1. Have many decades of baggage (40 + C's baggage from before). 2. Have backwards compatibility and non-breakage as one of their goals. 3. Are not designed…

I agree with the comment, other than that the author is (approximately) a woman, and it's incorrect to refer using "he".

Hmm... ok, but I couldn't tell from the article, and the website's name is "izzy", which I mistook for a male name. I can no longer edit my answer though.

Re: Wrapping Up 2021. Leaving C++

#226

Post by einpoklum »

smitty1e wrote: post #12
einpoklum wrote: post #9

Earlier quoted context omitted.

Sure we will. Just like we switched to C++ 2.0 aka Java.

I keep waiting for the announcement that some propeller-head has implement the Rust borrow checker as a template metaprogram, with the caveat that nothing larger than "Hello, world." compiles within a month.

C++ has gone down a different path, and reasonable one if I can say so myself.

Bjarne Stroupstrup said:

> I don't like garbage. I don't like littering. My ideal is to eliminate the need for a garbage collector by not producing any garbage. That is now possible.

And indeed, with modern C++ idioms you can avoid leaks at the static analysis level, avoid buffer overflows by simply not passing raw pointers around, etc. So no borrow checker / garbage collector necessary. For a little more elaboration on this point, see:

https://stackoverflow.com/a/48046118/1593077

Is it 100% bullet-proof? No, but then, Rust needs some unsafe parts too.

Re: Wrapping Up 2021. Leaving C++

#228

Post by chakkepolja »

zozbot234 wrote: post #135

> A lack of default arguments, a lack of basic arity overloading, a lack of variadic generics, all make me not want to write Rust. I'm not sure how serious this is, TBH? I mean, Rust does have macro syntax that supports all of these things (as seen e.g. in println!() and format!() ), and there are pretty solid engineering reasons to avoid those features within the basic workings of the language. I'm pretty sure most…

Out of everything about rust those are weird reasons to nitpick about.

Re: Wrapping Up 2021. Leaving C++

#230

Post by Const-me »

Jyaif wrote: post #16
einpoklum wrote: post #9

Earlier quoted context omitted.

Sure we will. Just like we switched to C++ 2.0 aka Java.

Out of curiosity, according to you at what point was Java considered C++ 2.0?

I agree with GP. When I started my career in 2000, people used C or C++ for pretty much everything. People wrote desktop GUI apps with MFC. People built web apps with cgi-bin, ISAPI, and C++ implemented COM objects consumed from asp classic. The only way to build mobile and embedded was C or C++ (PalmOS, Windows CE, later Symbian).

Eventually, some of that stuff was rewritten in languages like Java, C#, PHP, JavaScript, TypeScript. Other stuff was re-implemented for new platforms using Objective-C, or Google’s version of Java, or C# in Windows Phone/Unity/Xamarin.

Post reply on HN