[Solved] static and non-static init block in C++

Question

0.00/5 (No votes)

See more:

, +

Is there a way to have this initialization block similar to Java that we could implement and run properly in C++.

There were two types of init-block in Java:

1. init-block/raw-init-block, this will invoke at every new instance created.
2. static-init-block, this will only invoke once and consistently the first to be run/invoke before the init-block(if you implemented it).

What I have tried:

But the problem is, it kinds of behaving like a raw-init-block/init-block if were not using this pass-by-reference syntax.

First, We have this custom header file: static_init_block.h, I found this at IDEONE.COM: https://ideone.com/6sjRzz[^]

#ifndef __STATIC_INIT_BLOCK_H__
#define __STATIC_INIT_BLOCK_H__

#define __CONCATE(X,Y) X##Y
#define __CONCATE_IMPL(X,Y) __CONCATE(X,Y)
#define __UNIQUE(NAME) __CONCATE_IMPL(NAME, __LINE__)

struct StaticInitBlock final {
	template<typename T> 
	constexpr StaticInitBlock(const T& only_once) {
		only_once(); 
	}
	//REM: to counter "warning: unused variable"
	constexpr ~StaticInitBlock() { /**REM: ignore */ }
};
//REM: `__UNIQUE(...)` macro required if we expect multiple `static-init` blocks in function
#define __STATIC StaticInitBlock __UNIQUE(block) = [&]() -> void

#endif //REM: end of __STATIC_INIT_BLOCK_H__

And then we use that header file inside of this module partition interface: *.ixx
And include that as a global module fragment.
Note: I did not show the implementation of this module, since this is a straightforward src-code

module; //REM: global module fragment
#include "static_init_block.h"

export module domain.name:module_partition_name;

import <iostream>; //REM: header unit

namespace domain::name {
    namespace module_partition_name {
        export class ClassBase {
            __STATIC { //REM: static-init-block
                std::cout << "in namespace module_partition_name ClassBase static init block" << std::endl;
            };
        public:
            ClassBase();
            virtual ~ClassBase();
        };
        export class ClassDerive : public ClassBase {
            __STATIC { //REM: static-init-block
                std::cout << "in namespace module_partition_name ClassDerive static init block" << std::endl;
            };
        public:
            ClassDerive();
            virtual ~ClassDerive() override;
        };
    }
}

export namespace $DN_MODULE_PARTITION_NAME = domain::name::module_partition_name;
export typedef   $DN_MODULE_PARTITION_NAME::ClassBase   ClassBase_t;
export typedef   $DN_MODULE_PARTITION_NAME::ClassDerive ClassDerive_t;

primary module interface: *.ixx

export module domain.name;
export import :module_partition_name;

and at the main entry function: *.cxx

//REM: we must import domain.name;


//REM: RAI Initialization
//REM: the static-init-block did not work its act like a raw-block/init-block
ClassDerive_t d0;
ClassDerive_t d1;
ClassDerive_t d2;
//REM: explicitly allocate memory in ~HEAP, the static-init-block did not work.
//REM: and again it behave like an init-block.
ClassDerive_t* d00 = new ClassDerive_t();
ClassDerive_t* d01 = new Classderive_t();
ClassDerive_t* d02 = new ClassDerive_t();
delete ...;

//REM: Below this, the static-init-block works as intended. However
//REM: We don't want to run it such like this only using/sharing one address
//REM: in the real world this is impossible to maintain,
//REM: cuz we always need unique instances to keep data in tracks.
//REM: PASS-BY-REFERENCE
ClassDerive_t d000;
ClassDerive_t* d001 = &d000;
...
//REM: ~HEAP, PASS-BY-REFENCE
ClassDerive_t* d0000 = new ClassDerive_t();
ClassDerive_t* d0001 = d0000;
...
delete ...;

Posted 31-Dec-21 20:53pm

Phoenix Liveon

Updated 22-May-22 3:03am

v11

Add a Solution

Comments

Stefan_Lang 5-Jan-22 8:25am

You haven't mentioned what kind of problem you intend to solve, or why using modules prevents you from doing it with standard C++ techniques. Nor have you mentioned what functionality of Java initialization blocks you intend to recreate in C++.

I fail to see the need for this, or the problem you set out to solve: Constructors can - and should - do all of this for you, out of the box.

I expanded on that in my solution. It may not be the solution to your question, but it is most certainly a better way to approach this topic.

3 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Richard MacCutchan · Accepted Answer · 2021-12-31T22:29:00

Solution 1

You could probably simplify that by the use of the singleton pattern - Google Search[^].

Posted 31-Dec-21 22:29pm

Richard MacCutchan

Phoenix Liveon · Accepted Answer · 2022-01-03T00:14:00

What I did for now was to call/invoked it inside of the first line of one of any constructor, Note: upon by doing it we need to have a delegated constructor if we do had multiple overloaded constructors, so that we could link it together, then put this static block to the last linked constructor to had a chance running it only once and will be invoke first before any other else. But first we do need to add a static keyword found at the header file: static_init_block.h 3rd to the last line which is a STATIC REGISTRATION MACRO, #define __STATIC static StaticInitBlock __UNIQUE(block) = [&]() -> void

PS: I did not try/implement it yet to the bigger projects, but we had an assumption that this will cause an overhead more specifically at the delegated constructor(s);

//REM: overview or in theory

class ClassOne {
public:
    ClassOne() {
        __STATIC {
            std::cout << "ClassOne, STATIC init block" << std::endl;
        };
        //REM: second statement ...
    }
};

//REM: Overloaded Constructor, I use delagation constructor

class ClassOne {
public:
    //REM: delegating constructor
    ClassOne() : ClassOne(0) {
        //REM: statement
    }
    //REM: the last linked constructor
    ClassOne(int param0) {
        __STATIC {
            std::cout << "ClassOne, STATIC init block" << std::endl;
        };
        //REM: second statement;
    }
};

If we want simulated/similar to init-block then add this line/syntax:
#define __INIT StaticInitBlock __UNIQUE(block) = [&]() -> void at the header file which was next to the other defined STATIC REGISTRATION MACRO.

Stefan_Lang · Accepted Answer · 2022-01-05T01:46:00

You seem to try and imprint another languages' properties onto C++, and that is never a good idea!

My experience with java is limited, and I'm not sure what you actually have in mind, but the code you posted is clearly not the recommended way of doing things in C++. Most importantly, C/C++ does have a main function that can create it's own objects, without being part of an object: that is where you create the basic entities of your program, not in a some static intialization!

Initializing an object statically makes sense only for some classes in C++. For most, creating an object without tangible data is not helping anyone. This is bad for multiple reasons:

(a) you needlessly spend time trying to fill an object with data without having data

(b) you needlessly spend effort passing references of meaningless objects across your code until you get to the point where you can actually fill it with meaning.

(c) You later need to initialize it again. And you need to keep track of which objects need this initialization, and which don't.

(d) you confuse readers of your code by moving around references of objects that aren't valid objects

(e) you introduce additional sources of errors by providing references to objects that are not actually initilized with meaningful values: anyone dealing with these references either needs to spend additional effort just to detect whether the object it is looking at is actually valid, or else risk undefined behaviour.

What you should do instead is create each object right before you use it, because that is the time when you have all the information that you need to create a valid object - indeed you must have all the information at that point, because otherwise you may not use it! And then you provide contructors or factory methods to construct this object from this information.

Disclaimer: As always, there are exceptions. But for the many reasons outlined above, you should avoid static initialization as much as possible, and prefer construction and initialization with relevant data at the exact place and time when the object is needed.

[Solved] static and non-static init block in C++

3 solutions

Solution 1

Solution 2

Solution 3

Add your solution here

Preview 0