Hacker News Reader

C++ may get pattern matching with P1371, which may make visiting look more reasonable:

    std::string_view print_type(const variant_type& jtt) {
        using namespace std::literals;
        return inpect (jtt) {
            <double> __ => "Number"sv;
            <bool> __ => "Bool"sv;
            ...
        };
    }

In any case, `std::variant` should have been a language feature all along, instead of a library one; cf. Rust:

    enum Value {
        Number(f64),
        Bool(bool),
        ...
    }

    fn print_type(v: &Value) -> &str {
        match v {
            Value::Number(_) => "Number",
            Value::Bool(_) => "Bool",
            ...
        }
    }

Yes, pattern-matching like this would be the bee's knees

Since you're interested in readability, you may also like std::format:

    std::string format_parse_error(std::string base, JSONToken token) {
       std::ostringstream s;
       s << "Unexpected token '" << token.value << "', type '"
         << JSONTokenType_to_string(token.type) << "', index ";
       s << std::endl << base;
      return format_error(s.str(), *token.full_source, token.location);
    }

becomes

    std::string format_parse_error(std::string_view base, JSONToken token) {
      return format_error(
       std::format(
           "Unexpected token '{}', type '{}', index '{}'\n{}"
         , token.value
         , JSONTokenType_to_string(token.type)
         , index
         , base)
       , *token.full_source
       , token.location
      );
    }

I was excited to use it! But I don't think it's available in Clang 12 (noted in this post) which is the latest version that comes with latest Fedora.

I didn't want to have to spring a newer compiler version than came with the distro.

Unless it's just a flag I did not turn on.

You can install it. dnf install fmt-devel

If you really cared about readability

, you'd put your commas where normal human beings put them

. Instead of in a silly place like that

. Prefering structure over normal communication is not

, typically

, seen as a good thing

.

That is the (or at the very least a) normal place to put them in C++. Human beings use things differently in different contexts.

I've been a professional C++ programmer for 24 years now, and neither I, nor anyone I've worked with over this period, used this ridiculous style.

I've used it on larger teams where some enums for feature flags end up getting conflicts all the damn time when you add to the end because the last entry doesn't have a comma.

This might be fixed in various languages/parsers by allowing a trailing comma (e.g. python).

At the end of the day, clang-tidy, black, gofmt, rustfmt all the things and let's never talk about comma placement again.

What if C++ actually allowed that comma? Because... it does.

not everywhere, I often have a need for it in template arguments for instance for type lists:

    std::conditional<
     some_property<
       T, 
       U,
     >,
     int, 
     float,
    >;

is a compile error, I really prefer

    std::conditional<
       some_property<
           T 
         , U
       >
     , int
     , float
    >;

That's only from C++11. The story I was telling you was from before then.

    $ cat test.cc 
    enum Foo {
     FOO,
     BAR,
    };
    int main(int argc, char** argv) { return 0; }

    $ g++ -std=c++98 -Wpedantic test.cc
    test.cc:3:5: warning: comma at end of enumerator list [-Wpedantic]
        3 |  BAR,
          |    

    $ g++ -std=c++03 -Wpedantic test.cc
    test.cc:3:5: warning: comma at end of enumerator list [-Wpedantic]
        3 |  BAR,
          |     ^

    $ g++ -std=c++11 -Wpedantic test.cc

It’s a Haskell thing, and while I don’t use it in any other language, it does look very neat and readable in Haskell.

I thought it was an SQL thing.

It's because it's actually used in a lot of places because it makes sense

How many code bases have you actually worked on? I can tell you it's very common in constructor initializer-lists to the point that both the mozilla and webkit styles of clang-format does it.

https://stackoverflow.com/questions/10483635/why-do-lots-of-...

it just removes a lot of hassle when you are used to it, I'd never go back to trailing commas

Trailing commas work just fine when the langage supports, well, trailing commas.

Having them aligned looks much better when you're used to it

Anything seems better once you're used to it, even "not having toes".

well no, because I was used to trailing commas but this was creating more friction and was overall less pleasurable, that's why I switched to leading commas where it feels like an improvement

Prefix separators are an excellent way to avoid diff noise in langages without terminators (/ trailing comma support).

This is silly for several reasons that I will list: *

Programming is not prose, so we can temper our expectations. *

Even in prose, some symbols belong on the left, and some belong on the right. *

The example given is no less readable than the alternative. *

It's more important to be consistent in style than correct to one person's opinion e.g. some people still batch edit source via macros and appreciate when curly braces are not in unexpected places.

Happen very often in SQL codes :(

I do get that it's the type-safe approach but your resulting code looks more complicated than what I did (to me).

Still, thanks for sharing so that other people can see for themselves.

One of the biggest turnoffs about std::variant to me (which isn't relevant here) is that you can't name the types so the hacks for having multiple of the same type in std::variant look even hairier.

A nice follow up would also be looking at std::string_view as this has the potential to save a lot of memory.

Since I'm unfamiliar with the underlying concept, could you give an example of how you could see that being used?

`std::string_view` is essentially something like this:

   struct string_view {
      char *data;
      size_t length;
   }

It is a pointer to a subset of an existing string. It has all of the existing features of `std::string` but passing it around is zero copy. As long as the original memory allocation exists your `string_view`s are still valid. Also, it has an implicit constructor from `const std::string` and `const char #` allowing you you define a single function like `Thing ParseThing(std::string_view line)` and accept `char #` and `std::string` as an input.

More examples are here: https://abseil.io/tips/1

# -> *. HN formats bad

\* (backslash asterisk) will escape the asterisk.

>Also, it has an implicit constructor from `const std::string` and `const char *` allowing you you define a single function like `Thing ParseThing(std::string_view line)` and accept `char *` and `std::string` as an input.

every function where you are reading from a string without writing to it or saving it, you can use std::string_view. Same for vector / array: anything non-owning, read-only should use std::span instead.

it's not only type-safe, it uses much less memory, takes less time to construct and does not duplicate the "null" state:

- your JSONStruct takes 160 bytes (on 64-bit systems with libstdc++), the variant one takes 56, almost three times less.

- it needs std::optional<T> for each member to avoid construction, while std::variant does that by default. But the compiler still have to initialize all these optionals to their default state.

- you need on every access two branches:

* one for the type switch

* one for the optional

the variant only has one level of indirection.

That's fair. I assumed it would be clear to anyone who knows C++ better than I that the point of this post wasn't exactly performance.

Actually I was most interested in just how simple and readable I could make it. But I didn't say that in the post anywhere. Will add.

> I assumed it would be clear to anyone who knows

It's just not possible to assume that at all on the internet. Every year I have students who learn from blog posts like this for instance.

As someone who does quite a bit of C++ recently: for most uses readability is king.

If you did want squeeze out the extra performance you could also do something where you store `std::variant<>` inside a struct and provide an API like this:

    if (auto int_value = value.i()) {
      // *int_value == your int
    }

and expose a `std::variant<> &variant();` for use cases where you want the more complex/faster stuff.

Using variant as the storage type while providing a nice public accessor API makes sense given the huge difference in semantics between a struct containing optional fields and a variant.

Performance aside, using variant has an added benefit of making illegal states unrepresentable. Optionals + an enum still allows users to either nullopt all the members, or have more than one member that is not nullopt.

How do you get the size of the struct? Is there a compiler command to do that?

https://en.cppreference.com/w/cpp/language/sizeof

Rather than using std::visit, you can just use a chain of if statements with get_if [1]. You keep the most important benefits of std::variant but the code is much more readable (IMO).

[1] https://news.ycombinator.com/item?id=25316192

Interesting, I find the list of of ifs much less easy on the eyes. I wonder why that is.

Agreed that it's a personal preference. If you geniunely have a standalone function, like print_type shown here, then std::visit seems roughly even with std::get_if to me (but I'd tend to use the latter for consistency with my other code). std::visit would clearly come out ahead if you had some sort of complex nested variant and you called out to other visitors. get_if is clearly ahead IMO if you're using a variant in passing in a broader function, and especially if you when you want to use control flow (if you return in an if branch you return from the wider function).

Yes, this case (checking for a type and returning early) is pretty much my only usage of get_if (and in this case it makes a lot of sense)

Your alternative is undefined behavior due to using an incomplete type in std::map. C++17 allows std::vector to use an incomplete type but std::map does not.

Reference this paper for further details:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n451...

Why doesn't the compiler error when compiling if it is undefined behavior? It seems really simple to detect if a type is incomplete.

It's undefined because the standard says so explicitly for these containers, but if you copy-pasted all the code of libstdc++ or libc++'s std::map in a new namespace and gave it your name it would be perfectly defined.

It's a bit like naming a global variable _Weeeeeeeeee. It's technically UB because the standard says so, but in practice the compiled code will be fine if your stdlib does not use that variable, the compiler isn't actively looking for elements of the spec to check and enforce, it's just using UB where it can as a tool to optimize

I was only really aware of undefined behavior that was relevant to runtime behavior. I wasn't aware using compiler reserved identifiers was undefined behavior; I assumed it was required to error.

I don't see the purpose in allowing trivially detectable UB to exist. In this case and in the case of reserved identifiers, I don't see how any optimization could be made using the UB. Noticing the UB allows you to do anything, so you might as well rewrite the program to do nothing.

> I assumed it was required to error.

They are reserved because the compiler (and OS) writers need identifiers they can use in their own headers without breaking valid user code. Since there is no good way for the compiler to say which headers are user headers, erroring on those symbols would be counter-productive.

C++ has a lot of these silly rules. For the case of reserved identifiers, they are reserved for the implementation of the standard library, but of course C++ uses a copy and paste system of #include's which takes place in the preprocessing phase, before the actual parsing/compiling phase. That means when you #include <vector> into your own main.cpp, you're copying and pasting "vector" into "main.cpp" and compiling "main.cpp", so the compiler would have to jump through all kinds of hoops to figure out that a certain section of "main.cpp" comes from "vector" and another section comes from this or that.

It's certainly possible to do this in principle, but the standard does not impose that burden on any implementation.

At any rate, the standard is full of this kind of compile time "undefined behavior". The formal term for this is "ill-formed, no diagnostic required" aka "NDR" which means that the program is invalid C++ but the compiler is not required to report an error, and running the subsequent translation is undefined behavior.

Ah, I thought it came along with std::vector in the authorized bundle. Well, one can just use the boost containers instead since they don't have that wording.. but to be honest I used incomplete std::vector in a similar fashion for years without issues.

std::variant is an abomination. The idea is stellar. But actually using it is a frustrating nightmare. I prefer the simple way, unfortunately.