Is that a likely problem for the kernel, actually? Given that there's no API stability, and the fact that syscalls are an explicit ABI anyway, I don't see how that'd matter for linux?
This is C++ on Windows for you. On Linux, most compilers follow the ABI that GCC created, which has become very stable. I actually cannot name a C++ compiler that doesn't follow that ABI.
Which is why any Windows developer that wants to export OO libraries uses COM instead, with the benefit that any Windows compiler that can speak COM is able to use the library.
UWP now even supports generics and actual inheritance.
It's a true statement that C++ has gained considerable complexity since those days, largely due to the C++ committee's very religious approach to compatibility. How that added complexity has influenced how complex C++ applications must be is a discussion with considerably more nuance.
I'd argue: Yes, this is true. But you need at least on stable part in the toolchain for the kernel to get reliable results. You can't have your hammer transform to a screwdriver just because you swing it in the other direction. And if there is such a tool/case, you need to be absolutely sure how and when it behaves this way, on every possible platform.
To me this situation is more more like having a screwdriver that can only be screwed with hammers from a particular manufacturer (Linux -> GCC), because that manufacturer is the only one that makes hammers with screw-driving tips that work with that particular screw head (non-portable macros for type-checking or whatever goes on there). You might as well just get a normal screwdriver (C++ compiler) and a normal screw (C++ program) like the rest of the world does -- and there's no implication that you have to keep changing screw tips (-std=c++??) every time Apple (standards committee) decides to come up with a new format (C++17).
If you are going to argue that, then you need to look again at the headlined item, where it was not the case that it behaved the same on every possible platform. It is a non-standard mechanism of one compiler, that was picked based upon a compromise decision about what versions even of that one compiler it would actually work with.
The problem is that you can't always require people to use the latest bleeding edge version to build your code. Especially the Linux kernel has quite some requirements for backwards compat.
And yes, the fact that abi stability isn't really a thing in c++ land is a huge problem too. It has been tried before with beos and it sucked.
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.
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.
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 ...
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.
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.
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.
No it doesn't, which is one of the major advantages it has over the C version; you have to do an explicit cast when the args are different types (almost always a potential source of subtle bugs).
Assuming the single template argument version. If T has an implicit constructor taking type R as argument, wouldn't the second argument into max of type R be implicitly converted to T before getting passed to the max function? So there is no need for a special version taking both L and R?
This is a property of c++ implicit constructor rules, it is not unique to this function. In most cases this is something you want to avoid but for integer promotion it can some times be useful.
Oh, "conflicting types for parameter 'T' ('T2' vs. 'T1')". I'm surprised but it's a nice surprise. Finally something in c++ where safety is valued more than implicit dangerous magic.
A difference is that the linux macro works for non-constant expressions as well.
All the crazyness is in order to support both constant expressions (and keep them constant expressions) and non-constant expressions with the same max() macro.
That version does this. From cppreference (emphasis mine):
>The constexpr specifier declares that it is possible to evaluate the value of the function or variable at compile time. Such variables and functions can then be used where only compile time constant expressions are allowed (provided that appropriate function arguments are given).
That one-liner I posted works with both constant and non-constant expressions (and in fact is more likely to be evaluated at compile-time than the macro), is type-safe, and has no side effects assuming both arguments are arithmetic types or pointers (like all uses of `max` in the Linux kernel / C-language programs).
In C++, all the craziness and brittleness you find in the "C version" is actually encompassed entirely within the `constexpr` keyword. The compiler gets to deal with a lot of complexity to make that possible, but for users it is genuinely "that easy".
