Hacker News Reader

Comment by 112233 | Hacker News Reader

Ugh, so much wrong with this. There is C++, as implemented by every compiler, and then there is fantasy C++, as seen by the committee... See, e.g. this trainwreck:

    https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/rt2ivJnc4hg%5B1-25%5D

Also, e.g.

> P.6: What cannot be checked at compile time should be checkable at run time

Great! I want to do it! later...

> F.4: If a function may have to be evaluated at compile time, declare it constexpr

Ok. You can't put static_assert in constexpr function. You can't put runtime assert in constexpr function. You can't put debug print in constexpr function. How do you even debug that?

View on HN

I agree, e.g. they recommend not using `#pragma once` because:

> It injects the hosting machine's filesystem semantics into your program, in addition to locking you down to a vendor. Our recommendation is to write in ISO C++

Erm. What. Compiling anything other than a one-file program "injects the filesystem semantics into your program". I mean... your program is stored in a filesystem. #include uses a filesystem. What utter tosh.

And as for locking you down to a vendor, even niche compilers that you've probably never heard of support it.

https://en.wikipedia.org/wiki/Pragma_once#Portability

I'd take anything from there with a boulder of salt.

Hrmf, what I think they tried to say is that #pragma once causes your code to compile differently depending on which file it's stored inside. This can cause problem with some tooling (e.g. precompiled header generators, some distributed compiler tools, etc.) which concatenate header and source files to generate an amalgam.

So it's not "tosh", it probably just doesn't correspond to your way of writing C++ code.

> How do you even debug that?

    constexpr int hard_stuff(int x, int y) {
        return x + y;
    }
    
    void hard_stuff_test() {
      static_assert(hard_stuff(2, 3) == 5); 
    }

?

> How do you even debug that?

You provide a set of static assertions for the use cases you aren't sure of. constexpr functions should be thoroughly unit testable at compile time.

If you're worried about production compile times, put the static assertions in your test code.

Agree about unit tests. But asserts are used also to catch invalid _use_ of functions.

    void f(size_t x) {
        assert(x); // calling f with 0 is bug
    }

    constexpr f(size_t x) {
        ?????(x != 0); // <- what to write here?
    }

> You can't put debug print in constexpr function. How do you even debug that?

Use an IDE.

> Use an IDE.

Explain.

IDEs provide graphical debuggers and colorization to show which code actually gets compiled.

For example on Visual Studio, paths not taken on conditional code get grayed out.

You disappoint me pjmlp, you're not a true graybeard unless you use Vim or Emacs :o)

The slightly more serious question: is there anything like this in Vim or Emacs-land? I somehow doubt it... I, for one, have never seen something like it outside of the big IDEs (Visual Studio, IntelliJ, etc.)

I am an ex-XEmacs user, and used vi on Xenix, DG/UX if that makes you happy. :)

Always been an IDE fan since Turbo Pascal 6.0 with its Turbo Vision based IDE.

rtags for Emacs does this, as well as completion, highlighting syntax errors, and various other IDE-like features.

Got any demo for that? I couldn't find the "highlight unused code" thing...

>You can't put runtime assert in constexpr function.

As of C++17 you can: http://en.cppreference.com/w/cpp/error/assert

You can also throw exceptions in constexpr functions since C++14.

Reply on news.ycombinator.com