Hacker News Reader

Comment by edflsafoiewq | Hacker News Reader

This?

    template<typename _Tp>
      _GLIBCXX14_CONSTEXPR
      inline const _Tp&
      max(const _Tp& __a, const _Tp& __b)
      {
        // concept requirements
        __glibcxx_function_requires(_LessThanComparableConcept<_Tp>)
        //return  __a < __b ? __b : __a;
        if (__a < __b)
          return __b;
        return __a;
      }

I mean, there are more overloads, but it isn't what I'd call huge.

View on HN

Would that thing return precisely the same output for all possible inputs as the new Linux max()? I would imagine that even if the answer was yes, it would also require quite a few provisos.

To be honest, I'm just a bystander here but I did actually find the C based max() presented easier to appreciate than the C++ one you present here.

The C one looks more like a maths proof: build the argument ... et voila. It also does not have comments inline because it is a sort of comment. The C++ version has two inline comments, one of which is incorrectly formatted (space or no space after indicator) and the second one seems superfluous because it uses code to describe code. The C++ version, after you strip out the comments, looks very concise. If it does the same job then good stuff. After that we are down to whether x,y is a better choice than a,b. On balance I prefer a,b for arbitrary inputs and x,y etc for functional dependent - so the C++ example wins here for me.

> The C++ version has two inline comments, one of which is incorrectly formatted

This seems like the kind of thing which is easily corrected and probably not relevant for determining which is the better approach.

Yes it is easily fixed but this is a lack of attention to detail in a fundamental area. I would imagine that many, many people have seen that code at some point and yet have not bothered to fix up a glaringly obvious formatting error. That may say more about people than the quality of the code but it looks awful to an outsider (like me).

That chunk of code is one of the fundamental building blocks of C++. When presented as exhibit A it should look good. To an outsider that sort of thing looks bad, even if the presented thing is correct the silly error will be obsessed over - as here.

If something is important enough, and I think that C++ is one of those, then for $DEITYS sake fix the obvious stuff before having to be an apologist for it. A simple sed script run decades ago would have done that.

The reason I am labouring this point is that one day it wont be a discussion on HN debating this sort of bollocks but something involving lots of dosh. If S&M ever realised what source code really looked like - they'd have a fit. The world turns ...

Have you considered that it might be intentional?

I agree. This looks to me like a commented out source line, not a comment that describes what comes next using a similar code expression.

It makes sense to drop the space before the start of the commented code because that way you can just delete the // and obtain the original source line.

I'm going to have to disagree that a missing space in a comment is a fundamental flaw.

Argh, I deserve my portion of lashes, but it is so clearly standing in my experience: most coders who don’t care of syntactical purity like formatting, indenting, consistency, meaningfulness etc. — they have less awareness and make more errors than those who do. It is not a strict rule, but a sign of weakness in that regard.

  }
  int foo(){
    for(x=1; x<len*2;x++){//over 2 array len
    ...(no empty lines for next hour)

I know I’m clinical perfectionist, but try to see it behind my complaint. Our brain can process only few things in parallel. If you overload it with parsing and do not provide hints like grouping and/or formatting, you occupy a couple of threads for a complete bs. As if programming was not one of the hardest things already.

To be pedantic, note that is not the "C++ version" of max(). This is a particular STL's implementation of max(). Different STL implementations may approach it somewhat differently.

In practice, the style for writing STL code is often quite ugly (sometimes deliberately ugly), for reasons which aren't really interesting to most people.

It is interesting, it is related to this downside of C++ that templates have to be defined in header files, instead of say being compiled in some kind of module.

> The C++ version has two inline comments, one of which is incorrectly formatted (space or no space after indicator)

It’s not unusual to use a space after // for comments and no space for code that has been commented out.

You are upset about comment formatting, but find this easier to appreciate?

  ...
  #define __is_constant(x) \
      (sizeof(int) == sizeof(*(1 ? ((void*)((long)(x) * 0l)) : (int*)1)))
  ...

How many C programmers would even understand what that code does, without an explanation?

And it is not even standard C, but uses GCC extensions.

Does this coerce distinct type a and b, or just fail if they are different types? The C one will evaluate the comparison / trinary expression via the usual integer promotion rules.

The C++ version does not promote types. The language is generally much stricter about implicit type conversions, so this is very much in line with the language design.

Reply on news.ycombinator.com