g++ abs Probleme

[tjp]

Man kommt doch gar nicht mehr als Mac Entwickler drumherum Objektive C zu nutzen.

Das kommt auf den Kontext an. Wenn es sich um die klassische Applikation mit GUI handelt - sicherlich. Für Web Applikationen ist Objective-C seit einigen Jahren Geschichte, und für Server sollte man es tunlichst ebenfalls vermeiden, da Objective-C auf anderen Plattformen ein Exot ist und Cocoa gar nicht verfügbar ist. GNUStep ist nur eine Teilmenge und man handelt sich damit viel Arbeit ein. Unter Linux mag das vielleicht noch gegen (hängt von der Distribution ab) unter Solaris o.ä. bedeutet es einfach überflüssigen Ärger, den man einfach vermeiden kann.

 

[Jamsven]

Das kommt auf den Kontext an. Wenn es sich um die klassische Applikation mit GUI handelt - sicherlich. Für Web Applikationen ist Objective-C seit einigen Jahren Geschichte, und für Server sollte man es tunlichst ebenfalls vermeiden, da Objective-C auf anderen Plattformen ein Exot ist und Cocoa gar nicht verfügbar ist. GNUStep ist nur eine Teilmenge und man handelt sich damit viel Arbeit ein. Unter Linux mag das vielleicht noch gegen (hängt von der Distribution ab) unter Solaris o.ä. bedeutet es einfach überflüssigen Ärger, den man einfach vermeiden kann.

Ja klar, du kannst ja auch ne X-Server basierende Anwendung oder z. B Qt nutzen, nur leider ist das alles nicht nativ und sie können nicht die vollen Features von OS X ausnutzen.

Objective C kann ich leider aus Mangel an Erfahrung nicht bewerben, aber ich find die SmallTalk ähnliche Syntax strange.

 

[Amin Negm-Awad]

Ja klar, du kannst ja auch ne X-Server basierende Anwendung oder z. B Qt nutzen, nur leider ist das alles nicht nativ und sie können nicht die vollen Features von OS X ausnutzen.

Objective C kann ich leider aus Mangel an Erfahrung nicht bewerben, aber ich find die SmallTalk ähnliche Syntax strange.

Die Syntax besteht im Wesentlichen aus drei "Gewöhnungen".
1. @Schlüsselwort
Es gibt eine handvoll Schlüsselwörter, die zu Objective-C gehören und daher mit @ anfangen.

2. [receiver message]
Mag man gewöhnungsbedürftig finden, ist aber tatsächlich praktischer. Schau dir nur
object->method2()->method3()
und
[[object method2] method3]
an. Zweites finde ich persönlich klarer.

3. Methodendeklaration/-definition
calculator->addXtoY( 3, 4 )
und
[calculator addX:3 toY:4];
Ich fange jetzt nicht mit Methoden mit 4, 5 oder 6 Parametern an …

Der Objective-Aufsatz ist unabhängig von C. Er lässt sich auch mit anderen Programmiersprachen wie Pascal (Objective Pascal) und jüngst wohl auch Java (Objective-J) kombinieren.

 

[Jamsven]

Klar sieht das besser aus, nur ich bin die Methoden Deklaration aus C++ und Java gewöhnt.
Selbst die mathematische Notation ähnelt mehr dieser.

Cool finde ich bei Objektive C, das man Deklaration und Implementation trennt.

Aber wie gesagt: "Think different!"

 

[freddy.duese]

Cool finde ich bei Objektive C, das man Deklaration und Implementation trennt.

Ich finde eher, dass das ein Fall für das "Department of Redundancy Department" ist.

Kennt jemand eine Möglichkeit in Xcode, aus Methodenname und Signatur einer Implementierung, eine Deklaration im Interface zu erzeugen? Bei "Text Macros" und "Refactor" hab ich nichts gefunden.

 

[zottel]

Ja, sowas fände ich auch klasse. Oder umgekehrt, dass wenigstens aus dem Interface alle Methoden als Stub in die Implementation kopiert werden, damit man nicht alles von Hand Cut&Pasten muss?

 

[Jamsven]

Ich finde eher, dass das ein Fall für das "Department of Redundancy Department" ist.

Kennt jemand eine Möglichkeit in Xcode, aus Methodenname und Signatur einer Implementierung, eine Deklaration im Interface zu erzeugen? Bei "Text Macros" und "Refactor" hab ich nichts gefunden.

Naja, Objektive C ist da halt konsequenter als Java, da man hier direkt Schnittstellen haben muss.
Wenn du in Java eine Schnittstelle erstellst, wird diese auch in einer extra Datei gespeichert.

 

[MacApple]

Oder umgekehrt, dass wenigstens aus dem Interface alle Methoden als Stub in die Implementation kopiert werden, damit man nicht alles von Hand Cut&Pasten muss?

Im Script-Menü von Xcode gibt es unter „Code” zwei Scripte dafür.

MacApple

 

[freddy.duese]

Im Script-Menü von Xcode gibt es unter „Code” zwei Scripte dafür.

Hmm. Guter Tipp. Das Script-Menü überseh ich immer
Leider scheinen die beiden Scripts nicht viel zu machen.
Ich vermute mal sie sollten Definitionen bzw. Deklarationen für Instanzvariablen im Interface erzeugen. Bei mir ist aber nichts in der Zwischenablage nachdem ich die Scripts ausführe.

 

[Amin Negm-Awad]

Zu oben:
Es ist eine ganz gute Sitte, den Programmierer zum Nachdenken zu zwingen, was er publik machen möchte. Aber eigentlich ist dieses Aufgeteile in zwei Dateien in der Tat etwas anchronistisch.

Hmm. Guter Tipp. Das Script-Menü überseh ich immer
Leider scheinen die beiden Scripts nicht viel zu machen.
Ich vermute mal sie sollten Definitionen bzw. Deklarationen für Instanzvariablen im Interface erzeugen. Bei mir ist aber nichts in der Zwischenablage nachdem ich die Scripts ausführe.

Du musst zunächst die Zeile mit der ivar im @interface-Block selektieren.

 

[freddy.duese]

Zu oben:
Du musst zunächst die Zeile mit der ivar im @interface-Block selektieren.

Oh. Ich hatte nur den Cursor in der Zeile. Bei "Refactor" reicht das ja.
Danke für den Tipp!

 

[daniel.macbook]

Also, ich habe mir die Sache nochmals genauer angesehen. ISO 14882:2003 besagt

Dann folgen die Definitionen für diverse Funktionen unter anderem abs() mit diversen Typen. Wichtig ist hierbei zu erwähnen, daß alle Definitionen in <cmath> und <cstdlib> im Namensbereich std erfolgen und nicht im globalen Namensraum. Das kann man unter der Einleitung zur Standard Library lesen

Folgendes Programm reproduziert das Problem unter 10.4 mit g++ 4.0.1

#include <math.h>

#include <ostream>
#include <iostream>

using namespace std;

int main () {
        double x (-5.5);
        double y (abs(x)); // hier sollte/wird ISO konform nur int abs(int) aufgerufen

        std::cout << "abs(" << x << ") = " << y << "\n";
}

Was zu folgender Fehlermeldung führt

abs.cc: In function 'int main()':
abs.cc:10: error: call of overloaded 'abs(double&)' is ambiguous
/usr/include/stdlib.h:145: note: candidates are: int abs(int)
/usr/include/c++/4.0.0/cstdlib:169: note:                 long long int __gnu_cxx::abs(long long int)
/usr/include/c++/4.0.0/cstdlib:130: note:                 long int std::abs(long int)

Kommentiert man das "using namespace std" aus compiliert der Code und liefert das zu erwartende Ergebnis "int abs(int)" wird benutzt.

Das mathematisch richtige Verhalten erhält man dagegen, wenn man folgendes Programm nimmt.

#include <cstdlib>
#include <cmath>
#include <ostream>
#include <iostream>

using namespace std;

int main () {
        double x (-5.5);
        double y (abs(x));
        int a  (-5);
        int b (abs(a));

        std::cout << "abs(" << a << ") = " << b << "\n";
        std::cout << "abs(" << x << ") = " << y << "\n";
}

Die vorher geposteten Links zu dem Solaris Compiler legen zwar nahe, daß auch in <math.h> und <stdlib.h> die Erweiterungen deklariert werden, aber wie man an der ISO Norm sieht, ist dies wohl nicht korrekt. Warum unter MacOS X das Programm mit einem "using namespace std" nicht mehr compiliert, obwohl ISO 9899 davon nichts besagt ist wunderlich. Ohne dieses Statement compiliert das Programm mit dem von C bekanntem Verhalten. Das mathematisch richtige Verhalten erhält man, wenn man das Programm mit den C++ Headern compiliert. Was auch aus anderen empfehlenswert ist.

Super, vielen Dank, dass du das Problem ausfindig gemacht hast ! Mir war das so gar nicht bewußt, dass ich mit C-Headern arbeite. ...