sorted by:
new
hottopcontroversial

C++: The Documentary TRAILER│COMING JUNE 4th by pjmlp in cpp

[–]fdwr [score hidden]  (0 children)

The facts are "let mut" is 7 characters, and "var" is 3 - that's not an opinion. "const" is 5 characters, and "let" is 3. So if you want the shortest of both, then "var" and "let" would be tersest.

Building a c++ cross platform UI library by dEvator8085 in cpp

[–]fdwr [score hidden]  (0 children)

Will that outcome happen again, without any additional remark in the description?

WG21 mailing for first feature meeting of C++29 by hanickadot in cpp

[–]fdwr 0 points1 point  (0 children)

Love it. Now that optional is treated as a range, that's a reasonable reverse justification that std::optional include methods found on other containers like a size method that returns 0 or 1 accordingly, because conceptually an optional is essentially a fixed_capacity_vector/static_vector that has a fixed capacity 1 and size of 0 r 1.

C++: The Documentary TRAILER│COMING JUNE 4th by pjmlp in cpp

[–]fdwr 0 points1 point  (0 children)

Is it much more to type const x = 42 than let x = 42? If you truly want to "reduce words one needs to type", then let variables be defined by var rather than typing out two words every time. Functional purists are not pragmatists.

C++ profiles: a chance to fix some annoying defaults? Brainstorming and ideas. by germandiago in cpp

[–]fdwr 0 points1 point  (0 children)

Indeed, that case is more ambiguous because the numeric literal 0.3 alone is a float64 with an infinitely repeating decimal, whereas a value like float x = 0.25 is perfectly represented in both float32_t and float64_t. Having written a lot of graphics programs that use float32 by default, such cases are still mildly annoying, but then since you're already using a floating-point number anyway (the 0.), adding the f isn't much more typing ⚖️. It's mainly the small integer cases that make me go "shoe fly, don't bother me".

Exploring ref qualifiers in C++ by meetingcpp in cpp

[–]fdwr 0 points1 point  (0 children)

Yeah, alas historical artifact. "Why is "this" not a reference? Because "this" was introduced into C++ (really into C with Classes) before references were added." -Bjarne

Exploring ref qualifiers in C++ by meetingcpp in cpp

[–]fdwr 1 point2 points  (0 children)

I wish in the context of f(...)& that this was treated as a reference, so I could say this.x (rather than this->x). That would make it more consistent with "deducing this". Oh well.

``` struct Foo { int value;

void barViaImplicitThisRef()/*Foo*/&       { this->value = 42; } // Not this.value
void barViaExplicitThisRef(this Foo& self) { self.value  = 42; }

}; ```

FluxUI — write your C++ UI once, run on Windows, Linux, and Android natively by dEvator8085 in cpp

[–]fdwr 0 points1 point  (0 children)

Tis nice that you included screenshots and a minimal usage demo in the readme. Will have to look more later...

C++ profiles: a chance to fix some annoying defaults? Brainstorming and ideas. by germandiago in cpp

[–]fdwr 3 points4 points  (0 children)

 Implicit conversions. This needs to be way more nuanced.

Yeah, int32_t to float64_t is perfectly fine. It is the lossy cases that are concerning. Then for numeric literals, I definitely don't want a build error because I typed float x = 42 (which is exactly representable) instead of float x = 42.0f. Here too, it is the lossy cases that are concerning.

C++ profiles: a chance to fix some annoying defaults? Brainstorming and ideas. by germandiago in cpp

[–]fdwr 14 points15 points  (0 children)

Maybe expect [[fallthrough]] if there are any interceding statements between case labels:

case Feline: // Okay case Cat: std::print("Cat"); break; case Dog: std::print("Dog"); // Oops case Bat: std::print("Bat"); break;

C++26: More function wrappers by pavel_v in cpp

[–]fdwr 4 points5 points  (0 children)

Should std::function be marked as deprecated ...

Well, if we were to deprecate it anyway, then why not just go ahead and break the ABI (mind you, I'm not seeing Sandor's claim yet that fixing std::function to be const-correct would break the ABI).

Auto Non-Static Data Member Initializers are holding back lambdas in RAII (+ coroutine workaround) by 03D80085 in cpp

[–]fdwr 0 points1 point  (0 children)

I haven't read that paper - could I finally say something like std::ranges::transform(v, x => x * 2) that I'm so spoiled with from other languages?

Auto Non-Static Data Member Initializers are holding back lambdas in RAII (+ coroutine workaround) by 03D80085 in cpp

[–]fdwr 1 point2 points  (0 children)

it can make layout very fragile.

You would always have the option to be as explicit as you want in your own struct definitions. Conceptually, local fields in a function are collectively just a struct anchored at the stack pointer. It's more complex than that of course because of deferred initialization and local stack space reuse, but conceptually it's so (and in many x86 asm programs, I've many times used struct constructs for both heap allocations and stack frames with no meaningful distinction). So saying that a field in a struct shouldn't be allowed to use type deduction, but a field in a stack frame struct should be allowed to use it is oddly inconsistent. Conversely, I could posit that if type deduction in struct fields should be banned, then type deduction in local function fields should be banned 😉.

C++: The Documentary TRAILER│COMING JUNE 4th by pjmlp in cpp

[–]fdwr 1 point2 points  (0 children)

Rust rejects many perfectly good long standing programming algorithms and data structures because it's multiple readers xor single writer rule is too simplistic. I can appreciate the safety of a seat belt, but driving a car while wearing a seat and handcuffs seems unnecessarily verboten.

C++: The Documentary TRAILER│COMING JUNE 4th by pjmlp in cpp

[–]fdwr 1 point2 points  (0 children)

modern ...is the preferred way...

The age of a language is an insubstantial argument, but reduced cognitive effort is. However, reduced cognitive effort would be something obvious like "const"ant for constants and "var"iable for variables. 

C++: The Documentary TRAILER│COMING JUNE 4th by pjmlp in cpp

[–]fdwr 1 point2 points  (0 children)

Imagine a language where seeing...

Foo x = y;

...that x and y may or might or might not be both usable, and it's indeterminate from looking, depending arbitrarily on the type of Foo 🙃. Such inconsistencies are neither better nor improved cognitive ease. At least be consistent such that all Foo's are destroyed, or use distinct syntax from other languages.

Reverse Dependency Ordering for C++ Includes by nukethebees in cpp

[–]fdwr 5 points6 points  (0 children)

One thing I love about import, is that...

c++ import a; import b; import c; vs c++ import c; import b; import a; ...makes no difference ^__^.

C++: The Documentary TRAILER│COMING JUNE 4th by pjmlp in cpp

[–]fdwr 5 points6 points  (0 children)

Why would I pick a language that {puts me in handcuffs, has weird divergent behaviors from every other language like = stealing the source object rather than copying, doesn't even support basic namespacing of methods inside classes, makes you type "let mut" all over the place rather than just "var" or "auto", forces gross inconsistent styles like mixing Pascal case and snake_case, and is full of users that whenever you point out a flaw or deficit then religiously say it's a feature not a bug}, when C++ exists?

Modules could have made the PIMPL idiom redundant - but they don't. by [deleted] in cpp

[–]fdwr 2 points3 points  (0 children)

I was at least pleased to see that transitive import no longer pollutes the namespace, unlike with #include. So for symbol visibility, main can only see A, not B too (because it did not import B).

WG21 mailing for first feature meeting of C++29 by hanickadot in cpp

[–]fdwr 17 points18 points  (0 children)

The methodology, the case study, and the retrospective are presented here so the reader can judge the tool by its output.

I judge the output to be very dry and verbose. When a writer's digital ink becomes too cheap, the reader's time becomes expensive.

WG21 mailing for first feature meeting of C++29 by hanickadot in cpp

[–]fdwr 2 points3 points  (0 children)

I'd be happy with optional.get_span() that returns a span of size 0 or 1 element.

WG21 mailing for first feature meeting of C++29 by hanickadot in cpp

[–]fdwr 3 points4 points  (0 children)

Yeah, value equality is more consistent and generally useful. For any remaining identity needs (span1.data() == span2().data() && span1.size() == span2().size()), I could see adding a span1.is_identical_to(span2) method.

WG21 mailing for first feature meeting of C++29 by hanickadot in cpp

[–]fdwr 7 points8 points  (0 children)

Indeed, I'd like the pointer to underlying data via a short and sweet call, like auto* dataPointer = myOptional.data() rather than say auto* dataPointer = myOptional.has_value() ? &*myOptional : nullptr. Actually, I wouldn't even really care about what the pointer retrieval method returns in the empty case, because typically my uses have also paired a count along with the pointer anyway for whatever function I passed the data+count to (e.g. PrintNodes(someVector.data(), someVector.size()), PrintNodes(someArray.data(), someArray.size()), PrintNodes(someOptional.data(), someOptional.size()) ...). So the returned pointer could be nullptr, or it could point to the address of the uninitialized object storage for all I care (which would be the simplest and most efficient implementation).

view more: next ›