Forem: rwalroth

Why I prefer C++ to Python

rwalroth — Wed, 27 Jan 2021 19:25:02 +0000

After working in python for many years, I decided it was time I learn a second programming language. Everyone seemed to suggest C++ was the hardest language to learn and the most unpleasant to work with, but it also seemed the most widely used for native applications. So I decided to learn it anyway and found myself slowly growing to appreciate it more and more (heavily recommend this course, it's long but covers so much necessary information). Now, all my hobby projects are written in C++ and I am constantly looking for excuses to write more C++ code in my day job. Yet the whole internet is filled with people talking about how awful C++ is, how Rust is going to bury it, etc. So I decided to write up a comparison of python and C++ and give my rationale for preferring the language everyone loves to hate.

Controlling memory

In python, everything is an object reference. What this means, is that every variable is a container for an object that allows you to use that object. This is not a problem, it's just how python is implemented. The problem comes in when we want to control how we move around objects. For example, what does the following code output?

a = [1, 2, 3]

def myFunc(b):
    b.append(4)

myFunc(a)
print(a)

The answer is [1, 2, 3, 4]. What about this?

a = [1, 2, 3]

def myFunc(b):
    c = b
    c.append(4)

myFunc(a)
print(a)

It still prints [1, 2, 3, 4]! Ok, now what about this:

a = [1, 2, 3]

def myFunc(b):
    b = [1, 2, 3]
    b.append(4)

myFunc(a)
print(a)

Now it prints [1, 2, 3]! What is happening here? Well, that variable b in the function is an object reference, because everything in python is an object reference. At the start of the function, the function variables are all told to point to the object referenced by the input parameters. In other words, b and a both point to the same list. Not a copy, the exact same data stored in memory. Which means any modifications done to the object in the function stick with that variable after the function ends. That's why the append method permanently modified our variable. What about the second function? As it turns out, the = operator in python is more complicated than you think. It changes what an object reference is looking at, without changing the object previously referenced (the garbage collector eventually cleans up the old memory if all references to it are gone). But that means that, again, if we change c it will change b which means we change a. Finally, in the last function the right hand side of the assignment initializes a new list, and then gives the reference to it to our variable. b no longer refers to the data it grabbed at the start, it refers to a completely new list. But the variable a still refers to the old object, because b is a different object reference, it just shared data with a at the start of the function. When you use the = operator, you break that reference and now there's no way to access that data within the function. Let's compare it with C++ code:

#include <vector>
#include <iostream>

void myFunc1(std::vector<int> b) {
    b.push_back(4);
}
void myFunc2(std::vector<int> &b) {
    b.push_back(5);
}
int main() {
    std::vector<int> a {1, 2, 3};
    myFunc1(a);
    myFunc2(a);
    std::cout << '[';
    for (auto i: a) std::cout << i << ", ";
    std::cout << ']';
    return 0;
}

What is the output? It's [1, 2, 3, 5, ]. myFunc1 was not given a reference to a, it was given a copy, and we explicitly told it we only wanted it to have a copy! We know that no matter what that function does, a will come out the other side unchanged. In myFunc2 we gave it a reference instead, meaning we understand that function can modify the data. If we want to avoid making a copy of large objects but still want to protect the object from being modified we can add in a const modifier, more on that later. When assigning inside a function or outside, we can assign variables as references to other variables, as copies of the data, or just grab a pointer to the data. In python, you get object references. This means you need to be careful about modifying an object, and if you expect your function to modify an object you have to be very careful throwing around the = operator.

Constants

This brings me to the next part of python that is sorely lacking, constants. There are no constants in python. You can make some rules such as "all caps means don't change this" but it's always on the programmer not to throw that away and change a constant. For functions, where you can only pass things as object references, there is no way to protect your object from being changed. In very large code bases, if you actually change a constant somewhere it can be a pain to track down.

Privacy

Python has no private members or private attributes, which kind of means it is not really an object oriented language despite everything being an object. When architecting your code, you frequently want to create objects that are in complete control of their own internal data. In strict OOP, objects should always be in complete control of their data with everything accessed by getters and setters. Even in more data oriented design philosophies, there are data structures that will need strict control over access. And for private methods, running them at the wrong time can completely break an object in the worst cases. In python, you are on the honor system. Prefixing methods with _ or __ can send a signal to your linter that you shouldn't be using that method or directly accessing that data, but python will still run just fine. C++ gives you the option to encapsulate your data and control how it is accessed, ensuring things don't get changed in unpredictable ways. Methods and attributes marked as private cannot be accessed, the compiler itself will throw an error. And it even gives you the ability to mark functions and classes as "friends" for those rare use cases where a function needs more access to either a whole class or just a specific method or attribute.

Not just speed

The most obvious reason to use C++ over python is of course performance. To my knowledge, there are no languages that can go significantly faster than C++ (though of course many languages match it in speed), but that is not the whole story. I can do matrix multiplication using numpy and probably beat a naïve C++ implementation, but there is no way I could roll my own in python and expect it to work in anything close to a reasonably amount of time. Coding in python for years left me with a strong aversion to for loops and completely mistaken intuition on code optimization. Basically, the only way to make python performant at all is to rely on libraries that implement algorithms in C/C++ for you. Granted, implementing complex algorithms on your own is not necessarily a great use of time when libraries are almost guaranteed to do a better job regardless of language. However, learning a list of tricks for mashing your code into list comprehensions or creative uses of numpy will not make you a better general purpose programmer, it will make you a better python programmer. And whenever you move to a different language, all those tricks will not help you at all. In C++ or more performant languages, you might start to learn more about O notation, or how hardware works, and slowly build more efficient code with more transferrable skills.

Typed

This is more up to personal preference, which is why I left it for last. There are pages of debate on typed vs untyped languages, but I have fallen squarely on the side of strongly typed languages. A variable really has no business changing its type, I have yet to see a solid reason for it. Function parameters being duck typed does make sense, but this can also be achieved with templates in C++ where the compiler can make sure your use of the template is valid. Python does not even have specific variable declarations, the appearance of a new variable tells the interpreter to make a new object reference. This means there are no checks on whether a variable was already declared or not, it's entirely on the programmer to make sure they don't accidentally override a variable.

Why I still use python 90% of the time

Portability

Now, after all this I still use python, because not all the complaints about C++ are undeserved. As a compiled language, C++ needs to be built for each system you are targeting. Achieving cross platform functionality is not trivial, and each new computer architecture you target will require more troubleshooting. Python is not perfectly portable, because you have to make sure all packages you rely on, as well as their own dependencies, are compatible with your target architecture.

Speaking of packages, this is one area where I am torn as to which language has the right idea. C++ makes it a pain to manage multiple library dependencies while python makes it as easy as possible to bring more and more dependencies in. For C++, this means rolling your own code more often than your should, while for python it means watching your list of dependencies balloon out of control. Installing three packages with pip can easily mean twenty packages are actually installed, and if any one of them happens to not support Windows or Linux it can break everything. But even with this caveat, python I think still edges out C++ and the various attempts at package managers floating around out there.

Syntax and maintainability

While you shouldn't just focus on which language uses fewer lines of code, it's hard to miss the stark contrast in how much code I needed to write in C++ vs python for my examples at the beginning. Despite what I said above about python's speed getting in the way of learning how to optimize code, it's syntax makes it easy to write algorithms in a clear way. And python's ability to work well with C/C++ code means you can offload the heavier stuff to underlying libraries and have a clean and easy to read script sitting on top. Python is sometimes called a "glue" language or the "duct tape" of programming languages, and not at all derisively. It really does make scripting your code a very pleasant experience. And it does make it easier to get developers up to speed in python and therefore make your code more maintainable for the future.

Bad C++ is VERY_BAD

Finally, working in legacy python code might get confusing at times because of how flexible it is, but legacy C++ code can bring a developer to tears. Nothing makes my heart sink faster than opening up some source code and seeing nothing but MACROS_IN_ALL_CAPS everywhere. These are not always the fault of the developer, sometimes C++ just didn't have a feature to do what a developer needed when the code was written and it would be foolish to think you can just clear away all macros from a code base without breaking something somewhere. After you have learned C++ (and that beginner's course is 42 hours long just in lectures) you basically need to learn a whole new language: preprocessor directives. Some code bases have hundreds or thousands of lines of code just for their preprocessor directives, it makes one wonder why they are using C++ at all at that point when they are essentially coding their own language. And a lot of it can tie back to portability and making code cross-platform, which means it can't really be avoided unless you want to target only one OS and architecture. Knowing C++, in other words, does not mean you actually know how to read the majority of C++ out there because everyone tweaks the language for themselves.

Conclusion

Python is essentially the English of programming languages. It is easy to write nonsense that is still technically valid. Lots of my complaints (no constants, dynamic types, etc.) can be solved by programmers being disciplined. In a paradoxical way, python's simplicity and flexibility make it a pretty bad language to start in. It's simplicity is deceiving, because it is expecting you to keep track of what the compiler keeps track of in C++. And it's flexibility makes it very easy to make critical errors.

In the end once you know enough all languages boil down to personal preference, and I just like C++ better.

Understanding Objects from a Self Taught Perspective

rwalroth — Wed, 06 Jan 2021 00:39:15 +0000

When learning python or JavaScript, you may be told that "everything is an object" with little to no elaboration. Software architecture tutorials focus almost entirely on object oriented programming, but never really talk about what these things are or why we all use them. Especially coming from a higher level language like python, it can be very unintuitive what you are doing when you create a class and then use that class to instantiate an object. So I decided to write up a quick description of what objects are, what they are not, and when I think it is a good idea to use them.

What is an object?

Lower level - arranging memory

One of the downsides of starting out with a high level language like python is the computer hardware is completely abstracted away, including the actual data stored in memory. But to understand what an object is, you need to first know how data is stored (and if you want a nice fun intro to please check out Nand Game).

All data in memory is stored as 1s and 0s, in discrete blocks. Typically these blocks are 32 or 64 bits, each bit being a single 1 or 0 value (the "bitness" of the computer). All data, of all types, is stored this way, and that is crucial to grasp. In high level languages, you don't ever get to work with this kind of data but in low level languages like C++ these are the built in types such as int, float, or char. When you create a new variable, the computer grabs a block of memory and fills it with that data. In the picture above, the code on the left results in memory allocated on the right. It's important to note that these variables could be stored next to each other or not, there is no guarantee where they will end up. The location of that block in memory is its address, and that address is itself stored as a fundamental data type called a pointer. Now we get to the important part, since a computer can only store one thing in one block, and addresses fill an entire block on their own, how can a computer store more complicated data structures?

Lets say we want to store an array of 3 ints, like in the code above. In a high level language you create a list object and work with that, but in lower level languages you would instead ask the computer for 3 blocks of data and get the pointer to the first of the 3 blocks. Now you have gone beyond the scope of a single block, and you can do that because you know that the computer has reserved 3 blocks for you. Unlike before, the three blocks are guaranteed to be adjacent to each other. This is a "map" of where your data is, and is pretty straightforward. Traversing through your data is as simple as moving one data block at a time.

Now, let's say you have more things you want to store. Not just an int, but maybe an int and a char and a float. Well, you can ask the computer for three blocks adjacent to each other, and then traverse through it. This is essentially what a class is, a map of how to get to data in memory from a specified starting point. In the above example, all the data are fundamental types so a compiler could create this with three blocks of adjacent data but it doesn't have to. When you write a class, what you are doing is laying out what types of data you want to access when dealing with this object. When you create an object instance, the computer goes off and grabs some blocks of data, reserves them for you, and then gives you a pointer to get that data. The way it's laid out can get very complicated, maybe instead of data it just keeps a list of addresses. This is up to how a programming language is implemented, but in the end it's all the same. It's a blueprint for how to store data in memory, and every time you create an object the computer will store the data in the exact same way and therefore it will know how to get at all the data just given a pointer to the start and the map.

These pieces of data are called attributes, and in python, JavaScript and C++ they are accessed by the . operator (in C++ they are be accessed by the -> operator if using pointers). What the program is doing behind the scenes is going to that object's starting location, checking where that attribute should be located relative to that starting location based on the class, and then returning whatever is at that location in memory. You may have heard C++ is "unsafe", what that means is you get to directly manipulate pointers and could accidentally find yourself outside of the object data and messing with a different object's data. Python doesn't let you do that, you can only use python's logic for traversing memory which is very robust.

When everything is an object

So what does it mean when "everything is an object"? Well, in a statically typed language, there is a big difference between a fundamental type and an object. When you create a fundamental type, it's going to point to just one block of memory. In principle, you could swap this with any other fundamental type and there are methods for doing that. But when you create an object the computer will grab a set of blocks for you and populate them with data. Some of these blocks will be addresses and some will be fundamental types. Some of them will be addresses to other objects which the computer will also need to allocate. In python and JavaScript, you are not given access to fundamental types. You always create a more complicated object.

Methods

So far I have talked about objects which only hold data. But there is another half to objects of course, methods or member functions. Lets use the following example code for a class that stores some data and fits a function to that data. First, implemented without any classes:

myDict = {"data": [], "fitParams": [], "fit": [], "res": []}
def data_function(x, *params):
    # The function we are trying to fit to a data set

def fit_data(myDict, data_function):
    # Run a fit routine, store parameters, fit, and 
    # residual data in fitParams, fit, and res

def calculate_val(myDict, data_function, x):
    # return the result at x for the predicted function

We have a dictionary with some specifically named data types, we have some functions which accept that dictionary and a function as arguments. Now lets do the same thing with a class:

class myFitter():
    def __init__(self, data, func):
        data = data
        fitParams = []
        fit = []
        res = []
        data_function = func

    def fit_data(self):
        # Run a fit routine, store parameters, fit, and 
        # residual data in fitParams, fit, and res

    def calculate_val(self, x):
        # return the result at x for the predicted function

Take a look at the arguments in the class methods. You'll notice that the main difference is myDict is now replaced by self. Essentially, these two are exactly the same. In fact, for languages written without any classes at all this is a pretty common way to write code. First define how data will be stored, then write a set of functions which are all grouped together by their shared use of data. In python, there is even a __dict__ attribute which itself is a dictionary keeping track of all the class attributes. Getting back to the lower level, the information needed to create an object is the class. This tells the computer what memory is needed and where the program expects to find it. This can also include pointers to functions that will operate on this data. The . operator will direct the computer to some location in memory based on the name, and retrieve either some data or a method. A special aspect of member functions is that they are implicitly or explicitly handed the pointer to the object that called them. In other words, they know they are members of a class and also know who is calling them. That means they can access all the other member functions in the class as well as all data stored in the object.

Inheritance

Inheritance just means that instead of drawing your map from scratch, you start from a previously drawn map and extend it. There is no difference between copy and pasting all the code from the base class and inheriting from it, especially in languages like python which lack private members and attributes. They are a nice way to reuse code or make minor variations on an existing class.

What is an object not?

They are not real world objects

Objects are frequently introduced by comparing them to real life objects, like chairs or buckets. The problem is that computers don't actually store chairs and buckets, they store 1s and 0s. This is something completely glossed over in coding tutorials, but it is very important to understanding objects - objects are convenient ways to store data. Remember, an object is just some data and some methods that manipulate that data. I highly recommend this lecture by Catherine West for a more expert look on why this is a bad way to think about objects, but in brief real world objects interact with each other in ways completely different to how computer objects interact. If a person picks up a glass, the glass's positional "data" has been changed. But who changed that data? Not the glass itself. But in OOP, you would expect the glass's data to be private and the glass would always be responsible for moving itself. And this breakdown goes further than that, and even has computer performance implications.

You likely won't care about the performance hit, but in terms of designing your code it can be problematic to think about them this way. A well designed object has attributes that are all connected to each other an methods that are all needed and related. If you make a "chair" object, it might have a material, position, size, weight, price, style, and age. Do you ever need all these at once? Maybe style and age get used together with price, but does the position affect the price? Does weight affect age? In this case, why group all these attributes together at all?

Lets say you have a furniture store, and you want to keep track of furniture. You create a chair class, a sofa class, and so on. They each have different types of data, and you then store all the inventory in one large master class or array. Except you only care about the data. You might just want a list of prices to get an approximate inventory valuation. Or you might just want to know how much space you have available for more stock. Instead, you can have an array of position data, an array of prices, an array of types, etc. This is the "array of structs vs struct of arrays" debate if you want to read further, because there is a case to be made for both. In most cases, however, you will want the struct of arrays approach.

They do not make code cleaner or more performative

One reason I see frequently cited for using objects is to avoid "spaghetti" code. The claim seems to be that by using objects and inheritance you can somehow avoid a tangled set of functions which depend on each other in weird ways. This is not true at all. Classes can very easily become spaghetti if your functions are not clearly written, or if a class ends up with 100 member functions and 20 data attributes. Even worse, you now introduce the issue of complex inheritance hierarchies where a class inherits a class which inherited a class and so on. How do you know which methods are safe to override? How do you even know you're overriding a parent method without double checking the whole family tree?

So then why classes and objects?

Organizing data

Occasionally you might come across someone derisively referring to a programming language feature as "syntactic sugar", meaning it just changes syntax with no underlying performance implications. But every feature of every programming language, right down to the use of letters and numbers, is syntactic sugar. If you're not writing assembly code, you are using syntactic sugar. And that is all classes are, syntactic sugar. Take the following example:

def func(a, b, c, d, e, f, g, h, i, j):
    # Do some stuff with lots of variables

myDict = {'a': 0, 'b': 2 ...

def func2(myDict):
    # Do the same stuff but with one dictionary

class Obj():
    def __init__(self, a, b, c, ...
        a = a
        b = b
        ...

    def func3(self):
        # Do the same stuff but now no arguments at all

The first example is extremely clunky, no one wants to type that many parameters every time a function gets called and sometimes you do need that much data. The second example groups the data together so you can conveniently pass it to a function. This is much better, and helps keep the code more organized too. The final example adds nothing at all, just makes a class. But if func was particularly complicated, you could use the class to break up one big member function into a few different member functions to improve clarity. But it is important to not make objects too large, otherwise they get unwieldly quickly. Think about objects as convenient ways to organize data, and build them around that.

You can implement complicated data types

Even without taking a data structures course, you might want to build your own data type. Maybe you have a list of dates, and you want to be able to change all the dates at once. You can make a class which wraps a simple list, and have a set_new_start method which sets a new starting point that all dates reference. Maybe you want to store absolute and relative dates. An object helps you control how data is stored and modified.

They help modularize larger code bases

For simple tasks an object should be kept as small as possible, but objects do have one use case I know of where they will get very big and complicated. In larger code bases, with thousands of lines of code, objects are convenient ways to pass around large parts of the software itself. For example, lets say you have a GUI you are building to analyze data. You might have a main window, some inputs, and a display. The main window can be an object which also handles data storage and be a parent to the inputs and display. It can pass messages between these. And the inputs might do some input checks before passing along the message. Breaking code out this way lets you assign one person to one widget or group of widgets. The interaction between objects is well defined, so the individual developers get more freedom in building the internals of their code without worrying about stepping on someone's toes.

Conclusion

Objects are a great tool for writing code, but not a goal in and of themselves. I highly encourage you to try your next hobby project with no classes at first and see how far you get, then start bundling functions and data when you see places that it would help make the code easier to read.

I hope this was useful, let me know what you think!