I really wish more projects would use .hpp to differentiate from C headers. It’s really annoying to have a single header extension blend across two incompatible languages.
I did this in a project and someone later came and changed them all to .h, because that was “the convention” and because “any C is valid C++”. Obviously neither of those things is true and I am constantly befuddled by people’s use of the word convention to mean “something some people do”. It didn’t seem worth the argument though.
…so that leads to another annoyance of mine. The insistence that there aren’t two languages but indeed one named C/C++. Obviously I’m being a bit sarcastic but people blur the lines HEAVILY and it drives me crazy. Most of the C code I’ve written is not compatible with C++…at least not without a lot of type casting at a bare minimum. Or a compiler flag to disable that. Never mind the other differences. And then there’s the restrict keyword, and the ABI problems if the C library you’re using doesn’t extern C in the headers…etc etc… -_-
Yeah, I use that all the time. I think I use it in a different way though. I have projects with C, C++ and other languages. The C and C++ get compiled and linked together, and so there are some considerations for those files that don’t apply to anything else. So I mean C files and C++ files, but not as if they were the same language.
Yeah that’s completely fair and makes sense to me. I just know I’ve come across stuff where people are talking about it like they’re the same language. This seems to be especially prevalent in windows development where the C support is pretty poor in comparison and tends to kinda be lumped into into C++.
Projects for Apple platforms usually also use .h, where it could mean anything from C/C++ to Objective-C/C++.
In practice, Clang handles mixed C/C++/Obj-C codebases pretty well and determining the language for a header never really felt like an issue since the API would usually already imply it (declaring a C++ class and/or Obj-C class would require the corresponding language to consume it).
If a C++ header is intended to be consumed from C, adding the usual #ifdef __cplusplus extern “C” {… should alleviate the name mangling issues.
Yeah, I was ignoring apple platforms because Objective-C doesn’t even have its own header extension as an option. Also not all C headers do extern stuff…and it doesn’t fix 100% of compatibility problems when you do that anyway. Also I’m not really talking about it from a compiler perspective, I’m talking about it from an organization and human perspective. I know compilers generally don’t care…which is exactly how we ended up in this predicament.
Yeah. My original comment should have been “I wish people would use a C++ specific extension for headers.” I just picked hpp because cpp seems to be the most widely used C++ extension.
It’s actually not. Objective-C is a superset of C. C++ is not. It’s MOSTLY compatible…but it’s not a superset. See the restrict keyword, or the need for casting to and from void*, or the inability to name variables new or delete, or class, or this. I can’t count how many C projects I have which use this as a variable name that WILL NOT compile as C++…or the need for extern C to call C ABI code…in no way is it a superset
EDIT: lol, you can downvote me if you want but I think you need to lookup what a superset is
I don’t code in C++ (although I’m somewhat familiar with the syntax). My understanding is the header files should only contain prototypes / signatures, not actual implementations. But that doesn’t seem to be the case here. Have I misunderstood, or is that part of the joke?
Not a C++ developer, I prefer C. You are right in general however my understanding is that classes which are generic using templates must be fully implemented in header files because of how templates are implemented. That being said this code doesn’t appear to use templates so I’m not entirely sure I get it either?
I’m not fully sure what the intent of the joke is, but note that yes, it’s true that a header typically just has the prototype. However, tons of more advanced libraries are “header-only”. Everything is in a single header originally, in development, or it’s a collection of headers (that optionally gets “amalgamated” as a single header). This is sometimes done intentionally to simplify integration of the library (“just copy this files to your repo, or add it as a submodule”), but sometimes it’s entirely necessary because the code is just template code that needs to be in a header.
C++ 20 adds modules, and the situation is a bit more involved, but I’m not confident enough of elaborating on this. :) Compile times are much better, but it’s something that the build system and the compilers needs to support.
Well, it’s even just horrid code, because they’re reading user input in some random associated function, so I think, it’s safe to say that this is supposed to be horrid code.
Do other languages separate definition from implementation? 🤔 Is there another way to distribute libraries with a binary component and a public component?
Anyway, you don’t need to separate them in your source code to have a legible component on your distributable. C is the only language that insists you must have part of the source code before you can use the very public perfectly clear interface that is written all over shared libraries.
Also, you can distribute proprietary libraries by source perfectly well. And it’s the standard except on very few cases where a corporation can coerce most of the world on accepting any shit.
Define your terms before relying on platitudes. Mutability isn’t cleaner if we want composition, particularly in the face of concurrency. Being idiomatic isn’t good or bad, but patterned; not all patterns are universally desirable. The only one which stands up to scrutiny is efficiency, which leads to the cult of performance-at-all-costs if one is not thoughtful.
I agree somewhat, but I’d also say any codebase needs some level of “dogmatic” standard (ideally enforced via tooling). Otherwise you still end up with bad, messy code (I’d even say messier, as you don’t even get consistency)
I’d agree with the first half, but not the second. Sometimes mutability allows for more concise code, although in most cases it’s better to not mutate at all
I think the general idea would be to take the original const, and create a new const with the new location applied. Destroy the original when it’s no longer needed or scoped. State maintained through parameters passed to the move function e.g. move(original const, new location) -> new const object instead of stateful members in the object like move(mutable, new location) -> updated mutable.
Random example, imagine a variable that holds the time of the last time the user moved the mouse. Or in a game holding the current selected target of the player. Or the players gold amount. Or its level. Or health. Or current position.
Keeping state managed. The data for the function will be very predictable. This is especially important when it comes to multithreading. You can’t have a race condition where two things update the same data when they never update it that way at all.
Rather than me coming up with an elaborate and contrived example, I suggest giving a language like Elixir a try. It tends to force you into thinking in terms of immutability. Bit of a learning curve if you’re not used to it, but it just takes practice.
I’d say this example doesn’t fully show off what immutable data can do–it tends to help as things scale up to much larger code–but here’s how I might do it in JS.
<span style="color:#323232;"><btn mobile big>
</span><span style="color:#323232;"><btn desktop small solid my-class>
</span><span style="color:#323232;"><btn medium>
</span>
Notice that JavaScript has a bit of the immutability idea built in here. The Array.flat() returns a new array with flattened elements. That means we can chain the call to Array.join( " " ). The classes array is never modified, and we could keep using it as it was. Unfortunately, JavaScript doesn’t always do that; push() and pop() modify the array in place.
This particular example would show off its power a little more if there wasn’t that initial btn class always there. Then you would end up with a leading space in your example, but handling it as an array this way avoids the problem.
Very interesting. Actually the part you mention about there being an initial ‘btn’ class is a good point. Using arrays and joining would be nice for that. I wish more people would chime in. Because between our two examples, I think mine is more readable. But yours would probably scale better. I also wonder about the performance implications of creating arrays. But that might be negligible.
The app working isn’t good enough, it needs to be maintainable. From a professional perspective, unmaintainable code is useless code.
Code that mutates everywhere is generally harder to reason about and therefore harder to maintain, so just don’t do it (unless there’s literally no other practical way, but genuinely these are very rare cases)
Fair play, I guess we’re probably just gonna disagree.
In my experience I’d say mutable code (larger than anything other than toy examples) always results in more time spent fixing bugs down the line, predominantly because it’s objectively harder for humans to reason about multiple one to many relationships rather than multiple one to one relationships. I’d say because you need to think about all possible states of the set of mutable variables in your code in order to completely understand it (and I don’t just mean understanding the intended purpose of the code, I mean understanding everything that code is capable of doing), that usually results in a more convoluted implementation than the pretty linear way you typically read functional code.
Longer code is practically always better if it’s easier to understand than the shorter alternative. Software engineers aren’t employed to play code golf, they’re employed to write maintainable software. Though I’ll say ultra high performance applications might be the exception here—but 99% of engineers aren’t doing anything like that.
I’m always happy to be convinced otherwise, but I’ve never seen a convincing argument
In functional programming, everything is seen as a mathematical function, which means for a given input there is a given output and there can be no side effects. Changing a variable’s value is considered a side effect and is thus not possible in pure functional programming. To work around this, you typically see a lot of recursive and higher order functions.
Declaring all values as const values is something you would do if you’re a diehard functional programmer, as you won’t mutate any values anyway.
Depends on how deep down the rabbit hole you want to go :p
creating a new variable that contains the updated value
recursion (e.g. it’s not possible to make a loop that increments i by 1, but it is possible to turn that loop into a function which calls itself with i+1 as argument)
avoiding typical types of operations that would update variable values. For example instead of a for loop that updates every element of a list, a functional programmer will use the map function, which takes a list and a function to apply to each element of that list to create an updated list. There’s several more of these very typical functions that are very powerful once you get used to using them.
monads (I’m not even gonna try to explain them as I hardly grasp them myself)
Out of the 3 main web languages I use to develop my games (HTML, CSS, and JavaScript), CSS is definitely my least favorite.
HTML is relatively simple and understandable such that bugs rarely get introduced into my HTML code.
JavaScript, while janky and not known for good performance, will work without too much trouble compared to other languages (I’m looking at you, C++). No segfaults, effortless type casting, intuitive syntax, and debugging is fairly easy. Worst part is editing HTML and styles with JavaScript, it just feels clunky, to both the programmer and the CPU.
And then there’s CSS. Despite being a language dedicated to making things look pretty, it’s just an unintuitive list of properties on HTML classes. So many times it takes way too long to do a simple thing like center text in a div when there is other text that is meant to not be centered. But I guess I’m not using it to its fullest potential, as I recently came across an article that listed many pretty graphics, often animated, that was purely made using CSS.
I’m of the opinion that it’s a positive. Often I use “string” + number to access HTML elements and it just works. I can even use it to concatenate arrays.
Meanwhile, when I try to debug in C++ with cout statements, half the time it doesn’t even do anything even though I use std::to_string().
Somehow I doubt a lot of these opinions are steeped in the experience of building an HTML layout using tables, transparent gifs and inline width attributes. Shit was wild before CSS.
programmer_humor
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.