Ich habe einen Vorschlag für den nächsten Standard, und auch wenn ich ihn niemals proposen werde, wollte ich trotzdem ein paar Meinungen dazu einholen.

Meine Idee ist, statische Konstruktoren und Destruktoren für Übersetzungseinheiten einzuführen. Die Syntax wäre dabei wie folgt:

static : initializer-list // optional
{
    // code
}

~static
{
    // code
}

Warum will ich ein solches Sprachfeature? Ich habe erst letztens bemerkt, was für ein PITA es ist, globale Variablen von nicht kopierbaren, nicht movebaren Typen zu haben. In meinem Fall habe ich einen std::ostream und es so "gelöst":

std::ofstream of(filename);

std::ostream& init_get_stream()
{
	set_time_formatting(of, "%Y/%m/%d %H:%M:%S.%f");
	return of;
}

std::ostream& get_stream()
{
	static std::ostream& os = init_get_stream();
	return os;
}

Nachteile: Obskur, erfordert zusätzliche Referenz, für jede globale Variable im Worst-Case 2 Funktionen zusätzlich.

Möglichkeit 2: Singleton.
Nachteil: Eine Klasse ist designtechnisch das falsche Werkzeug, ich betrachte das als Hack. Außerdem immer noch umständlich.

Lösung mit statischem Konstruktor:

std::ofstream of;

std::ostream& get_stream() { return of; }

static : of(filename)
{
	set_time_formatting(of, "%Y/%m/%d %H:%M:%S.%f");
}

Viel kürzer, übersichtlicher, und drückt meine Intention direkt aus. (Die Initializer-List ist selbstverständlich optional, die Direktinitialisierung wäre weiterhin erlaubt.)

Als weiteres Beispiel könnte man die Windows Socket-API nennen, die bekanntermaßen das Aufrufen der Startup und Cleanup-Funktionen erfordert. Sowas könnte eine dazugelinkte Bibliothek mithilfe dieses Features erledigen.

Was haltet ihr von dieser Idee?

Grüße,
Der Kellerautomat

namespace
{
  ostream& get_stream()
  {
    ...
  }
}

std::ostream& os = get_stream();

Die Funktion get_stream dient dazu, Variablen im Header unsichtbar zu machen (sprich: Kapselung). Du müsstest also noch eine Funktion für deine Referenz schreiben.

Wozu dann die globale Variable?

ostream& get_stream()
{
  static ofstream of(filename);
  static auto _=[&of]{return set_time_formatting(of, "%Y/%m/%d %H:%M:%S.%f"),0;}();
  return of;
}

ostream& get_stream()
{
  static struct _ {
    ofstream of;
    _() : of("filename.txt") {set_time_formatting(of, "%Y/%m/%d %H:%M:%S.%f");}
    ~_() { of << "Schluss\n"; }
  } _;
  return _.of;
}

ostream& get_stream()
{
  static ofstream of("filename.txt");
  static std::once_flag _;
  std::call_once(_, set_time_formatting, std::ref(of), "%Y/%m/%d %H:%M:%S.%f");
  return of;
}

Alles zwei "Funktionen", genau wie dein "static Ctor":

1. Lambda
2. Ctor des lokalen Objekts
3. implizit durch call_once

den static Dtor kriegst du mit der zweiten Variante auch problemlos hin - du kommst sogar um das static initialization fiasko herum, das mit den static ctro/dtors nicht gelöst wird, weil die soweit ich das sehe offenbar nur auf tatsächlich globalen Variablen arbeiten sollen - global oder funktionsstatisch ist nämlich alles andere als egal.

Das sind doch alles nur hässliche Workarounds...

Der statische Konstruktor wäre auch kein Kind von Schönheit. Erst recht nicht, wenn man das static initilization fiasko im Hinterkopf behält.

Seien wir mal ehrlich: non-movable, non-copyable Objekte sind schwiergig. Gloabel Variablen sind grundsätzlich unschön. Beides zusammen wird dann allmählich eklig, ist aber gottseidank selten. Das machen Workarounds in der Sprache auch nicht schöner.

Davon abgesehen wage ich zu behaupten, dass die call_once Funktionalität genau für solche Zwecke geschaffen wurde - und Dinge wie Threadsicherheit gleich mit verarztet.

Der statische Konstruktor wäre auch kein Kind von Schönheit. Erst recht nicht, wenn man das static initilization fiasko im Hinterkopf behält.

Ich habe nicht so Recht verstanden, was du meinst, aber es lässt sich bestimmt zufriedenstellend lösen.

pumuckl schrieb:

Gloabel Variablen sind grundsätzlich unschön.

Das mag schon sein, aber wenn ich sie brauche, dann ist das nunmal so. Ich sehe auch nicht, warum einem die Sprache in diesem Fall nicht helfen sollte.

pumuckl schrieb:

Gloabel Variablen sind grundsätzlich unschön.

Das mag schon sein, aber wenn ich sie brauche, dann ist das nunmal so.

Aber das Design lässt sich immer so umsetzen, dass man sie nicht braucht. Es gibt wirklich nur sehr wenige Fälle ( std::cin, std::cout, std::cerr , Qts qApp , usw.) wo es wirklich Sinn macht, eine Variable global zu deklarieren.

namespace {
   struct staticCtor {
      staticCtor() {
         WSAStartup();
      }
      ~staticCtor() {
         WSACleanup();
      }
   } o;
}

Das ganze scheitert einfach nur daran, dass es keine definierte Initialisierungsreihenfolge. Das Problem löst sich mit einem static Ctor auch nicht. Aber die funktionalität ist da.

Wenn es ein Modulkonzept gibt, dann lässt sich darüber reden wie man sowas implementiert. Aber für das aktuelle ÜE-Konzept von C++ bringt es nichts.

Lösung mit statischem Konstruktor:

std::ofstream of;
 
std::ostream& get_stream() { return of; }
 
static : of(filename)
{
	set_time_formatting(of, "%Y/%m/%d %H:%M:%S.%f");
}

Viel kürzer, übersichtlicher, und drückt meine Intention direkt aus.

Hmm ich weiß nicht, ob man "globale Objekte" jetzt wirklich besser unterstützen sollte. Gibt ja genug Probleme mit der Initialisierungsreihenfolge. Wie wär es damit:

std::ostream& get_stream()
{
  static std::ostream& os_ref = []()->std::ostream&
  {
    static std::ostream os (filename);
    set_time_formatting(of, "%Y/%m/%d %H:%M:%S.%f");
    return os;
  }();
  return os_ref;
}

?

(beide static s sind hier wichtig)

Eine Initialisierungsreihenfolge lässt sich im Übrigen auch festlegen - daran solls nicht scheitern.

Wie willst du die denn festlegen? Mach mal einen Vorschlag.

Genau wie bei Klassenmembern: Definitionsreihenfolge.

Ah, dann hast du an etwas anderes gedacht, nämlich an die Definitionsreihenfolge innerhalb einer Übersetzungseinheit. Die ist ja, soweit ich weiß, auch schon festgelegt. Aber es ist nicht festgelegt, in welcher Reihenfolge die Objekte unterschiedlicher Übersetzungseinheiten dran kommen. Siehe static initialization order fiasco. Deswegen sind "static function locals" mit ihrer "lazy initialization" da viel interessanter.

Na und? Ist doch egal...

Bis auf dass dein Programm halt wegen einer Access Violation abschmiert.

Aber bis auf diese Kleinigkeit ists egal, ja.

Ich verwende sie doch gar nicht vor main(), also wo liegt euer Problem? Gleich mal voreilig beschweren, obwohl man die Verwendung nicht kennt?

Es ging um Übersetzungseinheiten und Initialisierungsreihenfolge. Und nicht ob jetzt ein konkreter Code funktioniert - deine Idee ist Broken By Design. Das ist der Punkt.

Tjoah, UB ist eben UB. Ein guter Compiler warnt vor sowas.

Vor manchen kann auch ein Compiler nicht warnen.

Ganz davon abgesehen können die Auswirkungen recht langwierige Suchen erfordern (Wir hatten in einem Projekt einen solchen Fall, den Fehler haben wir erst Wochen später entdeckt).