I’m taking a short hiatus for the following 4 weeks due to personal commitments as well as the articles themselves running out of steam. I haven’t been bottling things up enough for me to rant the way I used to and therefore perhaps it’s time for me to take a break for a while.

I’ll definitely return with more interesting articles and possibly more rants as well.

Many thanks for reading my articles!

Regards,
Jeremy

This week I’ll talk about the 3 main types of projects that are created with C/C++. We’ve perhaps heard of the term library, framework and engine. However, for this post, we’re talking about a low level set of articles which defined a certain development strategy.

Not everything is built directly as an application. Some applications have dependencies, some have extensions during run time, while others have a mix of both.

Whatever it is - there’s a need to understand what their differences are so that we know when to use what. Read on the find out more.

Introduction

So why are there applications (.exe), static libraries (.lib or .a) and Dynamic-linked library (.dll or .so)? The reason is simple - some information is known before execution, some information can only be available during execution.

In Windows, a DLL is also an application indirectly. Which is why sometimes you see a DLL runner known as rundll.exe. This file allows you to run a DLL alike an application.

In Linux or Solaris, a DLL equivalent is known as a Shared Object thus having the extension of  (.so).

Static Libraries on the other hand, are programs that are pre-defined and pre-declared for an application to use. They cannot run on their own and usually require an application to fill up the rest of the blanks.

Applications (.exe)

The first thing we were taught in schools when building applications in C is to include this header file known as stdio.h.

Most people will understand that this is a requirement, but will not fully understand why is it a requirement.

Reason is very simple. All applications need a starting point. This starting pointer is usually offered by runtime libraries such as the CRT. Thus if you attempt to build any applications without defining a main() for example, the linker will complain that there’s something unresolved.

This is how the CRT works. It’ll call your main() to kick start the whole process.

Static Libraries

These guys on the other hand, are functionalities that are built in. For one, CRT itself is a static library as well even though it uses some dynamic libraries during runtime (for Windows).

A static library usually comes in a package as follows:

1) A single .lib or .a file
2) A bunch of header files

Static libraries also have several special characteristics. I’ll list 2 below:

1) They do not need to link.
2) They allow declarations without definitions.

What are declarations and what are definitions? Well… I guess that’s up to you to find out right? After all, if you do not know this 2 terms, you’ll probably have a hard time reading this article as well.

DLLs(Dynamically-Linked Libraries)/Shared Objects

Although it sounds as though as it’s a static library loaded during run time, the truth is far from it. A DLL is essentially an application by itself. It may share a heap based on the CRT used for compilation, ie, (Multi-threaded Debug DLL, Multi-threaded DLL), but there’re a few things that they’ll definitely have on their own.

For example: private heap.

Thus the notion of a singleton that exists one and only in an application is only as true as the application itself. If the application extends by loading other dynamic modules during run time, that module does not have inherent access to the application’s private heap.

That means, don’t expect to access the same singleton instance when you call getInstance().

This however, is usually ignored since we’re encouraged not to put any data attributes into singletons due to its non-deterministic order of destruction.

Dynamic libraries however, have the distinct advantage of quick builds and deployment. Since the DLL needs only what it needs during linking, yes DLL needs to be linked, the overall build time is usually much shorter than the static library or the application. Subjected to project size of course.

Since the DLL is only linked during runtime, there’s no need to link into the main application everytime a change is made.

However so, DLLs have its disadvantages as well. In particular to the versioning of the DLL. If one or more DLL uses the same set of base classes and that the application’s base class binaries are newer than the ones linked onto the DLLs, then there’s a chance of a code misalignment.

When that happens, even if functions like GetProcAddress() works, any calls to the base classes will have an undefined behavior. Reason is because, the memory address of the code memory is mapped. Every function or method has an absolute code address. This mapping is changing whenever a method/function is added or removed.

This causes the expected function/method address to go off alignment and illegal memory access thus causes the application to crash unexpected without any clues.

The second level of impact is when the codes of the base classes were changed. This change may reflect a change of logic and thus produce erroneous results. The results can range between just a weird value to a wild or dangling pointer, in which will lead to a crash as well.

All these problems are associated with the symptom known as DLL HELL.

And such problems are extremely hard to fix unless there’s a strong technical lead to highlight the possibilities. On top of that, if the DLLs are from third party libraries, good luck!

Misuse

I don’t know if it’s just me or what but I usually encounter a few companies who tend to claim that they link to the DLL during the main build process.

As far as my limited knowledge can tell me, it doesn’t make any sense to link to any DLLs during the main build process.

If that’s the case, the DLL should just be a static LIB instead.

It’ll be a shame however, if these people continue to believe that they’re linking to a DLL during the build and then continue to load the DLL during runtime.

That’ll end up having two separate sets of binaries loaded and they’ll not even know exactly which piece of code is used! In short, isn’t this a recipe for disaster?

Conclusion

Finally, I’ll just like to round up the use of the 3 different types of build outputs.

An application is what it is, a standalone and executable application. It requires all compilation to work (except for template codes that are not used) and requires all symbols to be linked before it can be produced as an executable.

A static library is a collection of preprocessed object files which contains usually, logic and workflow. It may not necessary have all the symbols defined even when there’s declaration for it. A static library requires all codes involved to be compilable but doesn’t require any linking.

Finally, a dynamic linked library is also an application by itself but allows itself to be loaded as part of an application as a module. It requires all codes to be compilable as well as all symbols to be linked as well.

A DLL is extremely suited to be implemented with the Bridge Pattern in OO, where GetProcAddress retrieves a function that creates an instance of itself and returns a pointer of its interface to the caller.

The caller will then access all available functionalities based on the promise of the interface.

This allows multiple DLLs to implement the same interface without having the application to know of their existence at all. However, I won’t go into details on how to implement this just yet.

Anyway, I have a plane to catch! Have a nice week ahead and yeah - to all Singaporeans (as well as myself), Happy National Day!

Signing off,
Jeremy

This week I’ll address an issue that is common in developers who have the power to decide what goes in and what doesn’t in an application.

While many developers have lamented at the technical ignorance of their managers who had made certain decisions beyond technical comprehension and always seemingly appears to be an act of stupidity, technical naivete or even worse, a decision taken on their behalf; if something goes wrong, the developer is responsible.

So… what has this gotta do with “cool”?

Well, let’s begin with looking at developers who make the decisions. To know more, read on…

Introduction

First of all, we need to understand how decision makers think in order to anticipate the likely actions they’re going to take. Of course, there’ll be exceptions, special cases or even illogical or unexplainable decisions made from time to time but there’re a few things that always happen.

When we talk about “cool”, it’s usually associated with the “coolness” of a particular feature, be it graphical, audio, input, network or anything that is on the technical side of things.

Definition of “cool”

We have to ask ourselves, why does a particular feature appear to be “cool”?

The answer lies in the characteristic, role and mind set of the decision maker. If the decision maker is a technical person, then very likely, the definition of “cool” would be one that can make his/her technical capabilities shine and proven due to the success of implementing this feature.

However, if the decision maker is a management person, then the definition of “cool” will be probably refer to the ability to better manage his/her team.

Lastly, if the decision maker is a sales person, then the definition of “cool” will be the ability of this feature to increase the sales revenue.

In short, everybody has a different perspective when it comes to “cool”. The crux is whether this notion is applied correctly so that the project doesn’t freeze.

A project freeze refers to issues, bugs, regression errors and other related errors that causes the project to stall for an indefinite amount of time until those problems are resolved. This of course, isn’t good for the technical, management and sales people.

Constant truths

Before we even think of adding a cool feature into an application, we need to know several constant truths. Here’s a few of them in general:

1) You or your company is running a business.
2) You’re working on a project which has a finite scope and time frame.
3) Your company needs funding to survive and pay you.
4) Your company will eventually need to sell a finished product. Whether it’s a product to be given to a client or in-house developed product for general consumers.
5) Your project must be workable, deploy-able and usable.

So, does your cool feature have the potential to disrupt any of the above-mentioned points? If the answer is yes, then you’ll better think thrice before committing the changes.

Does size of role matter?

The quick answer is - no! Size does not matter in roles that help develop the application. The reason is very simple. If everyone has the power to affect the outcome of the project, then everybody is responsible.

If a developer is given the power to introduce any features or libraries as he pleases, then this developer must be matured and rational enough to consider the impact factors before committing the changes.

Let me give you an example.

Traditionally, C++ programs mostly use standard libraries and near-standard or de-facto libraries such as boost to help, in fact, boost the productivity of the whole team.

However, there’re cases where such libraries are not used due to specific reasons.

In this particular case, a developer actually introduced the use of boost library in the middle of a project which has its own capabilities. While the intentions are good, this developer forgot to measure the costs of linking the application to such a huge library.

As we know, boost is not a trivial static library. It’s alive with templates as well as other preprocessors to start up the entire library.

As a result, the application’s final execution binary size shot up to nearly 200%. On top of that, compilation of the entire application now takes twice as long. Worst of all, he only used like 1% of the boost library’s functionalities.

Although this isn’t a case where it’s cool but it froze the project, it’s a good example to demonstrate that such careless and reckless change or addition will inevitably affect the project progress.

When progress is affected, all the truths I’ve mentioned will be affected as well.

Boost library is cool as long as it’s used right from the start. It may not be suitable if an existing boost-like framework/library already existed. You’ll probably end up with 2 copies of similar functionalities instead.

Conclusion

Finally, I’d just like to say that the only thing that is cool is when the application is developed, finished, polished and published.

If a team even reaches a stage where their application reaches the stage of publication, then it’s a big step forward because by selling the product, it gives the team the extension required to build even better, greater and more efficient applications.

Otherwise, if a developer decides to selfishly fall back on his/her own comfort zone by introducing features that are familiar only to him/her, the project progress may suffer badly or even stall in the process of fixing the issues created by this decision.

Some may argue that they can rollback with a source control. Agreed, however it’s still not a trivial task. Don’t forget that you need to test as well. Regression testing, stability testing, coding standards and so on. How do you even know that the rollback itself was done correctly?

Therefore, a feature, no matter how big or small, simple or complicated, must go through a proper process of identifying potential impact issues, design issues and effort estimation in order to frame this feature up into something that can be contained.

While I’d want to continue, which I’ll probably do in the next few articles, it’ll probably be best for me to sign off for now.

Therefore, have a great week ahead!

Signing off,
Jeremy

This week’s post came late due to my hectic schedule and I suspect that I might have to even go for a miss for next week’s post.

In any case, I’ll try my best to post an article every tuesday.

This week’s post is very simple - limits.

A lot of people don’t know theirs. Do you know yours? Read on…

Introduction

The limits we’re referring to are actually very simple things such as native types. For example char, short, int, long, float, double, etc…

So, most of us roughly know what are the limits of these types.  But do we really know?

Most of the time we’ll see the compiler throwing out warnings, telling us not to mix signed and unsigned types. I’m very sure that this is one of the warnings that is almost certainly ignored totally.

In the following paragraphs, I’ll talk about these limits and how they affect our daily applications and development decisions.

Signed and Unsigned

So what’s the difference? Irritating isn’t it? Well … not really if you know what to do with it.

First of all, unsigned types do not apply to floating point types. They’re already tied up with storing the mantissa and decimals.

Secondly, unsigned types cannot be negative.

Thirdly, unsigned types have twice the limit range in terms of maximum positive number than their signed variants.

Lastly, in most cases, bit shifting is safe across most platforms for unsigned types compared to signed types.

As for signed types, there’re a few characteristics that one should know.

Firstly, they have a negative range. Based on 1’s compliment, their negative range is always 1 numeric more than their positive range.

That is, for example, signed char, or simply char, positive range is 0 - 127, the negative range is -1 to -128.

Secondly, their first most significant bit is used as the sign indicator.1 for positive, 0 for negative. See here for more information.

Lastly, this - I’m not so sure but I’ve heard that bit shifting doesn’t work properly on some platforms. We’ve tried it on Visual Studio 2005 without any issues. Basically, the sign bit is first taken out, then the rest of the bits are shifted without the sign bit. Then the sign bit is set back to the most significant bit after it’s done.

Limitations

Every primitive type has a limitation in terms of how far they go. Going beyond these limitations doesn’t lead to a crash. At least not for C++.

Instead, when the maximum limit of a primitive type is reached and that the limit is crossed, the type simply rolls over and start all over again.

For example, let’s take a look at the unsigned char type again. It has 8 bits and thus looks like:

0000 0000

When it’s full, it looks like:

1111 1111

And that’s 255 in value. (Consider 0 as a number as well).

What happens when you add 1 into the unsigned char? Let’s find out:

 1111 1111
+0000 0001
 ---------
 0000 0000

Do note - this is not an OR operation. OR operations always appear to behave like “add” operations. But it’s not true.

In this case, the bits will simply flow over and. The expected answer was supposed to be:

1 0000 0000

But, since unsigned char only has 8 bits to hold all the data, that 1 last most significant bit is truncated and thus resetting the value to zero!

Live Example

Let’s take a look at live example. The following example that I’m about to share is based on an signed short.

We know that short is usually 2 bytes long and since it’s signed, the ranges are:

0  to 32767
-1 to -32768

So what happens when I set -1 as the amount of credits for the game below?

-1 as credits works in Dune 2

But, do you know what’s binary state of -1 in a signed short type?

It's 1111 1111 1111 1111 !!!

So what happens when I reduce credits for building structures?

When you use credits, the number goes up instead even when it's negative due to the bit arrangement.

Let’s take a look at the binary state of -321:

1111 1110 1011 1111

So, there’re plenty of bits to spend before reaching:

0111 1111 1111 1111 = 32767

Thus, you’ll have as much as 65536 credits to build your army. The hack is really simple. You’ll only need to modify the file scenario.pak in the game directory without modifying the format of the file (best done via a hex editor) and you’ll get what you want!

I won’t go into details though

The reverse, however, happens as well. This is when the harvester collects enough spice, which I think it’s around 600 credits per bulk and returns to the refinery.

So … if you take -321 credits and add it with 600 credits, what happens?

You’ll get 279 credits! In binary this is how it looks like:

0000 0001 0001 0111

In terms of binary operations, it’s correct because the bits have overflowed at the last possible bit, which is,

1111 1111 1111 1111 = -1

Thus, as much as the hack has promised you, it’ll also take it all away from you in an instant. It’s just like karma man… especially when you’re immersed in attacking the enemy base and forgot to tend to your harvesters who diligently harvest all the spice in the area, only to find that by doing so, it inadvertently causes you to lose a potential 60,000+ credits!

Example in a bank

I’ve once encountered a strange bug when I was working for a bank which I won’t name. Basically, this account has like 10,000,000,000 in his account. This is like 10 billion; it’s a test account by the way.

It’s stored nicely in the database.

So, the code retrieve this value and stored into an unsigned long type. But the value that’s represented in the unsigned long is wrong.

Note that the unsigned long in this case is 32-bits long.

So why is the value wrong?

Reason is simple - the 32-bit long type can only store a number up to 2^32, which yields roughly around 4.2 billion.

In this case, the binaries would have overflowed several times before ending up with whatever value it’s in.

You can try it in your IDE and see if you can get the weird result.

How to tell the maximum size?

Very simple. There’re 2 methods in which you can derive the maximum size.

1) Perform a sizeof(type) ie, sizeof(int) and get the byte size, then perform a 2 power of byte size to retrieve the maximum range.
2) Read up on the specification of all the primitive types via documentation and perform the same 2 power of byte size to get the maximum range.

However, do note. For signed variants, always use a 1’s compliment to derive the negative side as well as to divide your results by 2 first.

For example, signed short range is 0 to 32767, -1 to -32768. It’s unsigned variant is 0 - 65535.

Conclusion

In conclusion, knowing your limits of your primitives will serve you a long long way in your development or programming career.

It’ll also arm yourself with things to look out for, especially suspicious numbers that are exceptionally large.

Without all these knowledge, a programmer is blind when choosing primitives and will be confusion by the range of selection available to him/her.

I’m sure some of you like myself, would have asked, why need short when we have int and why need int when we have long?

A short reason for it is - in the past, data alignment is packed to the brim. That is, unlike nowadays where struct alignment is defaulted at 8 bytes for maximum memory access efficiency, it was as low as 2 bytes during the 16-bit computing era. This help conserves memory usage per object instance and will allow an otherwise un-executable application to be run on machines with very little memory.

We’re talking about memory as small as 640kb where RAM takes on an appearance of a multi-legged bug.

Yeah, those were the old days of floppy disks, small hard drives and very small RAM capacities in the 8086 era.

Nevertheless, the significance of primitive limits now extends to design specifications where a certain variable is limited in range for design reasons.

Knowing it can help save you from getting into weird logic bugs which are hard to detect unless you’re a binary genius.

With that, I’m signing off for this week.

Have a great week ahead!

Signing off,
Jeremy

Ok. This is really an object oriented post. Do forgive me if I’m not as guru or as strict as many OO purists out there. Remember that I do have to balance between a perfect design and a usable design.

In this article, I shall discuss about a topic taught in C++ Beginner level training.

Aggregation and Composition, what’s so different about them? Do I need have a good grasp of English in order to do it properly?

Read on…

Introduction

Many of us have been taught more or less in Object-Oriented Programming, which is a popular programming methodology used by many programmers and represented by several major languages including C++, Java and C# to name a few…

In OO, there’re many terms, some of which sounds alike, while others sound very sophisticated till it’s misunderstood.

The notion of K.I.S.S (keep it simple and stupid) seems to contradict many of the OO terminology in terms of understanding. Or does it?

We know that OO has quite a few terminologies, each representing a part of OO or a way of doing things. Today, we’re just going to take a look at Aggregation and Composition because I somewhat believe that the so-called thin line that separates them is what that confuse programmers who are not profficient in English.

Composition

Let’s take a look at composition first.  Now in a class, there’re several basic building blocks that we know can exists. For example:

1) Access level Modifiers
2) Attributes
3) Methods

I shouldn’t have to explain what are modifiers. If I do, then this article is probably not meant for you.

Next, we have attributes and finally methods.

It’s basically telling other programmers that this class is composed of the following protected, private or public attributes.

So what does composed of mean? It simply means that the article is described or specified explicitly as being an integral part of the class. Which means to say, whenever an instance of this class is instantiated, the specified attribute will always be valid after construction and is part of the object.

“Valid” here means that the attribute itself is instantiated as well regardless of whether it’s a native, system or user-defined class type.

If we go deeper, this is what it’ll mean:

1) If the attribute is 12 bytes long (user-defined structure for example), then it must not be a pointer or reference to qualify as a composition.
2) Since it’s 12 bytes long, under struct alignment, it’ll take up 16 bytes of memory.
3) The object size is thus affected by the size of user-defined type.
4) Since it’s not a pointer or reference, the attribute is guaranteed to be instantiated either by its default constructor or a constructor chosen by the main class’ initialization list.

In such cases, when the copy constructor or the copy assignment operator is called, the default behavior will be a deep copy and will most likely remain as long as it’s a composition.

So in summary, an attribute composition is one that is part of or more correctly, composed of the class and is more likely to be available after construction and by design, will be deep copied.

Aggregation

Next, we’ll talk about aggregation. First of all, the very first confusion we’ll encounter is that, to qualify as an aggregation, the attribute must also be part of the class as well. The second confusion is, it seems as though as all natives are composition, all classes are aggregation.

Now, this confusion is exceptionally true for languages like Java and to some extent, C# as well. This is because, the notion of creating a stack object is virtually impossible in Java but somewhat possible in C#.

Just think, how do you create a user-defined object in Java (which is mutable)?

UserClass obj; //WRONG!
obj.a = 0; //BOOM!

The right way would have been:

UserClass obj = new UserClass(); //instantiated
obj.a = 0; //now it's usable

In C++, it’s very clear cut. In my previous article, if you should ever use the new operator (Yeah, new is an operator, not a special keyword) the object will always be created in the heap. If not, it’s on the stack yeah? Well, it depends.

Here’s the brain twist:

1) An object and its attributes are always created in the heap if the whole object is instantiated with the new operator.
2) An object and its attributes are always created in the stack if the whole object is declared in a function or method as it is.
3) If an object is instantiated with the new operator and its attributes are declared as it is, then the attribute is still instantiated as part of the object in the heap.

So, what has all these have to do with aggregation?

Well, basically, to qualify an attribute as an aggregation, that attribute must be a pointer or reference. We’re talking about C++ pointer and C++ reference.

Next, if an attribute is aggregated, there’s a chance that this actual object must not even exists.

Last but not least, an aggregated attribute is an association, not composed of.

To clear up the confusion, the only part that is composed of in an aggregation is the pointer itself, this applies to references as well even though they’re just aliases with a fixed referent. You see, a pointer takes up 4 bytes on a 32-bits machine. This 4 bytes must be stored somewhere right?

In this case, it’s stored as part of an attribute in the main object. Thus, the size of the aggregated object does not affect the final size of the main object since the size of the pointer will always remain constant (4 or 8 bytes for 32-bits and 64-bits respectively)

Lastly, an aggregation object is always a foreign object or to be clear, an object that is instantiated separately in a foreign location. While the object is aggregated, it’s not part of the class’ “hard” manifest.

Thus, an aggregated object is most likely to be shallow copied in the respective copy constructor and copy assignment operator. This of course can be changed when you override them for whatever design reasons that justify the deep copy.

Just note, the pointer itself is technically deep copied since the address (4 or 8 bytes) is copied over to the object copy. But do remember, it’s only the address, not the object, that is being copied over and thus should be considered in object-level, a shallow copy instead.

What’s the diff?!

Well, why not take a look at these 2 pictures below?

In fact, every attribute in this particular class is a composition.

In this case, the aggregation is clearly shown. Attribute C is a pointer while Object C which represents the actual object is somewhere out there in the heap. The rest are all compositions.

When should I use what?

It’s all in the design.

If the attribute is meant to be part of the class, then it should be a composition.

If the attribute is meant to be centralized for easy access, such a singleton that holds every single factory’s pointer, then it should be an aggregation.

Do note that aggregation, if abused, may lead to heavy memory fragmentation. How so? Since the object is nothing but a bunch of pointers (addresses) and the rest of the objects are somewhere out there in the heap, then yeah, the object chunk scatter will be greater (much alike an asteroid being blown into pieces). This thus lead to unusually high memory consumption for large number of small objects even when you have a projected heap size.

Conclusion

Unfortunately, this article doesn’t really apply completely to the Java and C# folks since you guys already have a VM to help you deal with things more or less.

It’s a pity though for Java in which a language that has been proclaimed as a pure Object Oriented language (better represented than C++) has the lack of ability to specify composition and aggregation explicitly. However I may be wrong, perhaps setting inner objects to be immutable may help?

Anyways, I do hope that this article can shed some light on these 2 seemingly confusing terminologies and as usual, please do not hesitate to correct me if you think that I’m wrong.

Have a great week ahead!

Signing off,
Jeremy

This article is in response to some of the people I’ve met during interviews. I’m just kinda surprised at their level of understanding of C or C++.

One of the basic concepts of C and C++ is pointers though C++ has a stricter references (int& for example) that help to clarify things in terms of usage, the basic understanding of pointers cannot be underestimated.

Why is that so? Read on…

Introduction

First of all, there’s a need to understand what exactly is a pointer. In very simple terms:

A pointer is nothing but a number representing a memory address.

The size of the memory address of course depends on the architecture. 32-bits, 4 bytes, 64-bits, 8 bytes. Nothing complicated.

However, a pointer also has a type. A type means class, struct or primitives. Which is why void* is valid. They’re simply memory addresses with no classification of types. That’s why they’re the most generic form of a full pointer.

Once you start to classify pointers with types, for example (C style):

void* ptr = 0×12345ABC;
cMyClass* classPtr = (cMyClass *)ptr;

By doing this, you are, in my terms, casting a shadow or a net on top of the address.

The system doesn’t understand it - neither does it perform checks on the cast validity (unless it’s dynamic_cast<T> with terms and conditions). So why does it even work then?

Classes and Structs

Now we just take a short moment to pull back things a little. We all know that classes and structs are very similar with the exception that classes have methods, access modifiers and inheritance capability. Structures can do that too - with disastrous results of course - as mentioned in my previous post here.

On top of that,  a class or structure has this property, at least in Visual Studio, known as struct alignment. Under default setting, it’s 8-bytes.

What does it mean?

It means that between each attribute in the class, it’s a 8-bytes block. For example, if you have 3 booleans inside a struct, how many bytes will they take up? 1 byte because they’re just 3 booleans? No! Under struct alignment, it’ll be 24 bytes.

As to why it’s set at 8 bytes - that I can only speculate. My guess is, since the biggest data type in C/C++ is double or unsigned long long which are both 64-bits wide and thus translates to 8-bytes, it’s sort of optimized to assume that all data are 8-bytes apart rather than having to check for unaligned memory.

I know this is exceptionally true in assembly language though (in terms of the aligned or unaligned memory).

Shadow-casting

Don’t get me wrong - this is not another type of casting mechanism in C or C++. It also doesn’t refer to the old shadow ROM or memory that your ancient motherboard might have as an option to turn on or off.

A shadow-cast is basically like this: Imagine yourself standing on a pavement and the sun is shining on you, you cast a shadow naturally. If the shadow is cast correctly, then you’ll see a complete shadow of yourself. In this sense you can take it as a valid cast.

In another scenario, imagine yourself standing a few steps before a cliff, the sun shines on you and you cast a shadow. Notice how the shadow disappears as it reaches the cliff? In that sense, you can take it as a wild/invalid/dangling cast. Basically, it means that the memory is shadowed incorrectly and will lead to disastrous results if it’s read from or written onto.

Now, knowing the shadow-cast size is important since you know that memory buffers too have such problems. Knowing your struct alignment will give you an accurate picture of whether your shadow casting is done correctly or not. In short, if you’re shadowing a piece of memory that is 24 bytes long and that your shadow specification is 32 bytes long, you’ll end up having 8-bytes shadowed illegally. While that alone doesn’t cause a crash, again, accessing it in terms of read or write operations will almost certainly lead to a crash.

Known Memory

So, the next thing we need to refresh ourselves is the 4 basic types of memory used by C/C++. That is:

1. Stack
2. Heap
3. Code
4. Private Heap aka Static

Though they’re used at different times, it doesn’t mean that we cannot point at them anytime. Have you heard of things like function pointers? These pointers are basically pointing to the code memory address of the function itself.

Myths

With the stage set, I’m going to move into the myths. But just quickly allow me to define some phrases to reduce or eliminate any confusion.

• Stack pointer means a pointer pointing to an address on the stack
• Heap pointer means a pointer pointing to an address on the heap
• Function pointer means a pointer pointing to a code memory address in the code memory
• Singleton pointer means a pointer pointing to an address in the private heap
• Static pointer means that a pointer is declared as static and its contents, which is the memory address is stored private heap.

Myth #1 - I should always delete a pointer when I’m done with it.

In truth, this statement is technically correct in a very literal perspective. However, this statement falls apart when you’re given pointers that is pointing to any type of memory other than heap.

Unless you have a memory map which maps a range of memory for stack, heap, code, etc, there’s no direct way to tell, by simply reading from the pointer, whether the address is pointing towards a heap or not.

In this sense, this statement should only apply to your own attributes. If you’re receiving pointers from another party, always check out its contract and origins. If your design requires the pointer to be deleted nevertheless, then the caller has invoked your function wrongly by passing in the wrong type of pointers.

Myth #2 - If I have a stack pointer, I don’t have to delete them.

Basically, this is not a myth only if you’re absolutely sure that it’s not a heap pointer. Again, this is only possible if you know the contract and possible pointer inputs. You can also state your own contract of how things work in your class in order to deter callers from passing in the wrong type of pointers.

Otherwise, it’s true.

Not only you don’t have to delete them. It’s best to set them to NULL once you’re done with them. Don’t worry about the actual stack though; you’re just setting the pointer’s holding address to NULL that’s all.

Reason being that should the life of the pointer exceeds the life of the function call, then it’s almost certain that this innocent pointer will turn into a wild or dangling pointer. Reading or writing means death to the application.

Myth #3 - I don’t have to delete static pointers because the compiler does it for me

Again, this statement demonstrates an insufficient level of understanding for pointers. If a pointer is declared as a static variable, then the pointer itself is stored in the private heap. But if you instantiate an object and assign the new address to this static variable, where’ s the object?

Very simple. Just ask yourself how do you instantiate your object? malloc? new? Fine. Where does these allocators draw their memory from? THE HEAP!

So, even though your pointer is declared as a static pointer, you’re responsible for the heap address assigned to your static pointer during instantiation!

Myth #4 - I don’t have to delete my heap pointers all the time

Surprising this myth is actually true! However, it comes with several conditions. You see, memory leaks are not lethal by nature. It’s the accumulation of leaks that eventually lead to crashes.

Therefore, if you can ensure that all your pointers will only ever be instantiated once, then this statement holds true. That’s because the OS will clean up your heap for you anyway.

However, do note - OS handles (ie, file handles) are not released just like that. You’ll need to manually release it or else it’ll be leaked until you restart your machine!

Myth #5 - I can control my private heap

Sure you can control the contents in the private heap. But this control doesn’t extent itself to as far as allowing you to delete the actual private heap itself. See the next myth to understand more.

Myth #6 - Singleton pointers must be the last pointers ever to be deleted

Singletons are stored in the private heap as we know.  If there’s a pointer to the private heap, then so be it.

But know this - the CRT will eventually clean up the private heap. But the order of destruction is not known to you or can be controlled by you alike the way you control heap deletes.

Therefore, this statement is a myth. Try it and you’ll probably get some weird errors as your program exits. Also, if you create a cross-dependency across multiple singletons, then it’s going to be a long long nightmare.

Conclusion

Those myths above are just some examples of insufficient understanding on C and C++ memory handling. There’re plenty more but I don’t have the luxury to post them all up here.

Besides, even I myself is still learning new things everyday.

Therefore, I hope that this article can be understood by everyone and doesn’t contain technical errors. I’m sharing from experience yes? But it doesn’t mean that my experience is flawless.

Thus, don’t try to kill yourself by reading this post too hard. If you find it hard to swallow, take a step back. Read other posts prior to try to gain more understanding towards C/C++ memory.

Otherwise, if I’m wrong, please feel free to criticize by leaving a comment. I’ll be glad to receive any guidance and corrections anytime!

Have a great week ahead!

Signing off,
Jeremy

Dear all,

This week’s article will be rather short because I’ll only be focusing on 1 single issue that I’ve come across. Some may think that it’s complete stupidity while others may be more sympathetic.

In any case, this is a disaster scenario caused by misunderstanding or abusing the use of Object Oriented programming in C++

Read on to find out more…

Introduction

We all know that C++ is an OO language. Therefore we can perform many things with C++, some of which can’t even be fulfilled properly by languages like Java. I’ll explain my statement in the future.

One of the shining mechanisms of Object-Oriented Programming is of course, inheritance. To many it’s a feature that is widely abused to reduce the amount of codes written and also poor attempts to improve reusability.

If done correctly, a framework or engine can easily become popular with programmers. Otherwise, it increases coupling to very dangerous levels and can easily cause the whole system to collapse by design failures.

Scenario

The scenario I have here today is based on C++ only. So, sorry Java and C# folks, you may have to sit this one out this time. But still, it may be something interesting to read up.

Once I was asked to resolve a very weird memory issue encountered with one of my customers. Basically, this customer was trying to make this structure compatible with a linked list node.

Reason? So that he can add structures into a linked list!

Now, this is one classic example where a Java-style programmer tries to make things happen using the Java way in C++. This is suicidal.

So we’re looking at a piece of code which looks like this:

struct MyStructure : public cLinkedListNode {
…

};

By understanding that structs and classes are alike, this is supposed to work right?

Well… yeah, technically, if this is the only predicate, then yes. However, another rule or practice will easily destroy this whole thing - All structures should always be memset to zero before usage.

So… I do something like this:

MyStructure instance;
memset(&instance, 0, sizeof(MyStructure));

What happens next?

You’ll get a very tight slap on your face!

Why? Simple, whenever you inherit another class, the first 4 or 8 bytes, depending on your system architecture and struct alignment, will contain an address to a table known as the vtable.

Without this table, it’s impossible for polymorphism to work and setting it to null certainly ensures that all your virtual methods will lead to disaster.

Conclusion

While it’s important to understand C++ semantics, it’s also important to know that structures are not recommended in a pure C++ environment.

Surely, a mixture C and C++ is possible and even things like temporary variables in C++, which in pure C environments, are illegal, can be used with proper control and understanding.

The problem arises when both standards are mixed wrongly as mentioned in the example above. In that case, neither can the structure be used the C-style way nor can it be added into a linked list just like that.

Solution?

Well… if C++ is to be used, either convert the structure into a class or implement a default constructor for its members. This is allowed in C++ by the way.

Next, the implementation of the linked list is wrong too.

This is C++, not Java. There’s no notion of an Object being the all generic object of every possible object out there. Thus comes this language facility known as - templates.

For example, Strideslib’s version of the linked list is known as cLinkedList<T>. Where T must be specialized in order for the template to be usable. It’s extremely type-strict, thus specializing it with a normal variable is not recommended.

For example: cLinkedList< MyStructure >

This example above requires MyStructure to have a default constructor or else it may not compile. On top of that, it should be used in conjunction of a pointer container such as cSmartPtr<T>.

For example: cLinkedList< cSmartPtr< MyStructure > >

This way, you reduce the amount of work done by the linked list; the copy assignment operator doesn’t have to be invoked everything you get something out from the linked list.

Unless there’s a very strong reason for inheritance, which otherwise, fail completely in the example above, composition or aggregation should be used instead.

I’ll cover these few terms in one of the next few articles.

If not, I’m done for the week. I’ll probably be taking a brief hiatus to work on other things very soon.

Have a great week ahead!

Signing off,
Jeremy

Hi all,

This week I’ll be talking about ‘this‘ pointer. Yeah this little pointer that points to self. Unfortunately, this article won’t really apply to Java or C# users. Nevertheless, you guys may also wanna read this article to appreciate the kind of things we go through writing C++.

So how is it possible that a ‘this’ pointer can lead to a disaster?

Read on….

Introduction

Now, we’re all very familiar with ‘this’ pointer, so this article is likely to be short. Yes? Well, I’ll try to until my explanation gets way too long.

As we know, in C++, some of us if not most of us use a smart pointer container of some implementation, for example boost’s shared_ptr<T>. In StridesLib, we use cSmartPtr<T> which is similar to the boost’ variant with some additional important features.

We will not go into that now.

Technically, we know that shared_ptr<T> is always to be declared as a local attribute or a composite attribute (I used to use the word ’stack variable’ because if the object is instantiated on the stack ,this whole object will be on the stack as well).

We only use a pointer of a pointer container for double pointer operations.

But in any case, here’re a few ways you can use smart pointer containers. I’m just going to promote cSmartPtr<T> a little here.

cSmartPtr< cVector4 > vectorPtr = new cVector4(1,2,3); //to instantiate
cSmartPtr< cVector4> v2 = vectorPtr; //to initialize with and share
cSmartPtr< cVector4> v3; //to declare an empty null pointer container
v3 = v2; //to assign with and share
v3->x = 2.0f; //dereference pointer and access a member

Smart Pointer Containers are not true pointers!

That’s right. As you can see in the examples above, all 3 pointer containers, vectorPtr, v2 and v3 are all local instances (aka stack instances).

If that’s the case, how can it be instantiated with a new pointer? Normally, this isn’t allowed by the compiler does it? Yes!

In that case, what’s the magic involved here?

Answer…. the big 3!!

Surprise, surprise! How can the big 3 be involved here? Well, basically only 2 of the 3 bigs are used as well as other operator overrides.

What are the bigs used here?

1) Copy Constructor
2) Canonical Copy Assignment Operator

What are the others used?

3) Parameterized Constructor (with a T*)
4) operator = (T* )
5) operator == (T* )
6) operator != (T *)
7) operator ! ()
operator * even

There’re more but I can’t afford to explain every single one of them. Basically, when T is used, the rest of the problems are dealt with by the compiler. As you can see in the set of overrides, it allows the smart pointer container to implicitly take in a true pointer so much so that it looks hidden from the user.

While this is a good feature overall. It sometimes can hide dangers that might stump even the most experienced C++ programmer for a moment.

Now, let’s just realise that cSmartPtr< cVector4 > vectorPtr; is not a true pointer.

A true pointer in this case would be cVector4* vectorPtr; instead.

When disaster strikes…

Here comes the ugly part.

Remember that a smart pointer container can take in a true pointer implicitly?

Here’s the catch - a this pointer is a true pointer, a smart pointer container is not a true pointer. Let’s take a look at this example:

class A {
    private:
        B bObj;
    public:
        A();
};

A::A()
{
    bObj(this); //this pointer is guaranteed to be valid at this point
}

//in classB.h

//forward declaration
class A;

class B {
    public:
        B(cSmartPtr<A> parmPtr);
};

//so happens when I instantiate an object of type A?
cSmartPtr< A > aObj = new A();

//1) aObj ctor called, instantiates composite object bObj with (this) pointer
//2) this pointer is interpreted by B's ctor implicitly and is initialized as a cSmartPtr<A> parmPtr instead

Therefore, at this juncture, there’re two smart pointer containers with different context pointing at the same pointer. Here’s how it looks like: (let’s say new A() returns a 0×00001FFF)

aObj —-> 0×00001FFF , ref count = 1
parmPtr —-> 0×00001FFF, ref count = 1

As you can see, there’s absolutely no communication between aObj and parmPtr. So if anyone of them sets themselves to null, thus reducing the reference count to 0, 0×00001FFF will be deleted with size of A. Thus the situation will be:

aObj —-> 0×00000000 , ref count = 0
parmPtr —-> 0×00001FFF, ref count = 1 //parmPtr is now pointing to a dangling pointer!

Can parmPtr escape?

Well, let’s see.
1) Dereference -> Crash due to dangling pointer
2) Check against null -> Return incorrect results
3) Set to null -> Crash since parmPtr will attempt to delete a pointer that has already been deleted
4) Pass it onto another container -> Won’t crash immediately, but the consequence merely delays the inevitable from happening since one of the containers will be 0 and the same thing will happen in 3).

Conclusion

Therefore, it’s impossible to recover from such a flop. In this case, the programmer must understand that this pointer is not a smart pointer container object. He/she must not take it for granted and pass things in just like that.

However, that being said - the implementation of the smart pointer can play a part as well. That is, storing a unique hash map of memory addresses as the key, the smart pointer container as the object. The smart pointer container will register itself the first time for memory protection. Then subsequent smart pointer containers who are not directly related by context will access this hash map to see if there’s already such a container that manages this memory address.

If there’s such a container, then it’ll retrieve that container and increment its reference count, thus joining up.

This is how it should look like even when the pointer containers are not, i repeat, not passed around.

aObj —-> 0×00001FFF , ref count = 2
parmPtr —-> 0×00001FFF, ref count = 2

The problem is - the cost of using a hash map can be expensive. Thus leading to an increased cost of using smart pointer containers afterall.

Bottomline is, programmers need to know their pointer basics, whether they use smart pointer containers or not. They can’t depend on these containers entirely without arming themselves with the right knowledge. Otherwise, if a disaster of such a kind strikes, nobody can save you.

Not even testing tools.

Hope that this helps! Have a great weekend ahead!

Signing off,
Jeremy

Hi all,

Here’s another article regarding software development disasters. However, do note that this is a fictitious story that contains certain fragments of events that are based on my own experience. I’m just using a single story to string them up. So, here it goes:

A team of developers worked on a software for 12 months already. So far, there hasn’t been any issues in terms of functionalities. Everything was proceeding smoothly.

One day, a new user joined the team to help test for exceptional conditions. That’s where the flight to heaven fell from the sky, hit a shit mold and starts to roll into the hot depths of hell.

What happened? Read on…

Introduction

Basically, there’s nothing much to introduce here. Most of the introduction has already been done above. But allow me to set the stage instead for this whole mess.

First of all, the developers are not very experienced. They have approximately 1-3 years experience in C++ development and their project manager is purely a task and requirements management person.

There’s a technical leader who has around 4 years C++ experience. Their code base is approximately 400,000 lines of codes so far.

So what exactly happened?

13th Month - Unlucky or just a plain number?

On the 13th month of the project, a new young but experience user-cum-tester joined the team. As expected, his tasks were to test the project with existing requirements and come up with test plans that are exceptional in behavior to the system.

He’d then test the system and submit a report to the manager who will then reassign new tasks based on the report.

The first few days was really honeymoon. The tester heaped tons of praises on the work done so far to encourage the team. Everyone was energized and motivated.

But problems start to appear right after the 2nd week.

In certain exceptional cases, the system could not be recovered. In fact, in extreme scenarios, the team had to shut down the server and restart the machine literally.

This came as a big blow to the team since they were on such a smooth sailing progress since last year.

The developers began to rage a war against the new tester by begin very difficult to deal with. They soon question the tester’s intentions in the company and even accused the tester of sabotaging the project for other competitors.

It was ugly.

In response to that, the project manager ordered an emergency meeting and launched an investigation into the series of crashes caused by the exceptional tests.

Debugger Faulty?

As usual, the developers stepped into the codes, they could even identify where the point of the crash occurred. But they can’t make any sense out of it. Basically, the code look something like this:

void Bank::UpdateStatus(int newStatus)
{
    m_iCurrentStatus = newStatus; // CRASH here.
}

It looked as though as the debugger was faulty here. But it can’t be. They’re using Visual Studio 2005 to begin with and we know that it’s a stable and dependable.

Apparently, they have a clue.

The memory address of m_iCurrentStatus looked dubious. The address reads something like 0xCCCCCCDF . But this alone doesn’t tell much of why the address was allocated this way.

Naming disaster

Another thing noted by the tester is that - whenever he encountered a compilation error in a sea of compiler warnings and template warnings, it’s almost impossible to look for THE compilation errors.

Usually, in Visual Studio, it’s easy to search for compiler errors by typing “error” in the search pop-up.

However, for this team, they apparently named classes with the word error as part of the name. For example:

cBankingErrorException
cAccountErrorException
cErrorReport
cErrorStatus

What the hell?!! For certain reasons, certain names like warning or errors should never be used as part of name of a class. This certainly leads to more work when debugging or figuring out syntax errors.

I mean, take a look at this. You have like 20,000 lines of warning and stuffs like that during a build and there’re like only 5 to 6 compiler errors. The compiler says, 10222 warnings 5 errors.

So what’s next? Look for the syntax errors right? NO.

You can’t because the freaking CLASSes are NAMED as errors. So now you’ll have to filter through like 2000 instances of errors in order to find that few compilation errors.

Worse if it’s spread evenly apart. Good luck finding them.

Note: Don’t assume that everybody’s using Visual Studio 2003 and above ok - errors don’t just pop up like that.

Mysterious System Slowdown

The system was actually ok when the standard test plans were performed. There were no glitches, bugs or crashes.

However, when the exceptional test set came into play, the whole system began to slow down after 2-3 days of continuous operation.

The so-called exceptional tests that caused the slowdown are nothing but creating bank accounts.

Cause of Problems

Now I’m sure you guys want to know what caused all these problems right?

Let’s go through them 1 by 1.

1) Debugger Faulty?

The debugger isn’t faulty. Neither is the address faulty.

The code is behaving correctly. So what’s wrong anyway? First of all, we need to understand that there’re 4 types of memory in C++. See this the memory management in totality article for more information.

So, a few things are known after compilation. One of which is the code memory. The code memory stores a single undisputed and unique copy of your compiled source codes in it. This applies only to an application by itself - additional DLLs have their own respective code memory.

We’ve now established that the code itself is perfectly ok.

Next, let’s establish the validity of  m_iCurrentStatus . Based on the coding standards, it means that it’s a member attribute, type: native integer. The thing you must know about classes is, a member attribute is actually an address offset in the class.

And since everybody has an address of its own, let’s assume that the address of the object is 0×1234cccc. Based on the struct alignment of 8 bytes default, each attribute is spaced out at 8 bytes distance.

Therefore even if you have 10 shorts, it’ll still take up 80 bytes.

So, when an member attribute is accessed, the formula is bascially:

base address + offset

Therefore if the base address is faulty in the first place, ie, wild or dangling, the CRT will not be able to tell unless it’s a null pointer which is zero in this case. Since it’s not able to tell, it’ll just blindly execute the line with the code, base address and offset.

Thus causing this weird error to occur.

2) Naming Disaster

By naming classes with error as part of the class name suggests a possible defect in the design itself. How could a class be created simply to represent an error?

While naming the class with error as part of it may have its merits, it’ll certainly cause a lot of problems should the build breaks. People who’ve used VC6 before should understand. In the later versions of Visual Studio, errors are presented in a different window apart from the console, allowing developers to quickly zoom into it.

However, for people who’re using make files, build utilities and the old VC6, good luck to you finding the compiler error. Even if you can, it’ll not be easy and it slows you down for nothing.

3) Mysterious System Slowdown

If your system doesn’t crash within the same day even though there’s an obvious design-based leak going on there.

Even if your system doesn’t crash but if it slows down dramatically, then either design-based leak or memory hogging is responsible.

For more information - read this article for memory hogging, and these two articles below for design-based leaks.

Design-based leaks (continued)
Legal Leaks

Conclusion

Finally, we’ve arrived at the conclusion - it has been a long long post I believe. I hope that these lessons will help people realise potential problems early during development even though the story is fictitious, it’s based on true experiences put together to form a scenario.

Do read up the references I’ve linked up here. It’ll help as well.

Have a great week ahead!

Signing off,
Jeremy

This week I’m going to talk about my experiences based on my other talents. Technical people can still read this post and perhaps gain some insights for your own benefit.

Basically, I’ve met a group of so-called musicians or guitarist during a gathering in which I was invited. In that group there was one or two that were “certified” as a performer.

By right, as a musician myself, I should be happy to exchange what I know with what they know. But what happened thereafter pissed me off.

How so? Read on….

Introduction

Yeah, some introduction about myself. I’m a pop pianist at core even though I play other instruments and genres from music such as Jazz, Bossa Nova, etc. I also play an er-hu and just started on a violin.

My main skills as a pianist isn’t with how I play or sight reading. Rather, it’s my ability to play what I hear. They may not always be accurate but it’s never too far off.

Incident(s)

As mentioned at the beginning, it was a gathering. Some of those guys actually brought their guitars along. My friend was actually a beginner of playing the guitar at that time. So, they were teaching him how to play a song based on the way it’s being played rather than understanding why the song was being played that way.

In short, these guys don’t know what they’re playing. They’re parrots, mimickers, imitators or playback machines at best.

I’m actually quite ok with it since everybody has their standards and talents which shouldn’t be judged against what I already knew.

The problem was, when I tried to explain to my friend what on earth he’s actually playing, one of those guys interrupted us and told me off. He said - “You shouldn’t teach him what’s a chord, you’ll only confuse him.”

I was like, (in my mind scolding the grandfather of all vulgarities) so damned pissed off. Already, the way he taught my friend was WRONG and he was there trying to be Mr Right all the way.

Anyway, much later I had a good talk with my friend. He too agreed that he was confused by them rather than enriched.

That guy moreover added : “To qualify as a rock guitarist, you need to master 5 metallica pieces…”

That’s the stupidest thing I’ve ever heard. Does he really think that mastering any 5 pieces makes qualifies him to be a great guitarist?

The same goes for piano or all other instruments! The mastery of music lies in its essence not in its instrument! An instrument is a conduit for musicians to express their emotions through the notes they play, and is not a copywriter! It’s an insult to the instrument!

It’s akin saying: “I need to make 5 chairs in order to be a master chair carpenter!”

That’s a total load of bullshit!

We all know that there’s more to being a master than just being a poser or recital expert. Having certified to be able to perform in the public doesn’t mean a thing if the performer doesn’t know what the hell he/she is performing!

I’ve seen in so many cases where a self-proclaimed maestro (ie, an accomplished musician) playing pop songs in the public.

You know what? They suck. They insult the song and misinterpret the song entirely by playing the classical way. Their additional cues only make matters worse.

It’s this kind of people that makes pop pianists look like restaurant performers.

Take for example, if I get an Electric Guitar to play “My Heart Will Go On” how would it sound?

Or if I play “Song 2″ on a piano using classical methods, how would it sound?

How should it be?

Music is a form of description. Playing it, is a form of expressing this description (story or scenario) with a perspective.

Its perspective should align as closely as possible to the rationale of the piece. Why is this song composed? Who is it for? Which place does it has its moods set upon?

Perhaps, musicians or wannabes should ask themselves the most important question. Why are they playing this song in the first place?

Of course, to be fair, practice is a common answer. Practice would mean practising the song in its technicalities. Ie, which chord to play, how to play it correct. That’s important.

But a practice session doesn’t mean that it’s the right perspective for the song.

If one takes on a training perspective as THE perspective for playing a song, then it’ll be a pure technical recital of the song without any real expressions or feelings.

In such a case, ordinary people would be able to tell though other musicians may be captivated by the technical-side of things.

Conclusion

In conclusion, I’ll just like to make a few points:

1) Don’t be an asshole. Just because you don’t know something doesn’t mean the others shouldn’t know as well.
2) If you’re confused, then you either suck or seek elaborations. It doesn’t mean the others will be confused.
3) Always know what you’re playing. Chords represent a part of progression in music which orchestrates the whole song. A chord itself is made up of notes that are usually part of the song’s stream (major/minor). This allows the song to be disciplined and classified properly, following the rules.
4) Music is not just about playing, it’s about expressions as well. There’re many types of expressions, one of which being the expression of understanding (which is attained by understanding the song itself).
5) Knowing an instrument is good, but knowing how to use it well is better.

It certainly applies to software development if you ask me. Just replace “play” with “code”, “song” with “application” and so on and you’ll get the drift.

While music itself is an expression, it’s also a “formula” which can be calculated with musical rules and chord rules. I’ll talk about this next time.

Anyway, have a great week ahead!

Signing off,
Jeremy