C++ Community

volkard

alex89ru schrieb:

Ich sehe garnichts ein...da es nichts einzusehen gibt!!!
Sei tollerant gegenüber C und C++!!!! Nicht nur C++.

nimm in C #define und in C++ const. es sind verschiedene sprachen. machst ja auch nicht

#define BEGIN {
#define END }

um mit pascal kompatiben zu sein oder

#define print cout<<

um wie imn basic

print "hallo, welt";

schreiben zu können.

alex89ru

Das liegt vielleicht daran , da ich NICHT tolerant gegenüber Basic , Qbasic , VisualBasic und sonstigem Scheiss bin.
Un im Grunde genommen ist es doch SCHEISSEGAL ob man #define oder oonst nimmt!
Im Endeffekt kommt eh das gleiche raus... gleicher code.!!!
zugegeben : So tolerant gegenüber anderen Sprachen bin ich auch net!!!!!!!!!!!! :p
Aber C und C++ sind miteinander verwandt.
So

GPC

Un im Grunde genommen ist es doch SCHEISSEGAL ob man #define oder oonst nimmt!Im Endeffekt kommt eh das gleiche raus... gleicher code.!!!

Falsch, da der Präprozessor dein #define rausfiltert (und jedem Debugger unbekannt ist), wird ein anderer Code erzeugt, als wenn du const verwendest.

alex89ru

Tja GPC: Hab gerade etwas ausprobiert(mit g++).
Einmal mit #define und einmal mit const und es ist der gleiche assembler code rausgekommen!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
(habs mit g++ -o someasmcode.s -S test.c "compiliert")

1:

const int B = 0xff;

int main (void)
{
    char buf[B];
}

... sit identisch mit

[/cpp]
#define B 0xff;

int main (void)
{
char buf[B];
}
[cpp]

Tja , GPC: identischer code. const hat nur den vorteil wegen der compiler meldungen.

GPC

Probier das mal das unten aus, und sag mir dann ob immer noch der gleiche asm-Code rauskommt. Vorher hat der Compiler bei deinem Beispiel wahrscheinlich B als unused erkannt und wegoptimiert.

#define SIZE 5

int main(int argc, char **argv) {
  int arr[SIZE];
  cout<<SIZE<<'\n';
  return 0;
};

const size_t SIZE = 5;

int main(int argc, char **argv) {
  int arr[SIZE];
  cout<<SIZE<<'\n';
  return 0;
};

alex89ru

Ich habe deinen code ausprobiert(asm-code davon angeschaut) und:
Nee , da gibt es ABSOLUT KEINE UNTERSCHIEDE!!!!
Ich bin noch extra Zeile für Zeile durchgegangen , doch der code war identisch!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

groovemaster

icepacker schrieb:

äh
wo ist denn hier überhaupt das problem #define <-> const
geht doch beides sowohl in c als auch in c+++

Nun c+++ kenn ich leider nicht (sollte ich mir darüber Sorgen machen ) und es ging bei der Aussage auch nicht um C. In C kannst du von mir aus #define oder const benutzen wie du willst, ist eigentlich relativ egal.
Versuche aber mal folgenden Code mit einem standardkonformen C++ Compiler deiner Wahl zu übersetzen:

namespace A
{
    const int C = 1;
    #define D 1
}
namespace B
{
    const int C = 2;
    #define D 2
}

Du wirst wahrscheinlich recht schnell merken, dass sich der Code nicht übersetzen lässt. Das liegt aber nicht am const, sondern am #define.

GPC

alex89ru schrieb:

Ich habe deinen code ausprobiert(asm-code davon angeschaut) und:
Nee , da gibt es ABSOLUT KEINE UNTERSCHIEDE!!!!
Ich bin noch extra Zeile für Zeile durchgegangen , doch der code war identisch!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

1. Ich weiß dass ich recht habe, denn der Präprozessor funktioniert wie ein Textersetzer (oder was denkst du, passiert wenn du #include <iostream> schreibst?).

2. Hier der Beweis mit g++ 3.3.6 (g++ -S .):

Erst die cpp Dateien

first.cpp:

#define SIZE 5

int main() {
  int arr[SIZE];
  int sum = SIZE*2;
  return 0;
};

second.cpp:

const int SIZE = 5;

int main() {
  int arr[SIZE];
  int sum = SIZE*2;
  return 0;
};

Jetzt der produzierte asm Code:

first.s:

.file	"first.cpp"
	.text
	.align 2
.globl main
	.type	main, @function
main:
.LFB3:
	pushl	%ebp
.LCFI0:
	movl	%esp, %ebp
.LCFI1:
	subl	$56, %esp
.LCFI2:
	andl	$-16, %esp
	movl	$0, %eax
	subl	%eax, %esp
	movl	$10, -44(%ebp)
	movl	$0, %eax
	leave
	ret
.LFE3:
	.size	main, .-main
	.section	.note.GNU-stack,"",@progbits
	.ident	"GCC: (GNU) 3.3.6"

second.s:

.file	"second.cpp"
	.text
	.align 2
.globl main
	.type	main, @function
main:
.LFB3:
	pushl	%ebp
.LCFI0:
	movl	%esp, %ebp
.LCFI1:
	subl	$56, %esp
.LCFI2:
	andl	$-16, %esp
	movl	$0, %eax
	subl	%eax, %esp
	movl	$10, -44(%ebp)
	movl	$0, %eax
	leave
	ret
.LFE3:
	.size	main, .-main
	.section	.rodata
	.align 4
	.type	SIZE, @object
	.size	SIZE, 4
SIZE:
	.long	5
	.section	.note.GNU-stack,"",@progbits
	.ident	"GCC: (GNU) 3.3.6"

Also ich sehe den Unterschied. Und du? Wenn du's mir immer noch nicht glaubst, dann lass es bleiben.

alex89ru

Stimmt , du hast Recht...hab's übersehen(die Asm Direktiven unten).
Als ich den code durchgegangen bin , hab ich mich auf die mnemonics konzentriert.
(Nicht auf die Assembler direktiven).
Aber jetzt mal im ernst:
Diese Direktiven sind doch nur Informationen für den Assembler.
Haben diese im Endeffekt igendwas mit der Ausführung zutun???????
Glaube eher nicht!
Denn (ich habe es noch ___NICHT___ ausprobiert) der assemblierte code dürfte identisch sein. Ich werde es auch nicht ausprobieren.(Ich gehe sicher nicht jedes einzelne byte für byte durch...etw mühselig...vielleicht gibt es progs die binäre dateien miteinander vegleichen , aber ich habe keine Lust drauf)
Diese helfen einem bei der Fehlersuche , aber wenn es keine bugs gibt...

Naja , ist ja auch egal...

groovemaster

alex89ru schrieb:

Tja GPC: Hab gerade etwas ausprobiert(mit g++).
Einmal mit #define und einmal mit const und es ist der gleiche assembler code rausgekommen!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Ein Ausrufezeichen hätte zwar auch gereicht, trotzdem ist das Ergebnis nicht verwunderlich.

GPC schrieb:

Hier der Beweis mit g++ 3.3.6 (g++ -S .):

Schön, ein Beweis ist das allerdings nicht. Erstens interessiert doch das Kompilat vom gcc und nicht g++, und zweitens solltest du auch Optimierungen in deine Betrachtung einbeziehen.

GPC

groovemaster schrieb:

GPC schrieb:

Hier der Beweis mit g++ 3.3.6 (g++ -S .):

Schön, ein Beweis ist das allerdings nicht. Erstens interessiert doch das Kompilat vom gcc und nicht g++, und zweitens solltest du auch Optimierungen in deine Betrachtung einbeziehen.

Ja, ich weiß dass es kein Beweis ist, aber ich wollte die leidige Diskussion beendet haben. Im Nachhinein betrachtet hätte ich es wohl besser nicht geschrieben.

However, der gcc hätte wohl ein ähnliches Ergebnis geliefert. Und ja, Optimierungen sind hier relevant, aber davon war bisher keine Rede, abgesehen davon habe ich in einem früheren Post darauf verwiesen.

Und nun lasst uns das Thema begraben.

C ist Mist!

groovemaster

Netter Versuch, aber wie GPC schon sagte, das Thema ist durch.

alex89ru

Ich hab auch keine Lust mehr.
9 == Unabhaengiger Experte , glaub ich
das thema ist echt durch

danke an alle

9 schrieb:

danke an alle

Wofür?

Stichwort Fütterung...