I take back everything bad I ever said about C++11. It has pretty much changed my life.
I finally had an opportunity to dig a little deeper into this idea that we programmers should shy away from trying to optimize our code. “Trust the compiler,” they always say. “The compiler will make smarter decisions than you will.” I never fully agreed with this assertion. I certainly trust that the compiler does a lot of things behind the scenes, but I also know that the compiler cannot fully deduce the logical flow of my software.
I stumbled upon this presentation. It is a fantastic presentation, and I recommend you watch it. But really? This is what people are doing to help the compiler out? I certainly agree with letting the compiler do its job if you are so ignorant as to how the language functions on a basic level. If you are even slightly doubtful about your implementation, keep it simple, and the compiler will make pretty good decisions for you.
The problem is that, after seeing just once instance of this, people extrapolate the logic to all cases and begin harassing others for even so much as attempting to writer faster code. “Premature optimization is the root of all evil! Profile it first! The compiler writes better code than you do!”
Look, I really do wish compilers could follow high level logic. If I have a hard coded std::vector with four hard coded calls to push_back with literals passed in, it’d be great if the compiler could see all that, pre-allocate the space, and do it in one step. The fact is, it doesn’t. (I would love to be proven wrong here.) I, the programmer, know better about what lies ahead. So, I am going to write the code in a such a way that fits my situation. I really want to punch the next person who tries to tell me that “C++ programs should never have C-style arrays in them”.
My husband shared this with me. This is true in my home. HAHA I am a software engineer’s wife. XD
This in response to that.
Since I work in software directly, I have a unique perspective on the DRM debate. Much of the time, I hear non-technical people state that DRM is OK as long as they cannot “feel” it. I am fine with that response. That’s really the core of the issue, isn’t it? No one would mind DRM if it had 100% accuracy and never once prohibited an honest person from using the software legitimately.
Basically, software is written to enable people to do stuff. Every line of code is there to empower the user. Sometimes, code is written to add new features. Sometimes, code is written to fix bugs, which indirectly empowers users by removing obstacles. In general, an argument can be made that all code written is there to help someone somewhere. Users want updates/patches because they bring more of that enabling power to them.
DRM emerges the instant code is written to weaken the user. When code only exists to prevent the user from doing something (for license reasons, not for safety reasons), it is DRM. Refusing to write code to enable something for the user is one thing; proactively writing code to disable the user is DRM.
1. When you talk about DRM, what kind of DRM are you referring to? What sort of practices? Is anything at all that prevents you from simply copying a directory to another machine and running it considered “DRM” to you?
Based on my established definition, my answer to that last question is yes. The game better have a pretty convincing reason as to why it is not a clean, self-contained piece of software.
2. Are simple license keys DRM?
Yes. The key-check code is only there to stop the program from running.
3. If not, do they become DRM if the game “phones home” to make sure it’s valid? If so, is there any point at which it ceases to be “DRM” in your mind? Like if it’s a common code or password to unlock the game? Or if you have to authorized a service (like Steam) on your machine before the games will run?
The only way it ceases to be DRM is if it is only used to enable online multiplayer. That is an authentication check in a controlled environment owned by the creators. I am playing on their hardware, and it is perfectly reasonable for them to authenticate against my key. However, this should not apply to my own LAN games, obviously.
4. All that being said, do you prefer to have a big demo download that can be upgraded with a single code or password, or a smaller demo download that must be replaced by downloading a “full version” that doesn’t require any sort of DRM or unlocking mechanism?
This is a tough question. I used to think it was an easy one, but I find myself flip-flopping on what I prefer. I think the unlock code is great for games where the download is relatively small to begin with. If the entirety of the game is 100 MB, sure, just slap an unlock code on there. If the game is 15 GB, eesh, lemme try a small demo first. Then I’ll buy. However, if I had to pick just one or the other, I prefer the latter (separate demo and full version) because I like having a version of the game that is complete and self-contained (and hopefully DRM-free). I’d rather not take the risk of losing my key or whatever.
5. How important are demo versions of games to you these days? Do you usually try a game before you buy it, or are your decisions mainly determined by watching preview videos / descriptions / reviews / screenshots?
These days, demo play is required. I have so many options available to me today that I can afford to be picky. While rare, I do sometimes buy games cold turkey (without a demo) if the gameplay video is extremely compelling. To me, it’s the sign of a good game: the video evokes emotions that makes me wish upon a star I was playing it right now. I’m not talking about graphics and explosions. I mean that I can really see the gameplay and want to experience it right now. For the rest of games, I need to play them to know if the videos are not doing them justice.
Dear Xbox and Playstation fans. It is cute when you fight, but before you think about trying to drag Nintendo into your pissing contest please take a moment to remember why Nintendo doesn’t even acknowledge you as their competition, much less their rivals.
(that being said i have no idea where this information is from and if it is valid)
My language project is being dubbed K++. My first initial is K, and I like C++. So, K++ it is! We’ll see how long that lasts.
Classes and structs have different uses and technical meanings in different languages. Since C++ is the language I am seeking to improve upon, I will focus on its particular flavor of classes and structs. C introduced the struct, and it had no concept of private member variables. It was simply a way to group multiple variables together into a single block of memory. Along came C++, and suddenly, data could be locked down. By marking stuff private, the class can hide data details from the programmer and only expose a proper interface for handling the object as a whole.
In C++, classes and structs are identical. Classes default to private, and structs default to public, but those can be easily overridden. Both support constructors, destructors, operators, etc. So, for many C++ programs, a class is generally meant to indicate a black box data type with a carefully crafted public interface, and a struct is generally meant to indicate a white box data type serving as a dumb container for multiple variables. This is the only way to really keep both keywords useful.
I think C++ was onto something by having classes default to private variable access. It obviously wanted to encourage encapsulation, but it left the option open to have public data as needed too. However, as I have grown as a programmer, I have found that all my excuses for having public data have washed away. All my data is private 100% of the time. I do not even use protected member variables anymore. If I want to allow class extension, I still wrap the relevant data in properties (actual or otherwise depending on whether I’m working in C#).
So, my first executive decision for K++ is this: there will be no public, protected, or private keywords for (non-static) member variables. All class member variables shall be private. Conceptually, a class should commit to that black box approach. The programmer has to responsibly expose a proper interface. If that means building setters/getters for certain variables, so be it. I’ll be more than happy to supply simplified property syntax (similar to C#’s shorthand property syntax), but it still needs to be an explicit decision.
I’ve looked through C++, C#, and Java code at my job for examples, and I feel really good about this decision. I suspect there might be arguments made for allowing at least protected member variables, but I think the simplicity and consistence outweigh convenience in this case. The point is that any programmer should have 100% confidence in being able to alter the private implementation of a class. The instant you see a public or protected variable, you know it’s gonna be a long day refactoring as you track down where it’s being used.
So, where does that leave structs? I think structs should be the exact opposite: all member variables are all public all the time. A struct’s purpose is simply to tie a few variables together. I would rather not complicate the process on either side by exposing the temptation to developers to make data structures that are half private and half public. I have to present a strong philosophy in the language design, or people will just go back to C++ and never look back. I cannot try to be everything; I’ll simply lose the war to C.
On that note, why did we call it a struct anyway? I understand that C was invented a long time ago, but would it really kill us to put 3 more letters onto it? I think ‘structure’ looks so much nicer than ‘struct’. Ironically, for what it represents in K++, I’m not even sure I like that word at all. To me, a better term would be like ‘group’ or something. I haven’t hammered down this aspect yet. I’ll come back to it later.
The longer I work on my cross-platform game development framework, the more I just want to incorporate all my ideas into a new language. Particularly recently, I’ve had a flood of inspiration for this hypothetical new language. The temptation to work on this language is spiraling out of control the more I learn about LLVM.
As I started to spec out my ideas, I finally had to confront the question: am I seeking to replace C or C++? What problems am I really trying to solve? The longer I thought about it, the more I realized that I really have nothing to offer C. It grants absolute control over everything. All memory is completely malleable to the code. There are no wonky high level concepts like exceptions muckin’ up the works. If someone is working in C, they probably know what they are doing. C is heralded as a “systems language”, and based on my experience, I find that to be spot on.
C++ is the language that needs serious help. It introduced all these concepts/extensions/libraries to help developers be more productive in C, but in the end, it left them caught in the void between worlds. The really good C++ programmers generally sit in one of two camps. The first camp (where I live) creates engines. They generally program in highly efficient C and only dip into C++ features as necessary. (Things like templates are extremely powerful and do not hinder performance whatsoever.) The second camp embraces all of C++ and distances itself from C as much as possible. This camp uses high level objects and frameworks to reduce cognitive load. Developers here ban arrays and “naked pointers” in favor of safe wrappers and handlers.
The problem is that C++ is its own worst enemy. It is such a huge language that people have strongly varying perceptions of the language and its users. People in the C camp (like Linus Torvalds) end up hating how stupid C++ programmers are and just go back to C. People in the high level camp end up hating how unsafe the code is and migrate off to Java, C#, Python, etc.
Everyone loses. Everyone talks about C++ as the language they “have to use”. They are either maintaining legacy code or working with low level drivers. No one wants to author new systems in C++. It’s too much of a joke to write a kernel in, and it’s too dangerous to write a user application in. How do we fix this?
This is why I am working on a new language. I feel a proper balance can be struck between the two camps. As I said above, I have no interest in disturbing the C community. The language is simple and powerful and does not really need improvements. However, I really feel for the guys who pick up C++ to gain a few features but constantly have to dodge bullets from the high level camp telling them to abandon their quest to stay close to the metal. What a low level programmer craves is the ability to express themselves in a clear, concise manner without forfeiting speed. Meanwhile, the only reason any of the high level C++ programmers stick around is that speed. C# and Java are way easier to work in; obviously something about C++ kept them there.
The high level programmers demand a more sane standard library. STL is a joke. Benchmarks aside, C++ keywords and STL combine to make painfully cluttered code. cout? std? const? ptr? The API alone is more than half the reason I put up with C# at work. “Console.Write” is abundantly clearer than “cout «”. (Sadly, Java squandered this opportunity and made an equally disgusting library.)
I’ll go into more specifics in future posts. I hope this all made sense. I think the world is hungry for a language that compiles straight to machine code. There is no reason a low level language cannot be elegant and expressive. Oh, and it can be “safe” too.
Python > Else..
Whenever I’m up all night programming.