Wie machen das eigentlich die C++ Programmierer mit den includes?

[Aldimann]

Huhu zusammen ,

Java mit Eclipse oder ähnlichem Entwickeln ist ja relativ bequem. Autovervollständigung sei dank, kümmert sich um alle Imports und das nimm doch ungemein Arbeit ab .

Aber wie machen das eigentlich die C++ Programmierer mit ihren Includes und so weiter?

Hab mich mal umgeschaut, die Autovervollständigung funktioniert bei C++ IDEs eher unvollständig und nicht so gut und außerdem weiß ich gar nicht ob die sich auch solche Themen kümmert.

Merken C++ Programmierer sich alle includes die sie so für ein riesen Programm benötigen?

Grüße

 

[Marco13]

<sarkasmusMitEinemFunkenWahrheit>
Nein, die includes stehen im "WOM", dem Write-Only-Memory: Wenn eine fehlt, wird sie dazugeschrieben, aber ein Teufel getan, und daran etwas geändert, was nicht unbedingt nötig ist.
</sarkasmusMitEinemFunkenWahrheit>

 

[Andi_CH]

Wenn die include- bzw. importliste zu lang ist, stellt sich eh die Frage ob die Architektur gut ist ...

So wie ich mich erinnern kann, hatten wir nur in Ausnamefällen mehr als etwa 15 Einträge. (Das waren C++ Projekte - in Java hab ich noch nicht so viel Erfahrung mit grösseren Projekten)

 

[kama]

Hallo,

Merken C++ Programmierer sich alle includes die sie so für ein riesen Programm benötigen?

Das merkt man dann einfach, dass man entsprechende Compile Fehler bekommt...oder spätestens beim Linken fällt das auf...

Gruß
Karl Heinz Marbaise

 

[maki]

So wie ich mich erinnern kann, hatten wir nur in Ausnamefällen mehr als etwa 15 Einträge. (Das waren C++ Projekte - in Java hab ich noch nicht so viel Erfahrung mit grösseren Projekten)

In Java sind 60+ Libs nicht unüblich für Projekte mittlerer größe, je nachdem was man alles verwendet/braucht, und natürlich ob man sich alles selber schreibt (schlecht) oder eben auf bereits exitierende Komponenten zugreifft.

 

[Aldimann]

Also sind es in C++ schlicht weniger Einträge und somit leichter zu merken?

 

[Marco13]

So pauschal kann man das nicht sagen. Aber es wird vermutlich nicht selten pauschal gelöst: Was man braucht, wird in einen "includeEverything.h"-Header geklatscht, und dann hofft man, dass sich die Anzahl der Namenskollisionen in Grenzen hält.:bahnhof:

 

[tfa]

Man kann echt froh sein, dass es Java keine Header-Files oder Präprozessoren gibt. Ab ins Museum damit...

 

[bygones]

includeEverything.h"-Header geklatscht, und dann hofft man, dass sich die Anzahl der Namenskollisionen in Grenzen hält.:bahnhof:

zu geil wie man überall doch immer die das gleiche Verhalten sieht

 

[Marco13]

Ich würde zumindest versuchen das vermeiden, wenn ich für Entwurf und Entwicklung einer C++-Anwendung zuständig wäre (und nicht nur für die Wartung einer, in der noch vieeel schlimmere Sachen gemacht werden) ...

 

[Guest2]

Allgemein muss man als C/C++ Entwickler doch schon relativ schmerzresistent sein.

Beim Vergleich einer möglichen aktuellen Java Toolchain, also z.B in etwa.:

Eclipse + Mylyn + Maven + Continuum + Archiva + Git

vs. z.B.:

Visual Studio 2010 + Team Server/System

ist die Organisation der Imports vielleicht noch das kleinste fehlende Feature.

Gruß,
Fancy

 

[Andi_CH]

Also sind es in C++ schlicht weniger Einträge und somit leichter zu merken?

Hm merken muss man sich eigentlich nichts, der Compiler sagt schon wenn etwas fehlt, aber meistens merkt man ja selbst, wenn man etwas "fremdes" verwendet.

Ich habe gerade heute so "import aaa.bbb.*" Anweisungen gesehen ;-)

Das kann C++ nicht, aber dafür kann C++ schachteln

#include aaa.h
und das aaa.h includet 10 weitere und die .......... und alles ist sichtbar, daher kommen dann die #ifdef Anweisungen in den C-header files

Wenn 50 und mehr imports "üblich" sind, stelle ich halt in Frage ob üblicherweise die Architektur gut ist. (Ich höre immer wieder vom "organischen Wachstum" von SW Projekten - das ist nichts als eine dumme Ausrede für nacktes Chaos!)

Wie war das mit den Metriken? Schlanke Schnittstellen sind doch gefragt?
Wenn eine Datei < 500 Zeilen hat (stand eigentlich jedes mal so in den Code-Guidelines) braucht es keine zig includes / imports und ist dafür übersichtlich

 

[maki]

Wenn 50 und mehr imports "üblich" sind, stelle ich halt in Frage ob üblicherweise die Architektur gut ist.

Daraus kann man nicht auf die Architektur schliessen.
Finde auch dass die meisten Menschen das Wort "Architektur" viel zu schenll in den Raum werfen und eigentlich "Design" meinen.

Wie gesagt, sowas ist in Java vollkommen normal, Hibernate zB. besteht aus 2 dutzend Jars, JEE mit EJBs braucht auch sehr viel (nennt sich dann JEE Server ), Spring braucht auch viel imho, OSGi, ein Komponenetensystem hat natürgemäss sehr viele Jars als Abhängigkeiten (in meinem jetztigen Projekt, Eclipse RCP + OSGi +SpringDM + XMLRpc + Netty + etc. pp.) kommt auf über 70 Jars (bzw. OSGi Bundles), dazu kommen spezielle Abhängigkeiten nur für die Unittests, dank Maven2 alles kein Problem

. (Ich höre immer wieder vom "organischen Wachstum" von SW Projekten - das ist nichts als eine dumme Ausrede für nacktes Chaos!)

Nun, SW wächst nunmal Organisch, und wenn man nichts aktiv gegen das Chaos unternimmt, wird es größer, Entropie eben.
Im allgemeinen ist das imho ein Zeichen, dass man viel wiederverwendet anstatt sein Feuerholz jedesmal selber zu hacken, und das ist ein gutes Zeichen.

Wie war das mit den Metriken? Schlanke Schnittstellen sind doch gefragt?

Ja,hat aber rein gar nichts mit der Anzahl der verwendeten Libs zu tun.

Wenn eine Datei < 500 Zeilen hat (stand eigentlich jedes mal so in den Code-Guidelines) braucht es keine zig includes / imports und ist dafür übersichtlich

Richtig, in Java sind 250 Zeilen eine "gute" größe für eine Klasse.

 

[Andi_CH]

Architektur beschäftigt sich mit Schichten (Tiers), Verteilung der Aufgaben auf die Packages, Sichtbarkeiten, welches Package greift auf welches andere Package zu. (Wenn der letzte Punkt zu lasch gehandhabt wird, entstehen riesige Listen von Abhängigkeiten)

Design sehe ich innerhalb von Packages. Es geht eigentlich selten darüber hinaus - Verteilung der Aufgaben auf Klassen,

Verwendet werden sollten ja eh nur die Interfaceklassen (Achtung- ich meine nicht Java-Interfaces damit) der benachbarten Packages

Ach wie schön tönt doch die ideale Welt

 

[maki]

Architektur beschäftigt sich mit Schichten (Tiers), Verteilung der Aufgaben auf die Packages, Sichtbarkeiten, welches Package greift auf welches andere Package zu.

Ja, oder einfach ausgedrückt: "The Big Picture", oder "Die summe aller relevanten Entscheidungen"

(Wenn der letzte Punkt zu lasch gehandhabt wird, entstehen riesige Listen von Abhängigkeiten)

Ähm.. nein.
Du meinst dass die Abhängigkeiten einzelner Module (=Packages) zueineander sehr groß werden und meist auch noch kreuz & quer laufen
Das läuft unter dem Begriff "Kopplung", "Kohärenz" spielt da auch mit rein, oft bei Metriken verwendet.

OSGi kümmert sich um Abhängigkeiten zur Laufzeit, Maven zur Buildzeit, das Team muss aber dafür sorgen dass diese Abhänggikeiten keinen Architekturbruch darstellen, denn weder Maven noch OSGi kümmern sich um Kopplung & Kohärenz, OSGi hilft dabei wenn es richtig verwendet wird.

Dagegen stehen aber die Abhängigkeiten des gesamten Projektes, d.h. wenn ich im Frontend Eclipse RCP nutze, brauche ich dutzende Eclipse RCP OSGi bundles etc., wenn das Backend Hibernate einsetzt, brauche ich da eben die 2 dutzend Hibernate Abhängigkeiten.
Das Backend solte natürlich keine Eclipse RCP Abhängigkeiten haben und das Frontend keine (idealerweise) Hibernateabhängigkeiten, letzteres ist leider viel seltener als man meinen sollte, liegt u.a. am lazy Loading und daran dass die meisten Leute glauben ein ORM lernt man so nebenbei, ausserdem hat Sun das sozusagen provoziert indem sie sagten EJB3 Entity Beans sind Pojos und könnten auch ausserhalb vom Container laufen, dann kammen die Lazy Load Exceptions.

 

[Andi_CH]

Nun, SW wächst nun mal organisch und wenn man nichts aktiv gegen das Chaos unternimmt, wird es größer, Entropie eben.

1. Teil VETO: SW wächst überhaupt nicht, es sind wir die sie wachsen lassen. Nur chaotische Leute lassen SW organisch wachsen. Wie sagte Booch (ja ich weiss, der ist uralt aber das meiste was er sagte gilt heute noch) Analyze a little bit, design a little bit, code a little bit .... Er sagte nichts von code code code

Im Allgemeinen ist das imho ein Zeichen, dass man viel wiederverwendet anstatt sein Feuerholz jedesmal selber zu hacken, und das ist ein gutes Zeichen.

Ja, stimmt, aber auf einem eher tiefen (ich meine wenig abstrakten) Niveau. Auf abstrakterer Ebene sieht das anders aus. Soll die Businesslogik wirklich direkt auf einen IP Socket zureifen, wie ich es gerade letzte Woche gesehen habe? Antwort: NEIN (Es gibt da wirklich einen Kommunikationsproxy, der aber, weil er fehlerhaft war, ausgelassen wurde ... )

Ja,hat aber rein gar nichts mit der Anzahl der verwendeten Libs zu tun.

Da bin ich nicht ganz deiner Meinung. Längst nicht jeder Import ist eine Lib
Die Anzahl Imports zwischen Libs und, wie soll ich sagen?, nonLibs - halten sich im aktuellen Projekt in etwa die Waage.

Jeder import ist eine Linie auf dem UML Diagramm. Je mehr Linien und je mehr sich die Linien überkreuzen (Wollknäuel-Architektur bzw. Design) um so komplexer ist die Software (Banal gesagt )

 

[Andi_CH]

maki (Heute um 14:24 Uhr)

Das entstand währen meinem tippen

 

[maki]

1. Teil VETO: SW wächst überhaupt nicht, es sind wir die sie wachsen lassen. Nur chaotische Leute lassen SW organisch wachsen. Wie sagte Booch (ja ich weiss, der ist uralt aber das meiste was er sagte gilt heute noch) Analyze a little bit, design a little bit, code a little bit .... Er sagte nichts von code code code

Booch sagte doch das Software organisch wächst, Analyse, Design & Code passieren ständig, d.h. es kommen ständig neue Digne dazu, alte fliegen raus.
Das einzige Mittel um das Chaos zu beherrschen & neu zu ordnen ist Refactoring, aber ohne Tests ist das ein Spiel mit dem Feuer.
Blooch finde ich nicht alt, ganz im Gegenteil, es sind auch die "Alten" die Agile SW Entwicklung propagieren (und damit organisch wachsende SW), extreme Programming und alles was dazu gehört (Unittests, Refactoring, TDD, Continous Integration, etc. pp.) ist das wohl bekannteste Beispiel.
Robert Martin hat das in seinem Buch "Clean Code" schön erklärt.

Das Gegenteil davon wären die alten Phasenmodelle (V-Modell [XT]), wo man noch davon ausgeht, das alles in einem guß fertig wird und sich nichts an den Requirements nach der Analyze ändert.

Da bin ich nicht ganz deiner Meinung. Längst nicht jeder Import ist eine Lib
Die Anzahl Imports zwischen Libs und, wie soll ich sagen?, nonLibs - halten sich im aktuellen Projekt in etwa die Waage.

Dann hab ich dich wohl wieder falsch verstanden, mea culpa
Dachte du meinst nur imports von Fremdlibs, nicht alle imports.
Ja, zuviele imports in einer Javaklasse ist ein Zeichen dafür dass diese Klasse "zuviel macht".

Jeder import ist eine Linie auf dem UML Diagramm. Je mehr Linien und je mehr sich die Linien überkreuzen (Wollknäuel-Architektur bzw. Design) um so komplexer ist die Software (Banal gesagt )

Stimme dir auch da zu, würde aber anstatt "komplexer" lieber den Begriff "chaotischer" verwenden.