{"id":6329,"date":"2025-04-20T18:06:04","date_gmt":"2025-04-21T02:06:04","guid":{"rendered":"https:\/\/wonghoi.humgar.com\/blog\/?p=6329"},"modified":"2025-12-01T01:47:39","modified_gmt":"2025-12-01T09:47:39","slug":"concepts-in-c-that-does-not-apply-to-python-or-matlab","status":"publish","type":"post","link":"https:\/\/wonghoi.humgar.com\/blog\/2025\/04\/20\/concepts-in-c-that-does-not-apply-to-python-or-matlab\/","title":{"rendered":"Concepts in C++ that do not apply to Python or MATLAB"},"content":{"rendered":"\n
Static Data Members<\/h2>\n\n\n\n
In Python\/MATLAB, data members are called properties. It’s called (data) member in C++. I’ll use these names interchangably when comparing these languages.<\/p>\n\n\n\n
Python and MATLAB have the concept static methods, but static properties (data members) doesn’t really exist in either language. <\/p>\n\n\n\n
Python’s properties have a split personality (class AND instance), so it’s not like C++ that you choose between class XOR instance. Therefore I call those class variables because in C++, static variables do not have split personality: either you are classwise (static<\/code>) or not. In C++ (or MATLAB) you don’t have both cases sharing the same variable name so a class variable can be shadowed by an instance variable.<\/p>\n\n\n\n
As for MATLAB, there’s no Static<\/code> property. The only classwise properties allowed is Constant<\/code> property. TMW (creator of MATLAB) decided not to allow non-Const<\/code> classwise\/static properties because of this web of rules:<\/p>\n\n\n\n
\n
A.B = C<\/code> can either mean 1) [Variable] write a new struct A<\/code> with field B<\/code>, or 2) [Class] attempt to write to property B<\/code> of class<\/strong> (not<\/strong> instance of) A<\/code>.<\/li>\n\n\n\n
If a class (definition) A<\/code> is loaded into the current workspace, allowing case #2 might throw users who intended to make a struct A with field B out of nowhere off.<\/li>\n\n\n\n
MATLAB gives variables higher priorities than function\/classes, so case #2 has to be struck down to make it unambigious.<\/li>\n\n\n\n
By making A.B<\/code>, a classwise access to field B, either read only (Constant<\/code>) or tied to instances a=A(); a.B=C<\/code>, MATLAB avoided the situation of A.B=C<\/code> while A<\/code> is a class (case#2) so A.B=C is unambiguously writing to a struct field (case#1).<\/li>\n<\/ul>\n\n\n\n
I know. This is quite lame. Matrices are first class citizens in MATLAB while classes are an after-thought that isn’t really a thing until 2008. You win some and you lose some whether you choose MATLAB or Python.<\/p>\n\n\n\n
The official TMW workaround is to use a Static<\/code> method getter\/setter (not dependent properties because it only works for instances or if what it depended are exclusively Constant<\/code> properties) with persistent<\/code> variable holding the internally data that’s meant to be static. This is very convoluted and it sucks. I’d call it a weakness of MATLAB.<\/p>\n\n\n\n
Constant properties in MATLAB are static const<\/code> (classwise-only)<\/h2>\n\n\n\n
In C++, const properties (data members) can be either instance bound or classwise (static), which means instances could be initialized with a different set of constants. <\/p>\n\n\n\n
Instance-wise constant data members is possible in C++ through (member) initializer lists, which happens to be the only route for private constants as public constants could also<\/strong> be list (including brace) initialized (in newer C++ such as C++11).<\/p>\n\n\n\n
Constructor is not a first-hand initializer in C++ (directly assigning memory with predefined values). Members are fully constructed in C++ (just not necessarily with the values you wanted) by the time you get inside the constructor function. Therefore, in C++, constants and references (things that cannot be changed) for instances<\/strong> must be done in (member) initializer lists right before the constructor.<\/p>\n\n\n\n
Only static const<\/code> can be optionally<\/strong> defined directly at the class with =<\/code> sign since C++11. Before then it only worked for integers as it was enum under the hood with a primative compiler design. Otherwise you forward declare<\/strong> the data member (without specifying the details) in the class C<\/code> such as static const T x<\/code>, then define it (assign the value) like T C::x = 42<\/code> outside the class definition.<\/p>\n\n\n\n
In MATLAB, Constant<\/code> properties are classwise-only (in fact, it’s the only kind of Static<\/code> property allowed as discussed in the first section). You simply declare the value at the class definition with =<\/code> sign just like the fast way to type static const<\/code> in C++11 because there is no concept of (member) initializer list in MATLAB so you can modify how consts and refs are stamped out, not remodel them in the constructor after they are already made.<\/p>\n\n\n\n
Accessing constant properties with an object instance has to be a shortcut for classwise constant in MATLAB, while it depends on whether the const<\/code> is static<\/code> in C++.<\/p>\n\n\n\n
In Python, everybody is a consenting adult (there’s no native concept of const<\/code>). Scream your constants in ALL CAPS and hope everybody act like a gentleman and not touch them. Lol<\/p>\n\n\n\n
Static Native Getters\/Setters<\/h2>\n\n\n\n
C++ does not have native getter or setter using a data member’s name so the said data member do not store states but instead act as a proxy (potentially interacting to other state-holding data members).<\/p>\n\n\n\n
Let’s say the variable with a native getter\/setter in question is x<\/code>. <\/p>\n\n\n\n
In MATLAB, this feature is called Dependent<\/code> properties, where you define members under properties (Dependent)<\/code> and the getter function is named function get.x(self, ...)<\/code>.<\/p>\n\n\n\n
In Python, @property<\/code> decorator mangles your function with the same name as the dependent member, aka def x(self, ...)<\/code> so the functor can call the corresponding getter\/setter without the function call round brackets ()<\/code>.<\/p>\n\n\n\n
However, in both MATLAB and Python, dependent data members are mainly aimed at instances (objects created), not class-wise!<\/p>\n\n\n\n
In Python, it’s simply impossible to stack @staticmethod or @classmethod with @property. I tried doing that and Python just declared the function name (dependent property name) a property<\/code> object so when I call it (without round brackets for function calls of course), it merely shows “<property at 0x...><\/code>‘.<\/p>\n\n\n\n
The case of MATLAB is a lot weirder. It’s a web of rules for that are based on seemingly unrelated reasons which created a catch-22 to mean dependent properties are instance-bound without means to access it classwise:<\/p>\n\n\n\n
\n
MATLAB doesn’t have classwise properties that are not Const<\/code> properties (aka no Static<\/code> data members\/properties) to avoid breaking backward compatibility (see the first section of this post for the web of rules that caused it).<\/li>\n\n\n\n
In C++’s lingo, MATLAB has no (mutable) static<\/code> data member. The only nearest thing is (immutable) static const<\/code> data member (which is called Constant<\/code> property in MATLAB).<\/li>\n\n\n\n
MATLAB does not have instance-wise constants (see above)<\/li>\n\n\n\n
Dependent<\/code> property in MATLAB is neither classwise or instance-wise, because the concept itself is a method (function member) pretending to be a property (data member). More precisely, it’s an extra level of indirection that dispatches getters or setters depending on whether it’s ‘read’ or ‘written’<\/li>\n\n\n\n
MATLAB not treating properties (data member) and methods (function member) the same way (when it comes to whether it’s class-bound or instance-bound) created an dilemma (identity crisis) for Dependent<\/code> property. <\/li>\n\n\n\n
Despite Dependent<\/code> property is really a method in disguise, its getters\/setters not allowed to take on a Static<\/code> role like other methods because it claimed to be a property (data member) so it’s stuck following the more restrictive rules that applies to properties (aka no static<\/code>)<\/li>\n<\/ol>\n\n\n\n
Without knowing the underlying rules above, the implications are less than intuitive (makes perfect sense if you know what constraints MATLAB is working under that made it nearly impossible for a sensible use case where the user simply wants to create a shortcut for computing with classwise\/Const<\/code> properties):<\/p>\n\n\n\n\n
MATLAB’s rules requires any property that are not<\/strong> Constant<\/code> to be accessed exclusively through instances. <\/li>\n\n\n\n
A Dependent<\/code> property is not a Const<\/code> property, so it’s considered an instance-based member. <\/li>\n\n\n\n
This implies Dependent<\/code> data member can only be called from an instance (regardless of whether you’re trying to do it from within the same class or outside the class).<\/li>\n\n\n\n
Since Dependent<\/code> property is defined to be instance-bound, the instance object (self<\/code>) is passed to getters\/setters as the first argument and the definition of the getters\/setters has to expect it so it’d be like function get.x(self, ...)<\/code>, just like all instance-bound methods.<\/li>\n\n\n\n
There’s nothing that says such getters\/setters must use the self<\/code> passed to it. However, if you use constant properties, it doesn’t matter where you call from the self<\/code> (object instance) or the class name since constants are classwise-only in MATLAB to both syntax refers to the same thing.<\/li>\n<\/ol>\n\n\n\n
RAII available in C++ and MATLAB but not Python<\/h2>\n\n\n\n
Garbage collector is a concept only when you are allowed to make multiple aliases for the same underlying data, and don’t want to meticulously keep track of who’s ultimately responsible for winding it down and when.<\/p>\n\n\n\n
In particular, garbage collector has the lattitude to not clean the object right away when the reference count goes down to zero. shared_ptr<\/code> (an automatic memory management technique) promptly cleans the object when the reference count touches zero. Therefore garbage collector can procrastinate painful release (cleanup) process so the program doesn’t have to frequently stumble to do the cleanup.<\/p>\n\n\n\n
C++ chose not to use garbage collectors (as class destructors running at a non-deterministic time breaks RAII). Python choose to embrace it at the expense of breaking RAII. MATLAB is kind of in between yet the way MATLAB does it does not break RAII, but it’s not obvious.<\/p>\n\n\n\n
![\"\"](\"https:\/\/wonghoi.humgar.com\/blog\/wp-content\/uploads\/2025\/04\/image-1-1024x283.png\")
<\/a><\/figure>\n\n\n\n