profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/akrzemi1/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

akrzemi1/Optional 299

optional (nullable) objects for C++14

akrzemi1/explicit 183

A set of small tools that allow you to state your intentions mre explicitly in the code

akrzemi1/markable 67

A template for creating optional-like objects with no space overhead

akrzemi1/compact_optional 23

A template for creating optional-like object with no space overhead

akrzemi1/out_param 4

A template for declaring function's output parameters

akrzemi1/concepts-ts 2

Technical Specification: Concepts

akrzemi1/Beast 1

HTTP and WebSocket built on Boost.Asio in C++11

akrzemi1/boost 1

Super-project for modularized Boost

akrzemi1/contract 1

A paper on contract programming in C++

issue openedatomgalaxy/wg21-abort-only-contract-support

Clarify "Other options"

Incorporate feedback from Thomas Koeppe. Are we not confusing "function parameters" with "function arguments"?

created time in 3 hours

issue openedatomgalaxy/wg21-abort-only-contract-support

Ignore -> No_eval

  1. Rename mode Ignore to No_eval.
  2. Determine if the note on ODR-usage should be made not a note.

created time in 9 hours

push eventatomgalaxy/wg21-abort-only-contract-support

Andrzej Krzemienski

commit sha 48256e3fe377da109b19691182887c5deb25132e

HTML: interaction with std::unreachable()

view details

push time in 14 days

push eventatomgalaxy/wg21-abort-only-contract-support

Andrzej Krzemienski

commit sha 462e776055eb6bd8bbc3ab531d6552af60b7572b

HTML: more on args in postconds, and a feature-test macro

view details

push time in 14 days

push eventatomgalaxy/wg21-abort-only-contract-support

Andrzej Krzemienski

commit sha e38640290b18873e79e510a6f14775745bd49f4c

HTML: more discussion in {rat.arg}

view details

push time in 17 days

push eventatomgalaxy/wg21-abort-only-contract-support

Andrzej Krzemienski

commit sha 0d5293e869c25405c70f5a741a19a75e6c27cea7

HTML: fixed Revisions sect

view details

push time in 17 days

push eventatomgalaxy/wg21-abort-only-contract-support

Andrzej Krzemienski

commit sha 69ab5c9d8fbf9ceea2619374d062645a16a42c93

Feedback from Henry Miller

view details

push time in 17 days

push eventatomgalaxy/wg21-abort-only-contract-support

Andrzej Krzemieński

commit sha b8962003321efeab9e3cb682dbe542297b4d257c

Fix formatting bug added in 6e64d13

view details

push time in 18 days

issue commentboostorg/optional

implicit constructor not working

Is optional<optional<T>> really a problem in practice?

When optional<optional<T>> appears in your program, you cannot easily see it, because the declaration is spilled across two places:


template <typename T>
void genericFun(const T& v)
{
  optional<T> optV = v;
  assert(bool(optV)); // wil it pass for *every* T?
}

optional<int> myValue;
genericFun(myValue);

But in this case we are not getting better functionality

The definition of "better" is not clear here. With boost::optional you get the subset of std::optional functionality that is known to have no gotchas. The interface is narrower, but is guaranteed to always (as opposed to 95% of the cases) do what you expect.

we are getting something that interoperates with other boost types poorly

Can you provide an example of how boost::optional interoperates with other boost types poorly?

For example: [...]

I can see how this is problematic. Is this the only use case that really shows up in practice? Because this one could be addressed in a different way. I will investigate if enabling U -> optional<T> doesn't introduce any gotchas (because the most prominent gotchas are introduced by other conversion optional<U> -> optional<T>).

I think there is benefit to enabling practical usage even if it comes at the expense of some esoteric theoretical use-cases.

The way I see it, we are talking here about the trade-off where you get a convenience feature that does what you expect in 95% of the cases, and in the remaining 5% cases it compiles and does something opposite to what you expect at runtime. This doesn't sound like the right trade-off for me. But I might be wrong about the "does something opposite to what you expect", so, as I said, I will investigate this.

vinniefalco

comment created time in 21 days

issue commentboostorg/optional

implicit constructor not working

Yes, you're right: the gotcha is not directly related to the design decision. Sorry. So, let me rephrase my response.
Making the constructor of boost::optional<T> from U explicit is a conscious decision, based on the premise that adding too much implicit conversions is potentially bug prone. While std::optional comes with far more implicit conversions, it is not clear if it is a superior design. std::optional has a number of gotchas that boost::optional doesn't that are caused by implicit conversions (albeit not by the one in question, but mainly from optional<U> to optional<T>). One such gotcha is when you convert from optional<X> to optional<optional<X>>: it can be handled by either T -> optional<T> or optional<U> -> optional<T> and an arbitrary choice is made, likely not the one that the user may intuitively expect. Therefore aiming at 100% compatibility with std::optional interface does not seem to be a reasonable goal for boost::optional.

vinniefalco

comment created time in 21 days

issue commentboostorg/optional

implicit constructor not working

This is by design. The constructor of boost::optional<T> from U is declared explicit. And I believe this decision is better than the one taken for std::optional. It avoids gotchas like this one: https://twitter.com/berglerma/status/1338918610652319745.

vinniefalco

comment created time in 22 days

CommitCommentEvent
CommitCommentEvent

push eventatomgalaxy/wg21-abort-only-contract-support

Andrzej Krzemienski

commit sha 05f7e8e7039e705e776272f8d1a06b30bbbbc883

HTML: described virtual functions

view details

push time in a month

push eventatomgalaxy/wg21-abort-only-contract-support

Andrzej Krzemienski

commit sha b564f94dc951d11350afd948d2e45123d5a34be5

HTML: discuss fun ptr, oldof, and arg copies Discuss how we treat funciton pointers Discus how in the future we may want to capture the state of the program on function entry Discuss another option for postconditions: doing copies of non-ref arguments.

view details

push time in a month

push eventatomgalaxy/wg21-abort-only-contract-support

Andrzej Krzemieński

commit sha 7417b20a257b584a6e4ddb2cfd9e96dd6a84262f

HTML: changed initial example Changed `pre` to `assert` in order not to divert the reader attention to name lookup issues and whether the precondition is called outside or inside the fun.

view details

push time in 2 months

issue commentboostorg/optional

Move in_place and in_place_t into individual headers?

Might I recommend having a look at https://github.com/akrzemi1/markable/tree/develop ? This may not be suitable for your use case, because it takes one of the values of T for representing a missing value, but it is smaller and can produce faster comparison/hash, because it requires no branches.

vinniefalco

comment created time in 2 months

push eventatomgalaxy/wg21-abort-only-contract-support

Andrzej Krzemieński

commit sha 022e680a5d0f0a6a2284ac54206c49ee88c0c166

HTML: clarify that postconds may add overhead

view details

push time in 2 months

push eventatomgalaxy/wg21-abort-only-contract-support

Andrzej Krzemieński

commit sha c0e1f0caebbf7c896cc2e9eee427afa1761e8d2f

HTML: described double precond impl

view details

push time in 2 months

push eventatomgalaxy/wg21-abort-only-contract-support

Andrzej Krzemieński

commit sha 93bab44d68c79ed90e15b41133c8e31137ef004f

HTML: clarified future compatibility

view details

push time in 2 months

push eventatomgalaxy/wg21-abort-only-contract-support

Andrzej Krzemieński

commit sha 0800c3d9aca13a0a79798fbd8e97eeeff7a0f9fb

HTML: add section {mot.too} This describes why an MVP is better if it doesn't address your use cases.

view details

push time in 2 months

issue commentboostorg/optional

Move in_place and in_place_t into individual headers?

Just to clarify, names boost::in_place and boost::in_place_t are already taken in Boost and denote "in-place factories" which was a pre-C++11 approach to perfect forwarding. They are already a separate utility library: https://www.boost.org/doc/libs/1_76_0/libs/utility/in_place_factories.html .

Boost.Optional makes use of them, but at the same time, in order to preserve maximum reasonable compatibility with std::optional it provides its own "tag" type: boost::in_place_init_t and a value boost::in_place_init.

Is the request about boost::in_place_init_t?

vinniefalco

comment created time in 2 months

push eventatomgalaxy/wg21-abort-only-contract-support

Andrzej Krzemieński

commit sha 9960645a30e404c060d8672aff0f1c44393ad902

HTML: fixed test sequencing in wording

view details

push time in 2 months

push eventatomgalaxy/wg21-abort-only-contract-support

Andrzej Krzemieński

commit sha d623c0cc63223363f029add5374303a677a09b69

HTML: improve discussion of side effects

view details

push time in 2 months

push eventatomgalaxy/wg21-abort-only-contract-support

Andrzej Krzemieński

commit sha 4b35340e4ff3fd3c5dc31e44401c9f46916f9457

HTML: UB when modifying args or return val

view details

push time in 2 months

push eventatomgalaxy/wg21-abort-only-contract-support

Andrzej Krzemieński

commit sha a2da4eea9c4e21f8ac27c8abc0f7a9043ff53fa9

HTML: fix wording for allowed side-effect elisions

view details

push time in 2 months

CommitCommentEvent