mikrocontroller.net

Forum: Compiler & IDEs Statische Bibliothek erstellen in C++


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von ~Mercedes~ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@an die C++ Hasen:

Wenn ich ne statische Bibliothek erstellen will,
was ist besser:

Alle Funktionen in einer Cpp Datei?
oder
Jede Funktion in eine separaten CPP Datei?,

um das eigendliche Client Programm möglichst klein
zu bekommen?

Das alle Deklarationen in die H. Datei gehören,
weiß ich. ;-O

Genauer:
Ich habe ne Bibliothek mit 100 Funktionen.
In meinem Client benötige ich aber nur eine davon.
Linkt der Linker jetzt diese Funktion aus der Objektdatei
oder kann er nur ganze Objektdateien in den Clienten einbinden?

Uff!!
Fragen über Fragen, hoffendlich versteht mich einer bei dem
Anliegen...


mfg

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
Mit link time optimization sollte das kein Problem sein.

Oliver

von Jemand (Gast)


Bewertung
1 lesenswert
nicht lesenswert
~Mercedes~ schrieb:
> Alle Funktionen in einer Cpp Datei?
> oder
> Jede Funktion in eine separaten CPP Datei?,

Wartbarkeit maximieren.

von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
~Mercedes~ schrieb:
> Alle Funktionen in einer Cpp Datei?
> oder
> Jede Funktion in eine separaten CPP Datei?,

Jede Funktion in einer separaten Datei.

Alternativ geht auch 1 Quelldatei, die dann mehrfach bedinge übersetzt 
wird, z.B. mit -DMODUL1, -DMODUL2, ... und entsprechende Abschnitte der 
Datei in #ifdef MODUL1 geklammert.

Je nach Build-Umgebung und Projektorganisation kann die eine oder andere 
Variante besser wartbar sein.

Für privaten Gebrauch und mit GNU-Tools (GCC) geht auch 1 Datei mit 
-ffunction-sections -fdata-sections und dann mit -Wl,--gc-sections 
linken.

Davon ab können sich Unterschiede ergeben, wenn man nur 1 riesigen Klotz 
compiliert wegen Inlining oder Cloning, bei fine-grained Modulen (also 
mit #ifdef oder n Quellen) besteht dieses Problem nicht.

von Wilhelm M. (wimalopaan)


Bewertung
1 lesenswert
nicht lesenswert
Was spricht gegen header-only?

von Bauform B. (bauformb)


Bewertung
1 lesenswert
nicht lesenswert
Oliver S. schrieb:
> Mit link time optimization sollte das kein Problem sein.
>
> Oliver

Das war doch mal eine der ersten und wichtigsten Aufgaben des Linkers? 
Damals, als es noch richtige Linker gab?

von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Oliver S. schrieb:
> Mit link time optimization sollte das kein Problem sein.

Nicht portierbar.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> Oliver S. schrieb:
>> Mit link time optimization sollte das kein Problem sein.
>
> Nicht portierbar.

Man muss den Code nicht ändern um auf einem anderen Compiler LTO nicht 
zu verwenden, der Code funktioniert auch ohne LTO. Also warum soll es 
nicht portierbar sein?

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Johann L. schrieb:
>> Oliver S. schrieb:
>>> Mit link time optimization sollte das kein Problem sein.
>>
>> Nicht portierbar.
>
> Man muss den Code nicht ändern um auf einem anderen Compiler LTO nicht
> zu verwenden, der Code funktioniert auch ohne LTO. Also warum soll es
> nicht portierbar sein?

Wenn kein LTO verwendet wird und LTO die (angebliche) Lösung für das 
Problem darstellen soll, dann ist es eben keine Lösung mehr.

Außerdem enthalten Object-Files nur lto und keinen (normalen) 
Object-Code (mehr), zumindest für GNU Tools.  Wenn also inkompatibles 
lto verwendet wird – zum Beispiel weil sich die lto-Spezifikation von 
einer Compilerversion zur nächsten geändert hat, was durchaus mal der 
Fall ist, dann ist es entweder keine Lösung (weil tote Funktionen 
vorhanden sind), oder der Compiler meckert – und dann ist es auch lein 
Lösung. Oder beides.

Dito mit -ffat-lto-objects.

Spielt natürlich nur eine Rolle wenn man die Libs ausliefert.  Zumindest 
in Standard-Libs wie libc.a will man definitiv keinen lto-Code.

von ~Mercedes~ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Meinen Dank, an alle hilfswilligen!

Hey, da sind sich noch nicht eimal die
Hasen richtig einig? ;-O

Es geht dabei um CLANG, genauer CLANG unter
Windows, noch genauer um den C++ Builder von
Embarcadero.
Und um kleine Tools mit grafischer Oberfläche zu erstellen.

Nun ist ja die Oberfläche objektorientiert und absolut
ineinander verzahnt, was bedeutet, das wenn man den kleinsten
Fuzz instanziiert, den ganzen Brocken in die EXE gelinkt bekommt.
Und Firemonkey, mit dem man geil Verspieltes machen kann,
ist sogar noch größer. :-(

Das wird man nicht verhindern können.

Wenn ich aber jetzt ne Lib erstelle, möchte ich wenigstens
nur die benötigten Funktionen meiner Lib in der exe haben.

Was ist LTO genau und kann CLANG das auch?

mfg

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
~Mercedes~ schrieb:
> Was ist LTO genau und kann CLANG das auch?

LTO steht für "link time optimization" und bewirkt genau das ;)

Der Compiler schreibt keine echten Objektfiles mehr, sondern legt in den 
.o-Dateien einen compilerspezifischen Zwischencode ab. Das eigentliche 
"fertig-compilieren" findet dann zur Link-Zeit statt.

Das wirkt sich (ungefähr) so aus, als ob Du alle Quellen in ein einziges 
C/C++-File geschrieben hättest. Dadurch, dass der Compiler so praktisch 
alle Quellen auf einmal zu sehen bekommt, kann er sehr viel besser 
optimieren (weil er beispielsweise so erkennen kann, welcher Code gar 
nicht benutzt wird oder wo sich inlining lohnt).

ja, clang kann das auch.

von Sven B. (scummos)


Bewertung
0 lesenswert
nicht lesenswert
Gibt auch noch den Trick alle cpp-Dateien in eine einzelne compilation 
unit zusammenzupasten, per Perl-Skript oder auch per #include. Sprich, 
du hast ganz normal organisierte Dateien, und dann nochmal eine die alle 
cpp-Dateien #included und nur die kompilierst du.

So oder so:
 1) Organisiere deine Dateien übersichtlich
 2) Probiere mit Compiler/Linker-Flags das zu erreichen was du willst
 3) Wenn und nur wenn das Ergebnis nicht gut genug ist, bau irgendwas in 
das Build-System ein was es besser macht.

Nicht den Code unlesbar machen um fragwürdige Optimierungen zu erzielen, 
das ist fast immer ein Fehler.

: Bearbeitet durch User
von Programmierer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Markus F. schrieb:
> ja, clang kann das auch.

Clang/LLVM hat damit sogar angefangen...

Johann L. schrieb:
> Nicht portierbar.

Ist kompilierter C++ Code sowieso kaum. Wenn man sich über Portabilität 
Gedanken macht, muss man sowieso prüfen zu welchen Toolchains es 
kompatibel sein soll und ob LTO hier konkret ein Hindernis ist.

von Vincent H. (vinci)


Bewertung
0 lesenswert
nicht lesenswert
Du entwickelst eine GUI Applikation und machst dir Gedanken über die 
Größe von 100 Funktionen? Darf ich Fragen wie groß die .exe eines 
Minimalbeispiels (Fenster mit X-Button) bei dem genutzten Framework ist?

von ~Mercedes~  . (lolita)


Bewertung
0 lesenswert
nicht lesenswert
Ne schön bunte "Hallo Board" Anwendung braucht
ungepackt rund 3 Mb, gepackt mit Winrar knapp 800 Kb.

Statisches Linken,  Optimierung -o3


mfg

von Vincent H. (vinci)


Bewertung
0 lesenswert
nicht lesenswert
Und wenn du die Lib mit den Funktionen dazu linkst? Ich kann mir nicht 
vorstellen das 100 Funktionen da großartig einen Unterschied machen.

von Sven B. (scummos)


Bewertung
0 lesenswert
nicht lesenswert
~Mercedes~  . schrieb:
> Ne schön bunte "Hallo Board" Anwendung braucht
> ungepackt rund 3 Mb, gepackt mit Winrar knapp 800 Kb.
>
> Statisches Linken,  Optimierung -o3

Jo ok, das ist dann wirklich eine völlig sinnlose premature optimization 
was du hier erfragst ;)
Vergiss es einfach und mach's irgendwie.

von Metu (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Was spricht gegen header-only?

- Lange compile-Zeiten
- Trashing von Namespaces mit nur für die Implementierung der Funktion 
relevanten Symbolen
- generell häufigere Rekompilierung durch für die Schnittstelle der 
Funktionen eigentlich völlig irrelevante Änderungen
- häufige Vermischung von Informationen, die ein Benutzer der 
Schnittstelle benötigt, mit völlig uninteressanten Details der 
Implementierung.

Für große Projekte daher vollkommen ungeeignet. Daraus folgend:
- schlechte Skalierbarkeit

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
~Mercedes~  . schrieb:
> Ne schön bunte "Hallo Board" Anwendung braucht
> ungepackt rund 3 Mb, gepackt mit Winrar knapp 800 Kb.

Das ist doch heutzutage vollkommen OK.

3MB in nem statisch gelinkten Binary das man überall einfach so ohne 
Installation laufen lassen kann ohne jegliche DLL-Hell sind mir allemal 
lieber als jedesmal separat noch dafür sorgen daß das benötigte 
GUI-Toolkit oder anderer Kram installiert ist oder einen Berg von DLLs 
mitliefern die dann insgesamt 30MB statt 3MB groß sind, vor allem auf 
Windows wo es keinen Paketmanager gibt der einem diesen Streß abnimmt.

3MB hätte mich vielleicht gestört in der Zeit als man noch mit 
1.44MB-Disketten unterwegs war, heute sind 3MB als vergleichsweise klein 
zu betrachten! Lass es einfach so, die Nutzer werden sich nicht 
beschweren, ganz im Gegenteil, die werden sich verwundert die Augen 
reiben daß diese ganze aufwendige Software nur aus dieser einen winzigen 
Datei besteht, sie werden Dich lobpreisen für diese Meisterleitung und 
andere die für vergleichbar komplexe Software nen 800MB Installer 
ausliefern ermahnen sich mal ein Beispiel an Dir zu nehmen!

: Bearbeitet durch User
von ~Mercedes~ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Huch?!?!

Bernd meinte:
> Das ist doch heutzutage vollkommen OK.

Aber der stumm schweigende Andreas wird mich
nicht loben, sondern skalpieren, wenn ich sein
Board vollmülle! ;-O ;-D
An mir ein Beispiel nehmen? Ich sehe zur Zeit
wie ne "Rechte Tussi" aus, mit meiner Glatze
mit Hieroglyphen drauf. :-O  ;--((
Nö. Ich brauche noch Zeit, bis ich ein Beispiel bin.

Was haltet ihr von Exepackern?
Son Teil, was die EXE beim Starten automatisch entpackt?
Oder das man die Ressurcen komprimiert in der
Exe hält, etwa durch ein Single Dateisystem?

mfg

von Kristallkugel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
~Mercedes~ schrieb:
> Was haltet ihr von Exepackern?
> Son Teil, was die EXE beim Starten automatisch entpackt?

Kann man machen, ein bekannter Packer ist UPX. Bei gepackten EXE kann es 
bei Antivirenprogrammen schon mal zu Fehlalarmen kommen.

von Bernd K. (prof7bit)


Bewertung
1 lesenswert
nicht lesenswert
~Mercedes~ schrieb:
> Was haltet ihr von Exepackern?
> Son Teil, was die EXE beim Starten automatisch entpackt?

Braucht mehr Speicher weil alles ins RAM entpackt und dort gehalten 
werden muss anstatt einfach nur die gerade benötigten Teile zu mappen.

Und es ist vollkommen unnötig weil Dein C++-Builder oder Delphi bereits 
erstaunlich kleine Exe macht. Die von Lazarus sind sogar noch nen Tick 
größer, aber selbst die sind noch um Faktor 10 unter jeglicher denkbarer 
Schmerzgrenze.

Also vergiss den Blödsinn einfach und kümmer Dich stattdessen um das 
eigentliche Programmierproblem anstatt Zeit mit der Prokrastination über 
derartigem nutzlosen Unsinn zu vergeuden. Du könntest schon halb fertig 
sein, also mach hin!

: Bearbeitet durch User
von ~Mercedes~  . (lolita)


Bewertung
1 lesenswert
nicht lesenswert
Bernd K. schrieb:
> ~Mercedes~ schrieb:
>> Was haltet ihr von Exepackern?
>> Son Teil, was die EXE beim Starten automatisch entpackt?
>
> Braucht mehr Speicher weil alles ins RAM entpackt und dort gehalten
> werden muss anstatt einfach nur die gerade benötigten Teile zu mappen.

  Gilt das auch für DLL'S? Werden die auch vollständig geladen?

> Und es ist vollkommen unnötig weil Dein C++-Builder oder Delphi bereits
> erstaunlich kleine Exe macht. Die von Lazarus sind sogar noch nen Tick
> größer, aber selbst die sind noch um Faktor 10 unter jeglicher denkbarer
> Schmerzgrenze.

  Wirklich? Wenn Du es sagst... :-O

> Also vergiss den Blödsinn einfach und kümmer Dich stattdessen um das
> eigentliche Programmierproblem anstatt Zeit mit der Prokrastination über
> derartigem nutzlosen Unsinn zu vergeuden. Du könntest schon halb fertig
> sein, also mach hin!

  Erst muß ich meine OP überstehen... ;---O

 Ich danke allen Beteiligten des Threads für Eure Hilfe!

 mfg

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.