if Abfrage

[MQue]

ich habe folgende if- Abfrage:

if ((b-1) == 2 || (b-1) == 3 || (b-1) == 9 || (b-1) == 10 || (b-1) == 16)

kann ich die obere Zeile auch wie in C mit einem #define- Ähnlichen Konstrukt in Java schreiben,

lg

 

[ARadauer]

was genau macht #define?

willst du es wiederverwenden, bzw von wo anders aufrufen?

du könntest eine static Methode in einer Utility Klasse anlegen...
zb

public class Tools { 
	public static boolean ifDings(int b){
		if ((b-1) == 2 || (b-1) == 3 || (b-1) == 9 || (b-1) == 10 || (b-1) == 16)
			return true;
		return false;
	}
}

 

[ARadauer]

ach ich bin schlecht (aber ist ja noch früh):

return ((b-1) == 2 || (b-1) == 3 || (b-1) == 9 || (b-1) == 10 || (b-1) == 16);

ist natürlich schöner

 

[quippy]

was genau macht #define?

"Defines" sind etwas sehr praktisches - sogn. Präprozessorbefehle, die auch bedingt ausgeführt werden können.
Im Prinzip deklarieren sie Makros, also z.B. sowas:

#define EINE_KONSTANTE 1

#define MAKRO(a,b) (a>b)?a:b

#ifdef EINE_KONSTANTE
#define EINE_ZWEITE_KONSTANTE 5
#endif

und so weiter.

Vor allem aber (und das ist die Stärke von den Dingern) kann man damit eine bedingte Compilierung hinbekommen:

#define DEBUG 1

[...]

#ifdef DEBUG
   Log.debug("Dies ist ein Text, den keiner Lesen soll!");
#endif

Wer "#define DEBUG 1" nun auskommentiert, verhindert den Compile aller DEBUG-Blöcke. Das ist echt was feines und daher ist es auch schade, daß es sowas in Java nicht gibt.

Ein konkretes Anwendungsbeispiel wäre z.B. (Weil C immer eine Konstante mit seiner Version anlegt, könnte Java vielleicht auch machen)

#ifdef JAVA14
   String bigDecimalValue = aBigDecimal.toString();
#else
#ifdef JAVA5
   String bigDecimalValue = aBigDecimal.toPlainString();
#endif

 

[SlaterB]

@ARadauer
Schönheitstomaten auf den Augen?
nur

 public static boolean ifDings(int b)
    {
        int c = b - 1;
        return c == 2 || c == 3 || c == 9 || c == 10 || c == 16;
    }

ist schön


oder getrickst

 public static boolean ifDings(int b)
    {
        return b == 3 || b == 4 || b == 10 || b == 11 || b == 17;
    }

 

[maki]

Neuer BeitragVerfasst am: 14. 03. 2008, 9:16 Titel: Zitieren
Druckversion downloaden (dieser Post)
ARadauer hat folgendes geschrieben::
was genau macht #define?


"Defines" sind etwas sehr praktisches - sogn. Präprozessorbefehle, die auch bedingt ausgeführt werden können.
Im Prinzip deklarieren sie Makros, also z.B. sowas:
Code:

1
2
3
4
5
6
7
8
9


#define EINE_KONSTANTE 1

#define MAKRO(a,b) (a>b)?a:b

#ifdef EINE_KONSTANTE
#define EINE_ZWEITE_KONSTANTE 5
#endif

und so weiter.

Vor allem aber (und das ist die Stärke von den Dingern) kann man damit eine bedingte Compilierung hinbekommen:
Code:

1
2
3
4
5
6
7
8
9


#define DEBUG 1

[...]

#ifdef DEBUG
Log.debug("Dies ist ein Text, den keiner Lesen soll!");
#endif


Wer "#define DEBUG 1" nun auskommentiert, verhindert den Compile aller DEBUG-Blöcke. Das ist echt was feines und daher ist es auch schade, daß es sowas in Java nicht gibt.

Sorry, aber Makros sind sch....e, kannst du ganz einfach durch search&replace nachbilden lol

Dein Beispiel zeigt das sehr schön, was passieren kann: Es werden verschiedene Quellcodes und dadurch verschiedene Versionen Produziert...

Wer das "Glück" hatte mit M$ VC zu arbeiten, weiss was ich meine
Oder hattest du schon mal das Erlebniss, dass der Produktiv Code abschmiert, aber sobald du debuggen willst, geht alles?
Schliesslich werden nicht nur dein Code anders übersetzt(Teile ausgelassen, Teile miteinbezogen), sondern auch noch andere Libs eingebunden (DEBUG Versionen), da kann es dann leicht sein das der Fehler in der DEBUG Konstellation nie auftritt..

 

[quippy]

Sorry, aber Makros sind sch....e, kannst du ganz einfach durch search&replace nachbilden lol

Dein Beispiel zeigt das sehr schön, was passieren kann: Es werden verschiedene Quellcodes und dadurch verschiedene Versionen Produziert...

Wer das "Glück" hatte mit M$ VC zu arbeiten, weiss was ich meine
Oder hattest du schon mal das Erlebniss, dass der Produktiv Code abschmiert, aber sobald du debuggen willst, geht alles?
Schliesslich werden nicht nur dein Code anders übersetzt(Teile ausgelassen, Teile miteinbezogen), sondern auch noch andere Libs eingebunden (DEBUG Versionen), da kann es dann leicht sein das der Fehler in der DEBUG Konstellation nie auftritt..

Aus Deinem Post kann ich nur schließen, daß Du es nicht verstanden hast. Die erste disqualifizierende Aussage ist das mit dem Search&Replace. Die Makros für Funktionen kann man auch als static irgendwo ablegen - kein Thema, aber der Rest ist nicht mit S&R abzudecken.

Ich kann nichts dafür, daß Entwickler nicht fähig sind - wer für den Mist, den er da programmiert, keine Verantwortung übernimmt, hat leider Pech gehabt. Bedingte Compiles sind eine mächtige Waffe - und spätestens seit Spiderman wissen wir: "Aus großer Macht folgt große Verantwortung"

Und nein, ich habe solche Probleme nie gehabt und sehr viel mit VC gearbeitet.

 

[maki]

Aus Deinem Post kann ich nur schließen, daß Du es nicht verstanden hast. Die erste disqualifizierende Aussage ist das mit dem Search&Replace. Die Makros für Funktionen kann man auch als static irgendwo ablegen - kein Thema, aber der Rest ist nicht mit S&R abzudecken.

Wieso "disqualifizierende Aussage"?
Der Präprozessor macht nix anderes mit Macros, ersetzen.

Ich kann nichts dafür, daß Entwickler nicht fähig sind - wer für den Mist, den er da programmiert, keine Verantwortung übernimmt, hat leider Pech gehabt.

Die Bibliothek von der ich spreche und mit welcher ich Probleme hatte, hiess: MFC *g*

Und nein, ich habe solche Probleme nie gehabt und sehr viel mit VC gearbeitet.

Kann ich gar nicht nachvollziehen...

Naja, jedenfalls ist log4j (gibt auch für C++) bedingter Kompilierung bei weitem überlegen.
Ein Code, ein Satz Bibliotheken, immer gleich, man kann logging nach belieben ein- und ausschalten.
Anstatt für Debug und Prod unterschiedliche Quellen,m Bibliotheken und damit Programme zu haben, bei denen Fehler unter Umständen nur in einer Version, nämlich der Prod Version auftauchen.

Macros waren schon immer schnell, aber eben kein "echter" code, bei dem zB die IDE gleich Fehler anzeigen konnte.
Sie sind weder typsicher, noch haben sie sonstige Vorteile echten Codes.

Bin heilfroh das man in Java keine hat

 

[SlaterB]

dein Argument 'dann leicht sein das der Fehler in der DEBUG Konstellation nie auftritt'
kann ich aber auch nicht nachvollziehen,

was kann man den im Macro-Debug-Modus so groß anders machen
als entsprechend in ein if (logger.isDebugEnabled() { }-Block zu schreiben,
warum ist log4j da besser?

 

[quippy]

1. log4j und bedingte Compiles haben nix miteinander zu tun. Das Problem bei Logausgaben ist nicht, daß sie hinterher im Log stehen - oder nicht, sondern daß für die Erstellung der Zeichenkette oftmals sehr viel Zeit drauf geht - obwohl man hinterher das Ergebnis gar nicht sehen will.
Alternativ kann man natürlich

if (Log.isDebug(this.getClass().getName()) Log.debug(this.getClass().getName(), "Humpf" + o.toString() + "blabla" + o2.toString());

wieder etwas Zeit sparen - aber mit der bedingten kompilierung wäre es gar nicht erst im Coding mit drin.

2. Das folgende Problem kannst Du gerne mal mit Suchen und ersetzen lösen:

#ifdef JAVA14
   String bigDecimalValue = aBigDecimal.toString();
#else
#ifdef JAVA5
   String bigDecimalValue = aBigDecimal.toPlainString();
#endif

Alternative: Reflection - wirklich sehr performant.

 

[maki]

dein Argument 'dann leicht sein das der Fehler in der DEBUG Konstellation nie auftritt'
kann ich aber auch nicht nachvollziehen,

was kann man den im Macro-Debug-Modus so groß anders machen
als entsprechend in ein if (logger.isDebugEnabled() { }-Block zu schreiben,
warum ist log4j da besser?

Ganz einfach SlaterB:
Anders als zB bei log4j, wird bei Macros anderer Quellcode verwendet, eben der den der Präprozessor für das Macro eingetauscht hat, oder eben auch nicht.
D.h. es gibt im oberen Beispiel zwei Quellcodes, je nachdem.. dazu kommt das VC im Debug Modus andere Bibliotheken verwendet hatte als im nicht-Debug.
Da stand ich nun.
kein Debug-> NPE
Debug -> keine NPE...

log4j führt bestimmten Code eben nur nicht aus, falls der Loglevel nicht gesetzt ist, musst aber weder dein Programm neu (und mit anderen Quellen) kompilieren, noch andere Bibliotheken verwenden.
Ist immer ein und dasselbe

Kennt jemand noch den grund warum bestimmte Macros (glaube es war MAX und weitere) nicht verwendet werden sollten? Müsste zuhause in meinen alten Büchern nochmals nachsehen.

Macros sollten übrigens in C++ nicht mehr oder nur in ganz geringen Dosen benutzt werden, leider hatte das M$ nie kapiert, und zum Teil ganze Bibliotheken daruf aufgebaut.
Kennt jamand noch ATL? Angeblich "Active Template Library", waren aber größtenteils nur Macros anstatt echter Templates und deren Vorteile...

 

[maki]

1. log4j und bedingte Compiles haben nix miteinander zu tun. Das Problem bei Logausgaben ist nicht, daß sie hinterher im Log stehen - oder nicht, sondern daß für die Erstellung der Zeichenkette oftmals sehr viel Zeit drauf geht - obwohl man hinterher das Ergebnis gar nicht sehen will.
Alternativ kann man natürlich

if (Log.isDebug(this.getClass().getName()) Log.debug(this.getClass().getName(), "Humpf" + o.toString() + "blabla" + o2.toString());

wieder etwas Zeit sparen - aber mit der bedingten kompilierung wäre es gar nicht erst im Coding mit drin.

Schlechtes Beispiel, schlecht (formatierter) Code wird nicht besser durch Macros...

if (log.isDebugEnabled()) {
   log.debug(wasAuchImmer);
}

wenn dich das stört kannst du aber immer noch auf AOP ausweichen.

Das Argument mit der Performance nehme ich nicht mal ernst lol

2. Das folgende Problem kannst Du gerne mal mit Suchen und ersetzen lösen:

#ifdef JAVA14
   String bigDecimalValue = aBigDecimal.toString();
#else
#ifdef JAVA5
   String bigDecimalValue = aBigDecimal.toPlainString();
#endif

Alternative: Reflection - wirklich sehr performant.

Das ist doich ganz einfach: Entscheide dich für eine Java Version

 

[SlaterB]

du wiederholst nur die Tatsachen (andere Code-Version, Bibliotheken)
aber erklärst immer noch nicht, was sich daraus für Probleme ergeben können

in Java wie in anderen Sprachen kompiliert man doch eh zigmal am Tag,
überall muss man darüber nachdenken, die alten Kompilate zu überschreiben oder separate unterschiedliche Versionen anzulegen


--------
Bibliotheken ist mir noch ein gänzlich unverständlicher Punkt,
wofür braucht eine Log-Ausgabe andere Bibliotheken?

wenn man mit Macros und unterschiedlichen Bibliotheken was anderes als Logging macht,
wie kann man das dann in log4j oder auf sonstige Weise ohne unterschiedliche Biblotheken machen?


> dazu kommt das VC im Debug Modus andere Bibliotheken verwendet hatte als im nicht-Debug

nun das ist eine Info,
einen VC-Debug-Modus, was immer das auch ist, sollte man demnach unter bestimmten Voraussetzungen nicht vertrauen,
aber hat dessen Nicht-Funktionieren denn etwas mit der Qualität des allgemeinen Macro-Konzepts zu tun?

 

[maki]

du wiederholst nur die Tatsachen (andere Code-Version, Bibliotheken)
aber erklärst immer noch nicht, was sich daraus für Probleme ergeben können

Dachte es wäre klar, offensichtlich noch nicht.

Wenn ich mehrere Code Versionen habe, eine in denen das Macro aktiv war, und einmal ohne, kann ich doch in den 2 Versionen verschiedene Fehler haben, oder?
Ist das gut bzw. sinnvoll?
Doof wenn es sich um ein und dasselbe Programm handeln sollte...

n Java wie in anderen Sprachen kompiliert man doch eh zigmal am Tag,
überall muss man darüber nachdenken, die alten Kompilate zu überschreiben oder separate unterschiedliche Versionen anzulegen

Darum geht es doch gar nicht, es geht um folgendes:
Meine Quellen sollen zu einem Kompilat führen, immer.
Das habe ich mit Macros nicht.
Beispiel:
ohne Macros -> quell code 1 -> Produkt 1
mit Macros -> quell code 2-> Produkt 2
Wird es jetzt klarer?

Bibliotheken ist mir noch ein gänzlich unverständlicher Punkt,
wofür braucht eine Log-Ausgabe andere Bibliotheken?

Das kannst du ja M$ fragen
Anscheinend werden bei VC++ im Debugmodus andere Libs verwendet, um Debug Infos zu bekommen.
Hatte das wohl mit Macros realisiert lol

wenn man mit Macros und unterschiedlichen Bibliotheken was anderes als Logging macht,
wie kann man das dann in log4j oder auf sonstige Weise ohne unterschiedliche Biblotheken machen?

Verstehe deine Frage nicht.

nun das ist eine Info, einen VC-Debug-Modus, was immer das auch ist, sollte man demnach unter bestimmten Voraussetzungen nicht vertrauen,
aber hat des Nicht-Funktionieren denn etwas mit der Qualität des allgemeinen Macro-Konzept zu tun?

Sicherlich nicht, aber genau das ist mir passiert
Übrigens, der Begriff "Qualität des allgemeinen Macro-Konzept" ist ein Oxymoron
Das ist ein Konzept das schon vor längerer Zeit als nicht so gut erkannt wurde, fehlende Typsicherheit ist nur eines der Probleme.

In Java haben wir Annos, ein bisschen besser als Macros

 

[SlaterB]

solange du nichts konkretes antwortest, frage ich einfach immer weiter :
was ist der Nachteil von mehreren Code-Versionen?

> kann ich doch in den 2 Versionen verschiedene Fehler haben, oder?

genausogut kannst in nur einem Java-Code verschiedene Fehler haben,
und zwar zum einen die, die innerhalb eines if (debug) {}-Blocks stehen + die außerhalb,
was ist der Unterschied/ Vorteil/ Nachteil?

> Verstehe deine Frage nicht.

ich frage mich, was du die ganze Zeit mit 'Bibliotheken' meinst,
außerhalb des irrelevanten VC-Debug-Modus

 

[maki]

Scheinst heute etwas Beratungsresistent zu sein SlaterB

> kann ich doch in den 2 Versionen verschiedene Fehler haben, oder?

genausogut kannst in nur einem Java-Code verschiedene Fehler haben,
und zwar zum einen die, die innerhalb ein if (debug) {}-Blocks stehen + die außerhalb,
was ist der Unterschied/ Vorteil/ Nachteil?

Trotzdem habe ich nur einen Quellcode und ein Kompilat, anders bei Macros.
Es wird nicht einfach was vom Präprozessor eingefügt/ausgelassen.

Der Unterschied: Der Code und das kompilat sind immer gleich.
Eine Codebasis, einen Satz von fehlern.
Mehrere Codebase, meherer Sätze von fehlern...

Ich kann Unit tests für alles machen, nur eben nicht für nicht-vorhandenen Code, weil zB kein Macro ersetzt wurde.
Oder sollte man dann die Unittests für die Macros auch in Macros packen? *g*
Wird sehr unübersichtlich...

Line und Branchcoverage zeigen mir dann schon, ob ich ein Log statement getestet habe.
Dieses if mitzutesten ist kein Problem, wenn es denn sein müsste ...


Jedenfalls klingt für mich "Schade das es keine Macros in Java gibt" nicht anders als "Schade dass es keine operator Überladungen in Java gibt" und "Schade dass es keine Mehrfachvererbung in Java gibt"...
IMHO kommt das von Leuten, die sich noch nicht im Detail damit beschäftigt haben und den Pferdefuss den diese "features" haben noch nicht kennen.

 

[SlaterB]

> Der Unterschied: Der Code und das kompilat sind immer gleich.

oh, hattest du ja erst dreimal erwähnt, aber noch nie die Folge/ Relevanz

> Ich kann Unit tests für alles machen, nur eben nicht für nicht-vorhandenen Code, weil zB kein Macro ersetzt wurde.

du kannst keinen Code testen, der wegen eines ifs nicht ausgeführt wird,
aber dann:

> Dieses if mitzutesten ist kein Problem, wenn es denn sein müsste ...

hmm, ein erster Hauch eine Info,
aber wie kann man sich das vorstellen? meinst du damit, das Programm im Debug-Log-Modus zu testen?
kann man ein Macro-Programm nicht genauso einfach mit eingeschalteten Macros testen?

 

[maki]

> Der Unterschied: Der Code und das kompilat sind immer gleich.

oh, hattest du ja erst dreimal erwähnt, aber noch nie die Folge/ Relevanz

3 mal weil es nicht durchgedrungen war, drücke mich anscheinend nicht klar genug aus.
2 mal Quellcode -> mehr Aufwand, jede einzelne "Version" muss geprüft werden.
Einen Satz tests für die Prod version, einen für die Debug version.
Schliesslich will ich ja Code testen, der mal da ist, und mal nicht.
Sicherlich muss ich nicht alle tests neu schreiben, aber der Aufwand ist größer.
Nach jeder Änderung sowohl Debug als auch Prod version testen, es handelt sich ja um unterschiedliche Programme, nicht wahr?

> Ich kann Unit tests für alles machen, nur eben nicht für nicht-vorhandenen Code, weil zB kein Macro ersetzt wurde.

du kannst keinen Code testen, der wegen eines ifs nicht ausgeführt wird,
aber dann:

> Dieses if mitzutesten ist kein Problem, wenn es denn sein müsste ...
hmm, ein erster Hauch eine Info,

Dazu reicht es, eine Konfigeinstellung zu ändern.
Muss nix neu kompiliert werden, auch nicht mit anderem Quellcode!

aber wie kann man sich das vorstellen? meinst du damit, das Programm im Debug-Log-Modus zu testen?
kann man ein Macro-Programm nicht genauso einfach mit eingeschalteten Macros testen?

Eben nicht, da es sich mit verwendeten Macros um ein anderes Proramm handelt, mit anderen Quellen, welches erst kompiliert werden muss, und unter umständen andere Fehler hat als die Prod Version.
Selbst wenn das testen nicht viel aufwändiger erscheint, habe ich im Prinzip etwas anderes getestet als später in Produktion kommt, da fehlt die Sicherheit.

Der Unterschied zwischen der Konfiguration ändern (property Datei) und einem anderen Quellcode kompilieren leuchtet aber ein, oder?

 

[SlaterB]

> Der Unterschied zwischen der Konfiguration ändern (property Datei) und einem anderen Quellcode kompilieren leuchtet aber ein, oder?

der war von Anfang an klar, nur deine Kritik daran nicht,

bisher sehe ich nur ein Argument von dir, nämlich dem Aufwand beim Testen,
das ist natürlich respektabel, aber zum Verfluchen reicht das nun noch längst nicht

beide Versionen ständig zu testen, ob mit log4j oder Macros, macht eh keinen Sinn,
beides wird wenn nötig dann sowieso automatisch gemacht, keine manuelle Arbeit,
zu Performance/ Zeitaufwand hast du ja schon 'lol' geschrieben, da darfst du das jetzt fairerweise auch nicht anführen


na jedenfalls klingt 'Auwand beim Testen' bis jetzt noch besser als die anfänglichen Schreckensbilder
'sondern auch noch andere Libs eingebunden (DEBUG Versionen)'
+ direkt dahinter
'da kann es dann leicht sein das der Fehler in der DEBUG Konstellation nie auftritt..'

----


der Unterschied 'langsames Logging, per Konfiguration dynamisch änderbar'
vs 'schnelles Logging, da zur Compilierzeit entschieden'
ist fundamental und aus meiner Sicht die Wahl zweier akzeptabler Alternativen

genau wie es in Java statische Klassenzugriffe vs dynamische Objekt-Zugriffe gibt,
final-Variablen, Singletons, Caches usw.

 

[maki]

bisher sehe ich nur ein Argument von dir, nämlich dem Aufwand beim Testen,
das ist natürlich respektabel, aber zum Verfluchen reicht das nun noch längst nicht icon_wink.gif

Dann hast du etwas übersehen.

beide Versionen ständig zu testen, ob mit log4j oder Macros, macht eh keinen Sinn,
beides wird wenn nötig dann sowieso automatisch gemacht, keine manuelle Arbeit,
zu Performance/ Zeitaufwand hast du ja schon 'lol' geschrieben, da darfst du das jetzt fairerweise auch nicht anführen icon_wink.gif

Performance ist es nicht was ich sagte und meinte.
Was hat Performance mit Programmieraufwand zu tun den ich habe, wenn ich tests für zwei Produkte schreiben muss?
"Performance" war noch nie ein Argument ohne zahlen die etwas belegen können, eher aberglaube.

na jedenfalls klingt 'Auwand beim Testen' bis jetzt noch besser als die anfänglichen Schreckensbilder
'sondern auch noch andere Libs eingebunden (DEBUG Versionen)'
+ direkt dahinter
'da kann es dann leicht sein das der Fehler in der DEBUG Konstellation nie auftritt..'

"Aufwand beim testen" hatte ich nie geschrieben.
Es ist schlicht, das man 2 Produkte testen muss.
Das Fehler in einer Version vorkommen können (und meist auch tun) und in einer anderen nicht, ignorierst/verniedlichst du einfach?
Sorry, aber das ist das Argument.

der Unterschied 'langsames Logging, per Konfiguration dynamisch änderbar'
vs 'schnelles Logging, da zur Compilierzeit entschieden'
ist ein fundamentaler Unterschied und aus meiner Sicht die Wahl zweier akzeptable Alternativen

"langsames/schnelles Logging" ist eine reine Mutmassung, wie lange dauert eine if -Abfrage?

Abgesehen davon gibt es die Alternative der Macros gibt es ja in Java Gott sei Dank nicht

 

[SlaterB]

"Aufwand beim testen" hatte ich nie geschrieben.

du schriebst

2 mal Quellcode -> mehr Aufwand, jede einzelne "Version" muss geprüft werden.
[..]
Sicherlich muss ich nicht alle tests neu schreiben, aber der Aufwand ist größer.

nun, vielleicht hast du damit nicht die Arbeit 'dieselben Tests auf zwei Programmversionen laufen lassen' gemeint,
wie ich gedacht hatte, sondern

Was hat Performance mit Programmieraufwand zu tun den ich habe, wenn ich tests für zwei Produkte schreiben muss?
Es ist schlicht, das man 2 Produkte testen muss.
Das Fehler in einer Version vorkommen können (und meist auch tun) und in einer anderen nicht, ignorierst/verniedlichst du einfach?

unterschiedliche Tests für die unterschiedlichen Programmversionen?
dann gehen wir wieder einen Schritt zurück und ich frage dich,

genausogut kannst in nur einem Java-Code verschiedene Fehler haben,
und zwar zum einen die, die innerhalb ein if (debug) {}-Blocks stehen + die außerhalb,
was ist der Unterschied/ Vorteil/ Nachteil?

wenn man mit Macros derart unterschiedliche Programme hat, dass man dafür unterschiedliche Tests braucht,
warum gilt dann das gleiche nicht auch für eingeschaltetes Logging (mit if-Blöcke) vs ausgeschaltetes Logging (ohne if-Blöcke)?

---------

> Abgesehen davon gibt es die Alternative der Macros gibt es ja in Java Gott sei Dank nicht

hehe, mit einem Java-Meta-Programm und unschuldigen Text-Datei-Quelltexten kann man ne Menge machen :bae:
(mache ich aber nicht)

 

[quippy]

Jedenfalls klingt für mich "Schade das es keine Macros in Java gibt" nicht anders als "Schade dass es keine operator Überladungen in Java gibt" und "Schade dass es keine Mehrfachvererbung in Java gibt"...
IMHO kommt das von Leuten, die sich noch nicht im Detail damit beschäftigt haben und den Pferdefuss den diese "features" haben noch nicht kennen.

Ohje - alle sind dumm, nur Du nicht, weil Du erleuchtet wurdest. Leuten zu unterstellen, Sie hätten sich mit einem Thema nicht auseinandergesetzt, nur weil sie nicht Deiner (und damit offensichtlich der falschen) Meinung sind, ist fahrlässig!

Alle diese Dinge (sowohl Operatorüberladung wie auch Merfachvererbung und auch Präprozessorbefehle) sind nie ohne Grund entstanden.

Die Operatorüberladung ist durchaus was feines, wenn man damit umzugehen weiß. Aber sie hat selbstverständlich den eklatanten Nachteil, daß man bei einem Operator erstmal erwartet, daß er sich wie gewohnt verhällt - die Lesbarkeit des Codes wäre stark verbessert, wenn man das ewige Beispiel der C++ Vektor-Klasse (das Paradebeispiel der Operatorüberladung) statt mit Operatorüberladung mit entsprechenden selbsterklärenden Methoden der Vector Klasse gelöst hätte. (Also statt * eine Methode Vector.multiply(Vector))

Die Mehrfachvererbung z.B. ist vor allem bei technischen Lösungsmustern sinnvoll - aber aus reiner OO-Sicht völliger Unsinn. Immerhin bedeutet "Ableiten", daß ein Objekt konkretisiert wird, also eine Person wird zum Geschäftskunden oder Kunden. Die "Einvererbung" generisch arbeitender Methoden, wie z.B. eine allgemeine Druckmethode für alle möglichen Objekte, kann per Delegation genauso elegant gelöst werden.
Es gibt allerdings Situationen, wo man es sich wünscht, einfach per zusätzlicher Vererbung einer weiteren Klasse Funktionalität zu erben. Das damit "super()" nicht mehr eindeutig ist, ist nur eines der vielen Probleme.

Nun noch mal zu den Präprozessorbefehlen. Es fällt mir auf, daß Du immer nur von Makros sprichst. Makros sind aber nur *eine* Möglichkeit, die diese Dinger bieten - und ja, Makros können besser durch (typsichere) static methoden, irgendwo zentral implementiert, gelöst werden.

Aber der bedingte Compile ist durchaus sinnvoll. In MVC hat man in den includes durch die Abfrage auf "DEBUG" z.B. zusätzlichen Code zur Prüfung von Speicherbereichen oder "null"-Prüfungen in den Code geholt, was die Ausführungsgeschwindigkeit stark reduzierte, aber das Debugging vereinfachte.

Klar, wenn man sich z.B. den ModPlugTracker-Source ansieht, stellt man fest, daß man dort Versionen mit und ohne bestimmter Features erzeugen kann - oder das z.B. (um den Hauch der Plattform- und Compilerunabhängigkeit zu erhalten) jeh nach Plattform die Wortlänge des INT entsprechend dargestellt wird. Damit bekommst Du, je nach Compilereinstellung, unterschiedlichen Code zurück - aber das macht überhaupt nichts, denn diese unterschiedlichen Versionen sind ja auch gewünscht und müssen dann natürlich auch alle getrennt getestet werden.

Und für die Pascalecke gab es immer den Standard-Define #define TRUE 1 #define FALSE 0; was übrigens total falsch ist. Man hätte besser #define FALSE 0 und #define TRUE !FALSE schreiben sollen - was aber auch nicht geholfen hätte, denn true ist in C alles, was nicht 0 ist. Daher hätte man nur FALSE definieren können und für "true" immer mit "!=FALSE" prüfen müssen.

Worauf ich im Endeffekt hinaus will:
a) bestimmt haben sich auch die Befürworter der Präprozessorbefehle mit dem Thema auseinander gesetzt und kennen die Stärken und Schwächen - sie können das Konzept einfach für sich arbeiten lassen
b) es gibt kein Schwarz und Weiß

Ein schönes Wochenende!

 

[Marco13]

b) es gibt kein Schwarz und Weiß

Aber an ersteres kommt man inzwischen schon verdammt nahe dran - zu etwa 99.96% Experimental Observation of an extremely dark material
(Ich find' der Thread war noch nicht off-topic genug :roll: )

 

[maki]

wenn man mit Macros derart unterschiedliche Programme hat, dass man dafür unterschiedliche Tests braucht,
warum gilt dann das gleiche nicht auch für eingeschaltetes Logging (mit if-Blöcke) vs ausgeschaltetes Logging (ohne if-Blöcke)?

Bei dem einen habe ich zwei Programme (Debug & Prod), bei dem anderen nur ein einziges.

Was ist ein größeres Risiko?
1 oder 2 Programme?

Einen if zweig mit anderem Quellcode gleichzusetzen ist... naja, Äpfel mit Birnen usw.

Ich glaube wir drehen uns hier im Kreis SlaterB, du scheinst nicht wirklich auf meine Argumente einzugehen.


@quippy

Ohje - alle sind dumm, nur Du nicht, weil Du erleuchtet wurdest. Leuten zu unterstellen, Sie hätten sich mit einem Thema nicht auseinandergesetzt, nur weil sie nicht Deiner (und damit offensichtlich der falschen) Meinung sind, ist fahrlässig!

Ja, war aber die Retourkutsche für:

Aus Deinem Post kann ich nur schließen, daß Du es nicht verstanden hast. Die erste disqualifizierende Aussage ist das mit dem Search&Replace.

Ich gebe dir recht mit dem was du über Operatorüberladungen und Mehrfachvederbung sagtest, bist keiner von denen die es nicht verstanden haben, nehme zurück was ich gesagt habe.


Klar ist bedingte Kompilierung ein gutes Mittel, aber Macros haben eben ihre Tücken und ich vermisse sie nicht.

(Ich find' der Thread war noch nicht off-topic genug icon_rolleyes.gif )

Ehrlich gesagt hab ich keine Ahnung worum es in diesem Thread *eigentlich* ging..

Allen ein schönes Wochenende.

 

[SlaterB]

> du scheinst nicht wirklich auf meine Argumente einzugehen

dann könnte ich sagen, dass du nicht auf den Sinn von Macros eingehst,

das eine ist
if (debug) {
// TeilCode
}

das andere ist

#ifdef DEBUG
// TeilCode
#endif

und ja, das setze ich gleich (auf einen gewissen abstracten Anwendungslevel), auf dem Stand können wir ja verbleiben

 

[maki]

und ja, das setze ich gleich (auf einen gewissen abstracten Anwendungslevel), auf dem Stand können wir ja verbleiben

Der Unterschied ist der erzeugte (Quell)code.
Ersteres erzeugt ein if, letzteres nie, entweder TeilCode, oder nix.

Naja, wir müssen ja nicht alle dieselbe Meinung haben.

 

[tfa]

Ich find Macros super. Jedenfalls in C:

/* Make code run faster */
#define while if

/* Save memory */
#define struct union

:lol:

 

[maki]

:lol: :lol: