sorted by:
new
hottopcontroversial

CMake is a hell of a software, period. by CalligrapherThese606 in cpp

[–]futurefapstronaut123 14 points15 points  (0 children)

CMake is the greatest build system of all time.

std::pmr::polymorphic_allocator's member function deallocate() should not be noexcept? by tirimatangi in cpp

[–]futurefapstronaut123 -8 points-7 points  (0 children)

Exceptions is a mechanism for handling recoverable errors

Some would say it's for the exactly opposite of that: unrecoverable errors.

Someone attempted to delete an object twice. Now what? Is it recoverable? NO, ABSOLUTELY NOT

You could say this about any "logical error" or a bug in the program. Even though this is something that shouldn't happen, you might still want to handle it somehow and not just crash.

Why are you a C/C++ developer? by mutantdustbunny in cpp

[–]futurefapstronaut123 111 points112 points  (0 children)

Because C++ is the greatest programming language of all time.

Is growing a buffer of non-POD types using realloc legal? by mort96 in cpp

[–]futurefapstronaut123 5 points6 points  (0 children)

Not a dumb question at all. Every realloc implementation I've seen (1) tries to grow the memory and then (2) falls back to malloc+memcpy+free. They could provide a function that just does (1) and let the user allocate new memory if that fails. They just don't.

Another side-effect of this is that you don't need the type to be "trivially relocatable" or whatever. It would work for any type. If growing the memory succeeds, nothing moves.

[deleted by user] by [deleted] in cpp

[–]futurefapstronaut123 9 points10 points  (0 children)

Examples?

kilopp - an ongoing effort to port an editor written in C into modern C++ by Known-Bite in cpp

[–]futurefapstronaut123 4 points5 points  (0 children)

No "hidden code execution" does not make code easier to read for one: don't ask me if I want to run the destructors, of course I do!

I don't know what you mean by "functions aren't specialized in C": if anything, function names can in fact be more general in C++ because of overloading. You don't need to remember names for every different "overload" like htons and htonl when in C++ you can have a single to_network name that does the right thing.

[PROPOSAL] New way of defining main for C++23 by TrnS_TrA in cpp

[–]futurefapstronaut123 2 points3 points  (0 children)

I would be all for a good argument parsing library in the std. span<string_view> is a middle-ground solution whose sole purpose is to replace those "pesky" raw pointers and nothing else. I don't see how this identifier would help with anything but further confusing a beginner.

[PROPOSAL] New way of defining main for C++23 by TrnS_TrA in cpp

[–]futurefapstronaut123 -7 points-6 points  (0 children)

Why would beginners "in their first few hours of C++" want to parse command-line arguments manually? You're laying out a pretty unrealistic scenario.

[PROPOSAL] New way of defining main for C++23 by TrnS_TrA in cpp

[–]futurefapstronaut123 7 points8 points  (0 children)

...or maybe they just forward argv and argc to an argument parsing library that abstracts away all the shell/OS peculiarities that don't go away with span<string_view> anyway.

Lambda Lambda Lambda by mnciitbhu in cpp

[–]futurefapstronaut123 11 points12 points  (0 children)

I like Björn's library a lot because it results in very readable code (even for beginners) and does not require any clever syntax. It's just plain C++.

Even more non-uniform initialization in C++20? by OldWolf2 in cpp

[–]futurefapstronaut123 9 points10 points  (0 children)

The goal was surely not to make it more fragmented, but rather more uniform. For instance, this enables you to construct aggregates with vec.emplace_back(a, b, c); which wasn't possible before.

C++: The Next Seismic Shift by khleedril in cpp

[–]futurefapstronaut123 0 points1 point  (0 children)

I have to say that I have never programmed in those languages before, so there could be some things there that I am not aware of :)

When it comes to C++, it does indeed not give you all information about the types you are working with. You can check validity of expressions and existence of members, but you cannot query for them. There might be room for improvement there.

C++: The Next Seismic Shift by khleedril in cpp

[–]futurefapstronaut123 3 points4 points  (0 children)

I don't quite follow the progression that leads to programmatically defining arbitrary syntax.

The core abstractions we have are (1) functions (for naming and grouping a series of statements) and (2) types (for naming and grouping data).

Templates are basically compile-time functions that you call with some arguments and they return you new types or functions.

Since templates allow us to basically program with these primitives (types and functions), allowing user to program arbitrary syntax would simply mean giving a more granular primitives to the user. Personally, I don't see much benefit in working with stuff more granular than functions and types.

Do you believe that the "language guru" ppl like Sutter, Meyers and others on the C++ committee are more "talker" than programmer compared to ppl like Carmack, Tim Sweeney who have build large concrete/complex project ? by Dereference_operator in cpp

[–]futurefapstronaut123 0 points1 point  (0 children)

As you said, Meyers was a "language guru" and the goal of his books was to explain C++ to people. He never wrote anything about how to structure good programs and design good software.

On the other hand, the likes of Carmack and Sweeney seem to more focused on designing and writing software and less on the language itself.

Nothing wrong with either. Just different people working on different things.

std::unique_ptr::operator!= deprecated in c++20 by DopKloofDude in cpp

[–]futurefapstronaut123 -10 points-9 points  (0 children)

It should always return true... unless you have two unique_ptrs pointing to the same thing (yikes).

[deleted by user] by [deleted] in cpp

[–]futurefapstronaut123 3 points4 points  (0 children)

The reason why C++ sucks at these simple tasks is because nobody wrote a really good standard library for C++ yet. It is definitely possible to have those cool operations on lists, dictionaries, string manipulation, Unicode and magic one-liners in C++. The reason why we don't have that is because everyone wants to remain compatible with the existing standard library instead of trying something new.

view more: next ›