Programmieren ohne Header Files

[Kamikaze]

Im Entropia hat bei mir am Sonntag jemand moderates Interesse an D geweckt. Das werde ich zumindest mal im Hinterkopf behalten.

Sprach der Mensch, der seinen Forscherdrang in Projekten zur nutzlosen Verbrennung von fossilen Rohstoffen auslebt.

Das kann ich durchaus begründen und rechtfertigen. Auch in ökologischer Hinsicht. :P

 

[Sickboy]

Das kann ich durchaus begründen und rechtfertigen. Auch in ökologischer Hinsicht. :P

Auf die Begründung bin ich gespannt (gerne im zitierten Thread).

 

[dettus]

Ich kann auf das Präprozessorprinzip gerne verzichten,

moep!
moep!
moep!

nope, ich arbeite hier an produkten die auf mehreren plattformen unterschiedlich gecodet werden muessen.
auf dem pc gebe ich dir recht, aber gerade im schmalbruestigen embeddet-bereich ist es unverzichtbar.


hier sind auch header sehr wichtig: man muss schliesslich ab- und zu mal ein struct von einem pc auf einen arm schieben koennen. und die sollten sich auch verstehen.
mit einem konsistenten header den man einfach teilen kann ist das moeglich.

 

[darktrym]

Damit wir uns hier nicht falsch verstehen, gewisse Konstrukte sind außerhalb des eigentlichen Sources besser aufgehoben, deshalb ist die Idee von der Trennung und Abstraktion nicht schlecht gemeint. Aber wieso muss C/C++ immer den kompletten Header importieren, wieso können nicht Teile übernommen werden? Wieso muss man mehrfach durch, um immer wieder die gleiche Information in Objektfiles abzulegen, damit der Compiler nicht zur Ruh' kommt. Von den Nebeneffekten mal ganz abgesehen.

 

[dettus]

weil du so auch mal eine vorcompilierte library mit header files verkaufen kannst.
ohne dass du den sourcecode mit rausgeben musst.


tut mir leid dass ich das nicht besser formulieren kann. aber wie gesagt: praeprozessordefines und header files sind im professionellen umfeld einfach wichtig. und werden deswegen auch nicht weggekuerzt werden.
dass sich im laufe der jahrzehnte viel mist im standard angesammelt hat moechte ich jetzt nicht verleugnen.

 

[Yamagi]

Zu D aka D2: D ist an sich eine sehr schöne Sprache, die viele Fehler und historische Probleme von C++ und seinen Derivaten auflöst. Das Modul-System als Ersatz für Header ist schon sehr sexy. Allerdings hat das Ökosystem um die Kernsprache herum noch immer viele raue Kanten, sodass es inzwischen leider zu bezweifeln ist, dass sie jemals über eine Nische hinauskommt. Das beginnt bei der noch immer sehr löchrigen Standardbibliothek. Viele Bereiche wie Container-Klassen sind einfach unvollständig und mangels Entwicklern sowie langen Review-Prozessen geht es dort auch nicht wirklich weiter. Die Runtime-Bibliothek ist eine gute Sache, aber in kritischen Stellen wie dem Garbage-Collector sehr rudimentär implementiert. Der Compiler übersetzt zwar schnell, der sich ergebende Code ist aber oft sehr langsam und weit ab von der Performance von JIT-Sprachen oder gar C++ . Es gibt zwar mit gdc ein GCC-Fontend, was aber auch aufgrund der durchaus berechtigten Kritik der GCC-Entwickler trotz mehrerer Versuche nicht in GCC gemerged wurde und auch nicht gerade optimalen Code generiert.

 

[Sickboy]

Der Compiler übersetzt zwar schnell, der sich ergebende Code ist aber oft sehr langsam und weit ab von der Performance von JIT-Sprachen oder gar C++.

Und ich dachte, D würde eine gute Performance bringen. Zumindest das in D geschriebene Forum ist sehr schnell. Aber wahrscheinlich merkt man dort den Unterschied einfach nicht.

 

[Yamagi]

Ja, die Sprache an sich kann schon sehr schnell sein. Bei der Entwicklung wurde sehr darauf geachtet, möglichst effizienten Code generieren zu können. Leider wird das Potential noch nicht genutzt.