Womit programmiert die NASA

rüdiger

pale dog, es lohnt sich eh nicht mit dir darüber zu diskutieren. Aber Templates sind sicher kein unkontrolierbareres Feature, als andere auch. Das man für zwei verschiedene Typen den Code doppelt hat (was so auch nicht stimmt, da nur Code angelegt werden muss der wirklich genutzt wird), hättest du ja auch wenn du den Code händisch für zwei Typen anlegst. Wie gesagt: Bei Templates kann der Compiler ohne Probleme toten Code aufräumen und ist viel freier in der Optimierung.

Aber egal was wir für Argumente bringen werden, wirst du es eh nicht einsehen wollen und auf C beharren. Meinetwegen mach das. Aber wie gesagt, es gibt Firmen die auf C++ für µC setzen und das sind zum Teil Industriegrößen. zB schreibt Lockheed Martin die Software für ihre Kampfflugzeuge mit C++ und ich glaube nicht, dass die total ahnungslose ineffiziente Deppen sind... Im Gegenteil glaube ich eher das dort ein haufen ziemlich kompetenter Ingenieure arbeitet, die sich nicht so leicht scheiß andrehen lassen...

Fye

pale dog schrieb:

mastercpp schrieb:

pale dog schrieb:

mastercpp schrieb:

Und templates sind entgegen der Meinung vieler µC-C-Programmieren sehr gut für µC geeignet, da nur der Code compiliert wird, der auch wirklich benötigt wird.

...aber bei jeder instanziierung

Nur einmal pro Datentyp..

nicht pro vorkommen im quellcode? wenn man ein z.b. ein function template instanziiert, packt man sich doch immer unüberschaubar viel code an diese stelle. so wie ein zwangs-inline...

Da wird nichts inlined:

template<typename T> T add(T a, T b)
{
  return a + b;
}

int main()
{
  return add(add(3, 5), add(5, 7));
}

a.out:     file format elf32-msp430

Disassembly of section .text:

[...]	

0000fc40 <main>:
  return a + b;
}

int main()
{
    fc40:	31 40 80 02 	mov	#640,	r1	;#0x0280
    fc44:	04 41       	mov	r1,	r4	;
  return add(add(3, 5), add(5, 7));
    fc46:	3e 40 07 00 	mov	#7,	r14	;#0x0007
    fc4a:	3f 40 05 00 	mov	#5,	r15	;#0x0005
    fc4e:	b0 12 6a fc 	call	#-918		;#0xfc6a
    fc52:	0b 4f       	mov	r15,	r11	;
    fc54:	3e 40 05 00 	mov	#5,	r14	;#0x0005
    fc58:	3f 40 03 00 	mov	#3,	r15	;#0x0003
    fc5c:	b0 12 6a fc 	call	#-918		;#0xfc6a
    fc60:	0e 4b       	mov	r11,	r14	;
    fc62:	b0 12 6a fc 	call	#-918		;#0xfc6a
}
    fc66:	30 40 8e fc 	br	#0xfc8e		;

0000fc6a <_Z3addIiET_S0_S0_>:
    fc6a:	05 12       	push	r5		;
    fc6c:	04 12       	push	r4		;
    fc6e:	05 41       	mov	r1,	r5	;
    fc70:	35 50 06 00 	add	#6,	r5	;#0x0006
    fc74:	21 82       	sub	#4,	r1	;r2 As==10
    fc76:	04 41       	mov	r1,	r4	;
    fc78:	84 4f 00 00 	mov	r15,	0(r4)	;
    fc7c:	84 4e 02 00 	mov	r14,	2(r4)	;
    fc80:	2f 44       	mov	@r4,	r15	;
    fc82:	1f 54 02 00 	add	2(r4),	r15	;
    fc86:	21 52       	add	#4,	r1	;r2 As==10
    fc88:	34 41       	pop	r4		;
    fc8a:	35 41       	pop	r5		;
    fc8c:	30 41       	ret			

[...]

:p

Mr. N

$ g++ -O3 -S -o - -x c++ - <<EOC
> template<typename T> T add(T a, T b) 
> { 
>   return a + b; 
> } 
> 
> int main() 
> { 
>   return add(add(3, 5), add(5, 7)); 
> }
> EOC
        .file   ""
        .text
        .align 2
        .p2align 4,,15
.globl main
        .type   main, @function
main:
.LFB3:
        movl    $20, %eax
        ret
.LFE3:
        .size   main, .-main
.globl __gxx_personality_v0
        .section        .eh_frame,"a",@progbits
.Lframe1:
        .long   .LECIE1-.LSCIE1
.LSCIE1:
        .long   0x0
        .byte   0x1
        .string "zPR"
        .uleb128 0x1
        .sleb128 -8
        .byte   0x10
        .uleb128 0x6
        .byte   0x3
        .long   __gxx_personality_v0
        .byte   0x3
        .byte   0xc
        .uleb128 0x7
        .uleb128 0x8
        .byte   0x90
        .uleb128 0x1
        .align 8
.LECIE1:
.LSFDE1:
        .long   .LEFDE1-.LASFDE1
.LASFDE1:
        .long   .LASFDE1-.Lframe1
        .long   .LFB3
        .long   .LFE3-.LFB3
        .uleb128 0x0
        .align 8
.LEFDE1:
        .ident  "GCC: (GNU) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)"
        .section        .note.GNU-stack,"",@progbits

Nochmal:

main:
.LFB3:
        movl    $20, %eax
        ret

oder in Intel-Syntax:

mov eax, 20
ret

Du musst nur Optimierung anstellen.

Fye

Mr. N schrieb:

Du musst nur Optimierung anstellen.

Cheater!

Nee, mal im Ernst: Klar, dass bei -O3 ge-inlined wird. Durch Wegfall des call/ret und dem stack-kram ist das ganze natürlich schneller:

0000fc40 <main>:
  return a + b;
}

int main()
{
    fc40:	31 40 80 02 	mov	#640,	r1	;#0x0280
  return add(add(3, 5), add(5, 7));
}
    fc44:	3f 40 14 00 	mov	#20,	r15	;#0x0014
    fc48:	30 40 4c fc 	br	#0xfc4c		;

Aber wenn man Wert darauf legt, dass nicht tonnenweise Code ge-inlined wird, kopiliert man natürlich mit -Os!

0000fc40 <main>:
  return a + b;
}

int main()
{
    fc40:	31 40 80 02 	mov	#640,	r1	;#0x0280
  return add(add(3, 5), add(5, 7));
    fc44:	3e 40 07 00 	mov	#7,	r14	;#0x0007
    fc48:	3f 40 05 00 	mov	#5,	r15	;#0x0005
    fc4c:	b0 12 68 fc 	call	#-920		;#0xfc68
    fc50:	0b 4f       	mov	r15,	r11	;
    fc52:	3e 40 05 00 	mov	#5,	r14	;#0x0005
    fc56:	3f 40 03 00 	mov	#3,	r15	;#0x0003
    fc5a:	b0 12 68 fc 	call	#-920		;#0xfc68
    fc5e:	0e 4b       	mov	r11,	r14	;
    fc60:	b0 12 68 fc 	call	#-920		;#0xfc68
}
    fc64:	30 40 6c fc 	br	#0xfc6c		;

0000fc68 <_Z3addIiET_S0_S0_>:
    fc68:	0f 5e       	add	r14,	r15	;
    fc6a:	30 41       	ret

Mr. N

Fye schrieb:

Aber wenn man Wert darauf legt, dass nicht tonnenweise Code ge-inlined wird, kopiliert man natürlich mit -Os!

Ich will aber, dass tonnenweise Code ge-inlined wird.

Sonst wäre mein Programmierstil untragbar.

Artchi

Ich hatte ja auch mal eine Bericht gepostet, wo "BMW CarIT" über den Einsatz von C++ im CAN-Bus geschrieben hat. Hat pale dog auch als "Unsinn" abgetan. pale dog braucht man nicht ernst nehmen... weil er alle anderen für Idioten hält, selbst wenn es große bekannte Firmen sind.

Paddy82

Ich arbeite in einem großen Rüstungsunternehmen.

Bei uns nutzen wir sowohl C, C++, Ada und auch (sehr sehr selten) C#. Kommt immer auf die Projekte an.

Ich glaube, dass die NASA auch nur mit Wasser kocht und dass es ganz normale Ingenieure und Entwickler sind, die nur entsprechend viel Geld in ihren Projekten zur Verfügung gestellt bekommen um sehr viel zu testen. Unsere Flugsysteme werden ebenfalls sehr viel getestet und haben dementsprechend wenig Fehler.

Auch das CERN entwickelt mit C++ (die haben doch irgend so einen open source C++ interpreter rausgebracht). Bei CERN sehe ich mehr Know How und Kompetenzen als bei der NASA.

Ich denke, dass es total egal ist, ob man nun mit C, C++ oder Ada programmiert. Die Hauptsache ist, dass genügend Geld zum Testen und Entwickeln da ist.

Dass bei der Microcontrollerprogrammierung nicht auf C#, Java oder eine andere interpretierte Sprache gesetzt wird, wird hier doch allen genauso klar sein, wie dass in den meisten Bereichen des Shuttle kein Windows Xp laufen wird.

Gruß Paddy

Artchi schrieb:

Ich hatte ja auch mal eine Bericht gepostet, wo "BMW CarIT" über den Einsatz von C++ im CAN-Bus geschrieben hat. Hat pale dog auch als "Unsinn" abgetan. pale dog braucht man nicht ernst nehmen... weil er alle anderen für Idioten hält, selbst wenn es große bekannte Firmen sind.

Du bleibst es aber bis heute schuldig mir den großen Sinn hinter dem Artikel zu nennen. Gebetsmühlenartiges Wiederholen der Existenz dieses Artikels bringts nicht. Dass es prinzipielll geht wundert niemand. So what?

pale dog

rüdiger schrieb:

Aber egal was wir für Argumente bringen werden, wirst du es eh nicht einsehen wollen und auf C beharren. Meinetwegen mach das. Aber wie gesagt, es gibt Firmen die auf C++ für µC setzen und das sind zum Teil Industriegrößen. zB schreibt Lockheed Martin die Software für ihre Kampfflugzeuge mit C++ und ich glaube nicht, dass die total ahnungslose ineffiziente Deppen sind... Im Gegenteil glaube ich eher das dort ein haufen ziemlich kompetenter Ingenieure arbeitet, die sich nicht so leicht scheiß andrehen lassen...

naja, wir wissen nicht, was sie dazu bewogen hat auf C++ zu setzen, aber wir sollten mal davon ausgehen, dass sie auch wissen, dass es sowas wie ADA gibt.
wenn's um 'bugfestigkeit' geht, beharre ich übrigens nicht auf C. beide, C und C++ sind in dieser hinsicht nicht das gelbe vom ei
ich glaube allerdings kaum, dass lockheed C++ in kritischen bereichen einsetzt, in denen programmierfehler menschenleben kosten können. wenn doch, dann sind es wirklich deppen oder sie treiben einen irren aufwand, um fehler im vorfeld auszuschliessen.

@templates:
optimierung ist fein, aber C compiler für µC optimieren ohnehin sehr aggressiv d.h. ein codewarrior z.b. hätte genau das gleiche getan mit eurer 'add'-funktion, nämlich einen konstanten wert eingesetzt und fertich
aber es gibt auch template-funktionen, für die ein compiler handfesten code erzeugen *muss*, weil erst zur laufzeit verschiedene bedingungen auftreten können und diesen code erzeugt er ja wohl immer, wenn das template instanziiert wird, oder liege ich da falsch?

btw: ich find templates übrigens gut. in C benutze ich oft #defines und manchmal wünsche ich mir, dass die so mächtig wie templates wären...

Tim schrieb:

Artchi schrieb:

Ich hatte ja auch mal eine Bericht gepostet, wo "BMW CarIT" über den Einsatz von C++ im CAN-Bus geschrieben hat. Hat pale dog auch als "Unsinn" abgetan. pale dog braucht man nicht ernst nehmen... weil er alle anderen für Idioten hält, selbst wenn es große bekannte Firmen sind.

Du bleibst es aber bis heute schuldig mir den großen Sinn hinter dem Artikel zu nennen.

einfach nur werbung, public relations. die firmen wollen damit zeigen, was sie für tolle entwicklungsmannschaften mit viel know-how haben.

Mr. N

pale dog schrieb:

@templates:
optimierung ist fein, aber C compiler für µC optimieren ohnehin sehr aggressiv d.h. ein codewarrior z.b. hätte genau das gleiche getan mit eurer 'add'-funktion, nämlich einen konstanten wert eingesetzt und fertich

Es geht darum, dass Templates die Optimierung nicht verhindern.

pale dog schrieb:

aber es gibt auch template-funktionen, für die ein compiler handfesten code erzeugen *muss*, weil erst zur laufzeit verschiedene bedingungen auftreten können und diesen code erzeugt er ja wohl immer, wenn das template instanziiert wird, oder liege ich da falsch?

Und wo wird da bitte mehr Code erzeugt als im Nicht-Template-Fall?

pale dog schrieb:

btw: ich find templates übrigens gut. in C benutze ich oft #defines und manchmal wünsche ich mir, dass die so mächtig wie templates wären...

Wenn du kein C++ einsetzen kannst, ist das wohl Pech.

.filmor

pale dog schrieb:

ich glaube allerdings kaum, dass lockheed C++ in kritischen bereichen einsetzt, in denen programmierfehler menschenleben kosten können. wenn doch, dann sind es wirklich deppen oder sie treiben einen irren aufwand, um fehler im vorfeld auszuschliessen.

Und du glaubst, das müssten sie nur mit C++ oder anderen Sprachen ohne strenge Laufzeitumgebung?!

pale dog schrieb:

aber es gibt auch template-funktionen, für die ein compiler handfesten code erzeugen *muss*, weil erst zur laufzeit verschiedene bedingungen auftreten können und diesen code erzeugt er ja wohl immer, wenn das template instanziiert wird, oder liege ich da falsch?

Tust du imho. Templates kennen keine Laufzeit. Alle Parameter sind Compilezeitkonstanten.

pale dog schrieb:

btw: ich find templates übrigens gut. in C benutze ich oft #defines und manchmal wünsche ich mir, dass die so mächtig wie templates wären...

Ne, tust du nicht. #defines funktionieren nur auf Textebene, da will man nichts magisches

rüdiger

pale dog schrieb:

rüdiger schrieb:

Aber egal was wir für Argumente bringen werden, wirst du es eh nicht einsehen wollen und auf C beharren. Meinetwegen mach das. Aber wie gesagt, es gibt Firmen die auf C++ für µC setzen und das sind zum Teil Industriegrößen. zB schreibt Lockheed Martin die Software für ihre Kampfflugzeuge mit C++ und ich glaube nicht, dass die total ahnungslose ineffiziente Deppen sind... Im Gegenteil glaube ich eher das dort ein haufen ziemlich kompetenter Ingenieure arbeitet, die sich nicht so leicht scheiß andrehen lassen...

naja, wir wissen nicht, was sie dazu bewogen hat auf C++ zu setzen, aber wir sollten mal davon ausgehen, dass sie auch wissen, dass es sowas wie ADA gibt.
wenn's um 'bugfestigkeit' geht, beharre ich übrigens nicht auf C. beide, C und C++ sind in dieser hinsicht nicht das gelbe vom ei
ich glaube allerdings kaum, dass lockheed C++ in kritischen bereichen einsetzt, in denen programmierfehler menschenleben kosten können. wenn doch, dann sind es wirklich deppen oder sie treiben einen irren aufwand, um fehler im vorfeld auszuschliessen.

Laut Stroustrup benutzen sie das für "airplane control". Hört sich also schon kritisch an. Aber sie haben wohl einen sehr strikten Coding-Guideline http://www.research.att.com/~bs/JSF-AV-rules.pdf

@templates:
optimierung ist fein, aber C compiler für µC optimieren ohnehin sehr aggressiv d.h. ein codewarrior z.b. hätte genau das gleiche getan mit eurer 'add'-funktion, nämlich einen konstanten wert eingesetzt und fertich
aber es gibt auch template-funktionen, für die ein compiler handfesten code erzeugen *muss*, weil erst zur laufzeit verschiedene bedingungen auftreten können und diesen code erzeugt er ja wohl immer, wenn das template instanziiert wird, oder liege ich da falsch?

btw: ich find templates übrigens gut. in C benutze ich oft #defines und manchmal wünsche ich mir, dass die so mächtig wie templates wären...

Ne, der Compiler erzeugt nicht blind Code. Aber wenn er ihn erzeugen muss, unterscheidet sich das nicht von einer normalen Funktion.

pale dog

Mr. N schrieb:

pale dog schrieb:

aber es gibt auch template-funktionen, für die ein compiler handfesten code erzeugen *muss*, weil erst zur laufzeit verschiedene bedingungen auftreten können und diesen code erzeugt er ja wohl immer, wenn das template instanziiert wird, oder liege ich da falsch?

Und wo wird da bitte mehr Code erzeugt als im Nicht-Template-Fall?

im nicht-template fall existiert der code nur einmal und wird als funktion aufgerufen.

Mr. N schrieb:

pale dog schrieb:

btw: ich find templates übrigens gut. in C benutze ich oft #defines und manchmal wünsche ich mir, dass die so mächtig wie templates wären...

Wenn du kein C++ einsetzen kannst, ist das wohl Pech.

ach, eigentlich bin ich ganz froh, dass ich C++ nicht benutzen muss...

.filmor schrieb:

pale dog schrieb:

ich glaube allerdings kaum, dass lockheed C++ in kritischen bereichen einsetzt, in denen programmierfehler menschenleben kosten können. wenn doch, dann sind es wirklich deppen oder sie treiben einen irren aufwand, um fehler im vorfeld auszuschliessen.

Und du glaubst, das müssten sie nur mit C++ oder anderen Sprachen ohne strenge Laufzeitumgebung?!

ich glaube mit ADA o.ä. viel weniger als mit C oder C++. ADA bietet doch diverse error-check- (beim compilieren sowie zur laufzeit) und recovery-mechanismen. nicht ohne grund ist ADA erste wahl bei den herstellern von fluggeräten.

.filmor schrieb:

pale dog schrieb:

aber es gibt auch template-funktionen, für die ein compiler handfesten code erzeugen *muss*, weil erst zur laufzeit verschiedene bedingungen auftreten können und diesen code erzeugt er ja wohl immer, wenn das template instanziiert wird, oder liege ich da falsch?

Tust du imho. Templates kennen keine Laufzeit. Alle Parameter sind Compilezeitkonstanten.

und was ist mit variablen?

Das drifftet alles langsam in "Rund um die Programmierung" ab ...

pale dog

äääh, Nr N und rüdiger:

Code bloat can also be caused by inadequacies in the language in which the code is written, or inadequacies in the compiler used to compile the language. An example of this is the template system employed in C++.

von --> http://en.wikipedia.org/wiki/Code_bloat
stimmt das?

Mr. N

pale dog schrieb:

äääh, Nr N und rüdiger:

Code bloat can also be caused by inadequacies in the language in which the code is written, or inadequacies in the compiler used to compile the language. An example of this is the template system employed in C++.

von --> http://en.wikipedia.org/wiki/Code_bloat
stimmt das?

Lies den nächsten Satz. Oder noch besser, lad die Seite erneut. Hab das verbessert.