First of all, let's think do we really need to keep icpp-compatibility at all. Or it is possible to forget about them once and for all.

Talking about the solution proposed (to inject registration calls with header - if I understand it correctly), I think this is possible way, but it has one [possible] issue with initialization order. We can't predict the way headers are included and we can't predict the sequence of initialization.

First of all, let's think do we really need to keep icpp-compatibility at all. Or it is possible to forget about them once and for all.

Talking about the solution proposed (to inject registration calls with header - if I understand it correctly), I think this is possible way, but it has one [possible] issue with initialization order. We can't predict the way headers are included and we can't predict the sequence of initialization.

I always wondered why plugins are not initialized inside CONSOLE_APP_MAIN/GUI_APP_MAIN)

with auto-initialization classes

Hi Mirek,

That would be great! It would also make U++ much easier to use without theide. Using other IDEs or makefiles, cmake, etc. would lower the barrier for new users and could allow many more people to adopt U++.

Mindtraveller wrote on Sun, 28 August 2016 10:07

First of all, let's think do we really need to keep icpp-compatibility at all. Or it is possible to forget about them once and for all.

I'm definitely for dropping icpp completely, if possible. There are other uses, not only plugin-like stuff (e.g. files with Skylark handlers), but those could be solved in similar way I presume. Could there be a simple utility class for automatic initialization that could be used in all cases, even in user code?

struct GifInitializer { GicInitializer() { GifInitializerFunction(); } };

static GifInitializer DummyName;

void GifInitializerFunction() {}

INITBLOCK {
  ... register GIF in Draw
}

Well, first of all, let us not to forget that the problem we really need to have solved is to force linker to include some .obj files from .lib (or .o from .a ... even if none of symbols is referenced from the rest of the code. What I am proposing is basically putting a dummy call from header to such .obj, just to have it 'activated'.

Why not to use explicit method?

// upp_static_init.cpp
void upp_static_init() {
  {void plugin_gif_init(); plugin_gif_init();}
  // or this way
  #include <plugin/gif/gif.init>
  ...
}

[plugin/gif/gif.init]
{void plugin_gif_init(); plugin_gif_init();}

you'll have control over order of initialization and it looks like ordinary include.
And this file can be easyly generated with small tool.

May be something like this?

// lib1.h
#pragma once

int lib1_init();

#ifndef IMPL
int lib1_init_res=lib1_init();
#endif

// lib1.cpp
#define IMPL
#include "lib1.h"
#include <stdio.h>

int lib1_init() { printf("lib1\n");return 0; }

How about another explicit method

Generate in project dir file like this

// static_init.cpp
#define INIT(lib) extern int lib##_init(); lib##_init();
static int init() {
    INIT(lib1)
    INIT(lib2)
    INIT(lib3)
    // ....
    return 0;
}
static int init_result=init();

and link it to project. Just like .def file.
This is simple and you can control order of initialization. And no need of inline valiables support.