I'm no expert in this field. This writing is an effort to document my learning process from multiple sources and will be updated when I get more comprehension on the topic. Feel free to correct me, or comment.

What is it?

The main function is the entry-point of a program, where the instructions to be executed. However this is not the case with libraries, they don't have one. What if a program doesn't have one? It simply won't compile.

How is it declared?

Generally the main function is declared like the following:

int main() { ... }

// or

int main(int argc, char* argv[]) { ... }

// or, with common POSIX extension

int main(int argc, char* argv[], char* envp[]) { ... }

The name main

The name main was inherited from C, and it escapes from all the revision and changes between standards, except got a little bit annoyance in MSVC++ which they introduce wmain for arguments that supports wide chars.

The signature

The signature was also inherited, this time from the old days of C++98, and the third version also accomodating POSIX extension. The following would be the explanation of the signature elements.

int return value

In the early days, we've seen something like void main(...). However, using it in modern C++ will raise an error.

This is the return value that C++98 and above expects. The int return type, as I've read somewhere, while it does not direct mapping with the OS process exit statuses, it's for easy conversion and more intuitively interpretable. But I think it's more of a guess of mine, if you know the reason behind it, please let me know.

int argc argument

This is the count of entire argument including the executable name itself. Thus,

./cut -d' ' -f2,3,4 data.csv

will have argc equals to 4.

char* argv[] argument

This is the argument values, packed in array. The first element of the array will always be the program name. Hence, from the previous example it will be equal to ./cut, and the next in sequence will be -d' ', -f2,3,4 and the last one will be data.csv. What about the next element, argv[argc]? It is guaranteed to be null.

char* envp[] argument

This argument does not come from the C++ standard, but commonly used and as part of the POSIX extension. This parameter will be the storage of the frozen version on user's environment variables, including those provided when executing a program like this:

EDITOR=/bin/vim visudo

The envp array has the possibility to be empty. Also, because of the absence of the count parameter (like argc to argv), programmer shall loop through the array until finds null which is the indicator that there's no more value to collect.

However based on many discussion on the internet, many of them discourage to use this as it's not portable between systems. Some also pointed out about overflowing possibilities. I'd like to hear from you too if you have something in mind about this.

How does it flow?

What happened before main begins?

There are some activities happens when we executed a program. The following are the activities that is performed before it entering the main function.

• Linker takes the object files and libraries the program linked against, and combined them into an executable program. After that, loader will load the program into the memory.
• Memory is allocated both for the code, data and stack.
• Global variables are initialized with their corresponding initializers, and for the uninitialized, they will be set to zeros. On MSVC++, all static members of classes will also be initialized here similar to global variables. However, other compilers decide to perform this at compile time.
• Function pointers are set up, and virtual tables are constructed for dynamic dispatch.
• Entering the executable entry point as OS expects it, that is the _start section in the assembly code version of our program. In this section, it will initialize C++ runtime library required for running the program, and also prepare the arguments for our actual main function and finally invoke it.

What happened after main ends?

• The destructor of all globals and static objects will be called in reversed order as they were created to clean up the resources they may allocated.
• After that the C++ runtime library will make system call to OS to indicate that the program is terminating, typically will take the main return value as its parameter.
• OS will then update the process status to terminated and marks it with the main function return value.

What can we do with it?

• Declare the function body as try/catch block:

// this example is borrowed from reference 1
#include <stdexcept>
#include <iostream>

struct Q {
    ~Q() noexcept(false) {
        throw std::runtime_error("will escape");
    };
} q;

int main() try {
    throw std::runtime_error("will be caught");
} catch (const std::exception& e) {
    // will caught the runtime error from main, but not from ~Q
    std::cerr << "caught: " << e.what() << std::endl;
}

here's the output of the above program:

caught: will be caught
terminate called after throwing an instance of 'std::runtime_error'
  what():  will escape
make: *** [Makefile:14: try-main.x] Aborted (core dumped)

A little explanation of the above code:

• entering main
• throw exception, hopefully be caught
• catching exception: yes, it is caught
• is there user code remaing to execute? no
• main exiting...
• program do some house keeping, found q of type Q, which throws exception in its d'tor
• destroy q, hence, throws exception "will escape"
• is there anymore to clean up? no
• call terminate

What can NOT we do with it?

Naming

• Cannot be named, thus can't take its address, can't also be called recursively, or get the type of it.
• Cannot use the name main for other function in global namespace or anything with C-linkage

Construction

main can't be declared as inline, static, constexpr, consteval or with auto or as a coroutine.

Reference

1. Daily bit(e) of C++ | main
2. main function and command-line arguments
3. Main function

I'm no expert in this field. This writing is an effort to document my learning process from multiple sources and will be updated as I gain more understanding of the topic. Feel free to correct me or comment.

There are two type of initialization mechanisms, direct initialization and copy initialization.

1. Direct initialization is a mechanism that explicitly use the constructor to construct the value of the variable or object.

2. Copy initialization, on the other hand, is a mechanism that use other value or object to construct the value or object.

Now, what's the uniform term refer to? It's uniform by mean of there's no difference between initializing variables of regular types, or custom types (classes, arrays, maps etc.).

How?

By using the brace initialization {} (introduced in C++11, improved in C++20).

std::string direct {"this is direct initialization"};
std::string copy = {"this is copy initialization"};

int i {10};
int n = {1};

float f {22.7};
float c = {299792458};

int array1[5] {1, 2, 3, 4, 5};
int* array2[3] = new int[3]{10, 20, 30};

std::vector<int> vector1 {0, 1, 2, 3};
std::map<int, std::string> map1 {{1, "one"}, {2, "two"}};

class foo {
    public:
        foo(): _i(0), _f(0.0) {};
        foo(int i, float f): _i(i), _f(f) {};

    private:
        int _i;
        float _f;
}

foo {};
foo {4, 29.3};

Why?

The following are the reasons why you would use it most of the time.

Consistent syntax

It provides same or at least intuitive syntax for variables initialization of various data types.

// integer
int i {1};
int* iref {12};

// floating points
float f {22.01};
double f {3.1416};

// string
std::string name {"Agung Prakasya"};
std::string email {"agung@example.com"};

// array
int* heights[5] {14, 22, 21, 15, 17};

// map
std::map<std::string, float> dict {{"earth", 67.5}, {"mars", 21.7}, {"venus", 33.8}};

// vector
std::vector<double> distances {12.6, 44.2, 15.7};

// object (from previous section)
foo {};
foo {4, 29.3};

// and so on...

Doesn't allow narrowing type conversion

In C++, narrowing conversion is a potentially unsafe numeric conversion where the destination type may not be able to hold all the values of the source type. The following code won't compile, that is to prevent unintentional typecast which can produce error in further flow of the program.

// initialize variable d as double with value 10.71 
double d {10.71};

// create variable i as int, with intention to initialize
// with value 10 (integer).
// this won't compile.
int i {d};

However, if it's intentionally to cast the value, we can achieve that with the following:

// initialize variable d as double with value 10.71 
double d {10.71};

// double to int implicit conversion
int i = d;

// modern C++ typecasting - this is the best practice
int i {static_cast<int>(d)};

// C style typecast
int i {(int)d};

// old C++ style typecast
int i {int(d)};

Fixes most vexing parse

There's a rule in C++ parser that, every time it finds something considered as function declaration, then treat it as function declaration.

Now consider the following example:

class foo {
    public:
        foo() {...};
    private:
        std::vector<int> v(3, 0);
}

The code ablve won't compile. The vector v initialization will be treated as function declaration, while it's not.

To achieve the vector v initialization we can use some other approach. First, move the initialization into the constructor:

class foo {
    public:
        foo(): v(3, 0) {};
    private:
        std::vector<int> v;
}

second, use the copy initialization:

class foo {
    public:
        foo() {};
    private:
        std::vector<int> v = std::vector<int>(3, 0);
}

third, use the uniform initialization:

class foo {
    public:
        foo() {};
    private:
        std::vector<int> v {0, 0, 0};
}

Why not?

With all the pros above, still, we need to be aware that there are some cases that we need to not just used it along with other conveniences. Actually the following are just special cases where if all the condition occur, we might need to use another approach.

Auto type

While using auto in variable declaration is convenience, we might need to sacrifice it when using uniform initialization. Otherwise, we might get the variable type not as intended, or the code doesn't even compile.

// var_name is of type int
auto var_name {1};

// var_name is of type std::initializer_list<int>
auto var_name = {2};

// doesn't compile, error variable contains multiple expressions
auto var_name {1, 2, 3};

// var_name is of type std::initializer_list<int>
auto var_name = {2, 3, 4};

However, with simply replacing auto with actual data type should have solved the problem.

Vector type

It's actually more like warning to not mixed up with the old initialization approach like the following code:

// initialize myvector with {0, 0, 0} elements
std::vector<int> myvector (3, 0);

// this initialization will create myvector with {3, 0} elements 
// instead of {0, 0, 0}
std::vector<int> myvector {3, 0};

The strongly prefer std::initializer_list constructor

Strongly prefer std::initializer_list constructor is actually a process of constructor overload resolution within a class. The first phase of the resolution is to inspect if there's a constructor that has std::initializer_list as a single parameter. This is why it is said to be strongly prefer std::initializer_list constructor.

To be clear, let's imagine we have a class with overloaded constructor, first with whatever parameters (in the following example using int and float) and another one with std::initializer_list parameter.

class foo {
    public:
        // first constructor
        foo(int i, float f) {}
        // second constructor
        foo(std::initializer_list<bool> list) {}
}

foo my_instance {4, 23.5};

The code above won't compile. Why? because, foo has the strongly preferred constructor that is the second one. Thus, the creation of my_instance won't invoke the first constructor, but instead the second one. In this case, the invocation will attempt to narrow-convert the int and float, 4 and 23.5 to bool which of course will fail.

Summary

Reference

• SYCL 101

• Beginning C++20: From Novice to Professional (Ivor Horton, Peter Van Weert)

• C++ standard's draft

This actually a note to myself (and may be some of you who experience the same) to keep up the effort to maintain my Github repository better.

Background

I have a thought that my Github repository is not how it is supposed to be and I think I need to do some action for that. However, I need to know the root cause and see what I can do about that because I think it's also related to my habits.

Let's dig deeper into the current situation of my current Github account. First, this is my second Github account. I decided to retire the first one because it was too messy and started the second one from scratch with hopes it wouldn't be experiencing the same as the first one.

Guess what! It happened again. Okay, let me explain the situation of my current Github account, the what (the thing I see in my Github) we'll analyze, and then the why (a self-diagnosis of why it happened) and then the how (a thought on how to fix that).

Analysis

Here is what I found in my Github account:

• All private, no public repositories.

• No mature code, only unmaintained early-stage codes

• Same idea in multiple repositories

Let's think that those are signs of something or effects of some behaviour or even further mentality of the owner.

Before going further, let's dig deeper into each fact. After a while of trying to be honest with myself, here are the findings of my behaviour:

• Why are the repositories all private?

  Well, I always think that code that is published on Github should be mature, professional and in the best of its form. I feel a little bit unconfident about my code.

• Why is there no mature code, only unmaintained early-stage codes?
  I think I was really quick to get bored with the approach, topic or the idea itself. Or it might be too long before it reaches the excitement and the passion has just gone.

• Same idea in multiple repositories?

  I have a habit of doing in multiple ways to achieve a single objective if it's possible. Doing them in parallel and picking the most elegant one.

Problem Statement

• Setting the bar too high.

• There was no milestone setup, current work is always compared with the expected final state.

• There was no focus or strategy for achieving the target.

Solution Proposal

Actually, this is not the final solution, except it's already been done for some time and the result is as expected. However, I need to write this and propose this to myself as the fix for my habit problem.

So let me propose it to myself and see if it needs some revision or adjustment in the future.

• First, let me confess: Stop being proud and prejudiced. We (me and myself) are just learners, and will always be. Even Mozart had his simple composition at the time. Nobody will laugh at our work, and we also have never done that, right? Let's confess, that we learn from somebody else who kindheartedly shares their knowledge, and is never prejudiced against anyone else.

• Set milestones that can be achieved in a relatively short time and visible improvements. When I have the knowledge in terms of theory and methodology, I think I need to write something about this.

• If there are some options to the approach of achieving the target, pick only one with the SMART (specific, measurable, achievable, relevant & time-bound) consideration.

Action Plan

I think this part should be a living part of the document which contains some actionable that I can add from time to time and can close when I think it's enough.

1. Publishing a repository of mine, excvtor; a repository of a simple python script to generate TeX and PDF resume from JSON formatted resume and a style/layout template.

2. TODO

It's actually an old mission, a long pending mission to tidy up all my digital workspace, showcases, and everything in between. the long-time-dead blog, cluttered GitHub repositories, messed up cloud storage, tons of duplicate files, digital garbage and evidence of things I've done that should never exist.

Problems

From the background above I just use words cluttered, messed up etc. It does show the situation but doesn't tell the urgency. In these sub-parts, I try to express how they contribute to the unright things of me.

• I'm a programmer but don't have any public repository/published code, a mature code that others can get inspired with, let alone a complete app/lib that others can use.

• I claim myself as a person who is experienced enough and likes to read but I don't have any published writings in the form of anything that expresses my thought or express my opinion about something relevant to my knowledge/experience.

• When I think I have an idea, I usually do Self-PoC, and it's often done partially in code and another part only in the mind. With the model, I can confirm to myself it is legit proof while knowing that in the future I can guarantee that I will forget those parts in my mind.

• When I need to show my off-office work, I don't have anything real to put in my showcase, it's all over the place, local disks, minds and even scratch paper. And this repeats.

• and so on.

Risk & Impact

Here I'm trying to identify the risk and impact of those unright things above, to model how it will affect me and probably my life.

Risks

• There's a possibility that some audience will see what I claim about myself as a false premise.

• There's a possibility that some audience will see that I'm exaggerating the claim.

• There's a possibility that some audience will see that I'm the kind of person who likes to keep everything to myself.

• There's a possibility that some audience will see that I'm the kind of person who doesn't have good responsibility with the work artifacts, let alone doing documentation on them.

Impacts

• Companies won't get a meaningful conclusion from a false premise. Thus, they won't buy pig in the poke, i.e. not gonna hire me.

• Companies, even they like to hire me. They will be in doubt. Thus, I won't get my salary expectation

• Companies will value me as a nonteam player, or at least not a good one. Whether or not they hire me, my value just got dropped.

• Companies will think that non-responsibility with the work artifact is very bad for the team or even the whole company, and should be avoided. And of course, company won't take the risk.

Solution

Breaking Down the Problem

From the above description, we have a broad problem space and cross domains and of course, it has never been a good idea to try to solve it as a whole. We definitely need to do dividee et impera against it. The obvious option would be by activity, which gives us three problem sub-space:

• Coding activity: What do I need to do/have, to be a productive, consistent, and being better and better time-to-time programmer?

• Writing Activity: What do I need to do/have, to be a productive, consistent, and being better and better time-to-time writer?

• Self-PoC activity: What do I need to do/have, to be a proofer for concepts?

Solution Design

We have broken down the problem into specific domains which hopefully are easier to solve. To keep them separate, I think it'd be better to try to solve the above problems in separate articles.

If you happen to read this and have a thought on how I should solve my problems please tell me what you think.

Salam,

aprksy