C++ Exceptions in 64-bit Objc

[karolherbst]

Hi,

ich las häufig, dass es möglich sei, in der 64-bit runtime von ObjC auch C++ Exceptions zu verarbeiten.

-(BOOL)connect{
    NSLog(@"Connect to Database... ");
    
    try {
        if (conn.connect([databaseName UTF8String], [serverURL UTF8String], [userName UTF8String], [userPassword UTF8String] ) ) {
            NSLog(@"connected");
            return YES;
        }else{
            NSLog([NSString stringWithFormat:@"connection failed %@", [NSString stringWithUTF8String:conn.error()] ]);
            return NO;
        }
    }catch (mysqlpp::ConnectionFailed e) {
        NSLog(@"something stupid happened");
        NSLog([NSString stringWithUTF8String:e.what() ]);
        return NO;
    }
}

Mit dem C++ try catch Block funktioniert auch alles wunderbar. Ich würde aber lieber gerne den ObjC @try @catch @finally verwenden, ist das irgendwie möglich, oder geht das nur wirklich so?

BTW: mysqlpp::ConnectionFailed erbt fast direkt von std::Exception.

Oder empfehlt ihr mir jedoch einen anderen Weg auf eine MySQL DB zuzugreifen? Ich finde die libmysqlpp sehr praktisch, vor allem weil die mysqlpp::String klasse sich in jeden Typ durch casts umwandeln läst. Z.B. geht

mysqlpp::String str = "55";
int i = str;

oder noch besser

const char* str = "55";
int i = (mysqlpp::String)str;

wunderbar und ohne Probleme.

Also wenn ihr eine praktische mysql lib für ObjC kennt, die nur auf Foundation basiert (das ist unbedingt notwendig, da das Projekt später auf Linux mittels GNUStep portiert werden soll, im Ursprung liegt das jetzt in C++ vor, aber ich habe von C++ entschieden die Schnauze voll), wäre mir das natürlich viel lieber.

Danke im Voraus

karolherbst

 

[JustSid]

Richtig, die 64 Bit Objetive-C runtime kann sowohl C++ als auch ObjC Exceptions verarbeiten. Siehe dazu auch die release notes der 64 Bit Runtime: https://developer.apple.com/library/mac/#releasenotes/Cocoa/RN-ObjectiveC/ (letzter Punkt, 64-bit Zero-Cost C++-Compatible Exceptions).

Ein Beispiel wie das ganze aussehen könnte:

void foo()
{
	@try 
	{
		throw 42;
	}
	@catch(...) 
	{
		// ...
	}
	@finally 
	{
		// ...
	}
}

Zu der zweiten Frage kann ich leider nichts sagen das ich mehr der SQLite und Core Data fan bin (wobei letzteres ja für dich wohl nicht möglich ist).

 

[karolherbst]

Jo leider ist CoreData proprietär. Naja SQLite wäre eine alternative, aber es sind nicht wenige Daten, die aus der DB geholt werden müssen und da bietet sich MySQL schon an, weil die Datenbank an sich ja schon fertig ist. Aber so schreibe ich halt ein ObjC++ Wrapper für die mysql++ lib, da ich diese ziemlich simpel und kompakt finde. Man bekommt auch schon fertige STL Container, die man sogar assoziativ ansprechen kann und alle Daten sind mysqlpp::String s. Ist demnach sehr Einfach die Daten in ein NSDictionary + NSArray Konstrukt zu packen (Obwohl manchmal sogar NSDictionary + NSDictionary besser ist, wegen Zugriff per ID auf Zeilen). Leider ist das nur eine Überbrückung und natürlich mit Performanceverlust verbunden.

Das mit dem @catch(...) throw; gefällt mir nicht wirklich, da ich die Exception auch direkt auswerten möchte und dass geht ja nur, wenn man auf die Exception direkt zugreift und ich möchte diese auch nicht quer durch den gesamten Code werfen.

 

[JustSid]

Jap, das mit dem rethrow ist unschön. Was man machen könnte (achtung! Dirty voodoo hack!) ist per inline assembler selber die Daten beschaffen. Hier mal ein auf die schnelle Beispiel das mit hoher Wahrscheinlichkeit nur in diesem speziellen Fall funktioniert und ansonsten bricht:

void foo()
{
	@try 
	{
		throw 42;
	}
	@catch(...) 
	{
		uintptr_t _ptr = 0;		
		asm volatile ("nop" : "=a" (_ptr));
		
		int *ptr = (int *)((void *)_ptr); 
		NSLog(@"%i", *ptr);
	}
	@finally 
	{
		
	}
}

Gibt zumindest bei mir in der Konsole folgendes aus:

2010-09-18 23:53:22.172 Test[2585:a0f] 42

Aber wie gesagt, davon ist echt abzuraten!



Wenn dir NSArray und NSDictionary zu langsam sind, probier doch mal die Core Foundation Objekte aus (wenn GNUStep die anbietet). Die sind in der Regel schneller als die ObjC pendants und lassen sich ja hin und her casten wie man möchte. Ansonsten halt so etwas wie NSSet das deutlich schneller als NSArray's ist

 

[karolherbst]

Naja es ging mir eher um die "Umwandlung" von STL Container in NSArray, NSDictionary. Wenn man das mit 10.000 Zeilen macht, ist das etwas happig. Naja, ich glaube CoreFoundation liegt noch mal unter Foundation, ich weiß aber nicht ob di CF Typen da exisiteren, habe ich noch nicht richtig nachgeforscht, immerhin gibt es Foundation und AppKit und das reicht eigentlich schon AppKit ist nur auf Windows etwas unstable. Immerhin gibt es CF-Lite, welches die OpenSource Teile der CoreFoundation beinhaltet. Aber danke für den Tipp mit dem NSSet, die scheinen echt etwas flotter zu sein als die NSArrays, da keine Sortierung vorgenommen wird.

Wenn man die Exceptions mit dem Assembler beschafft, kann man auch gleich direkte Objekte beschaffen? Also auch auf deren Methoden zugreifen? Sonst wäre das ja sehr unlustig und ich müsste da mit Konstanten ran, was auch irgendwie doof ist.

 

[JustSid]

So wie ich das sehe ist Core Foundation komplett offen ( http://www.opensource.apple.com/source/CF/CF-550/ ), hab jetzt aber nicht all zu genau geguckt.

Auf die Methoden der geworfenen Objekte kann man theoretisch zugreifen, allerdings eher nicht ohne den entsprechenden Assembler Code zu kennen und die Funktionsaufrufe dann selber nachzubauen.
Allerdings ist Assemblierter C++ Code unglaublich hässlich und lang, das wird schwer da was zu finden. (-O0 ist dein Freund. Aber lass die debug symbole raus die verwirren nur).

Bei Objective-C sieht das anders aus, da kannst du direkt einen Aufruf zu objc_msg_send machen. Der erste Parameter ist das Objekt das die Nachricht erhalten soll (self) und als zweites musst du dir aus dem selector und dem Objekt den passenden IMP basteln (_cmd).
Allerdings ist das wohl eher witzlos das ObjC Objekte ja eh schon einfach abzufangen sind.

 

[JustSid]

Ich mach mal einen bösen Doppelpost da ich nicht weiß ob du auf der Cocoa Mailingliste mitliest oder nicht.
Heute wurde auf besagter Liste ein SQLite Wrapper für Cocoa announced ( http://sourceforge.net/projects/nanostore/ ), falls du also Probleme mit deinem C++ MySQL Wrapper hast, hilft dir das vielleicht (du hattest ja geschrieben das SQLite zur Not auch noch eine akzeptable Lösung ist).

Hier mal der Original Text:

Von Tito Ciuro <[email protected]>
nach Cocoa Dev List <[email protected]>
Datum 23. September 2010 04:51
Betreff [ANN] Release: NanoStore 1.0 for Mac and iOS
Gesendet von lists.apple.com



NanoStore 1.0
© Webbo, L.L.C., 2010. All rights reserved.
September 21, 2010

Today, Webbo is pleased to announce the release of NanoStore:

http://sourceforge.net/projects/nanostore/

NanoStore is a Cocoa wrapper for SQLite, a C library that implements an embeddable SQL database engine.

With NanoStore, you store data using a dictionary of any depth. The developer can decide what to store on the fly, unlike other systems that require the developer to design a schema. With NanoStore just build your dictionary and store it. That's all there is to it! Every data element in the dictionary is indexed (except BLOBs) so there's no need to keep a list of indexed separately. You can disable indexing, import your data in batch mode, save it and then reindex at once, which is quite efficient. For even better performance, all I/O can be performed in memory and save the new database to disk at once, which is even faster. And if you feel adventurous, you can even do that in Fast mode and save extra SQLite processing.

All these variations come with pros and cons, sure... but you have a choice. You can decide what's best *for you* and map a strategy to *your* model as there accessors available for most SQLite settings and pragmas that will allow you to tune it to your liking.

The list of classes include:

NSFNanoStore
NSFNanoExpression
NSFNanoSearch
NSFNanoResult

You also have full access to the sqlite3* handle, in case you need it (hey... you're a developer right?)

In addition, the NanoStore project includes:

- Unit tests
- An iOS plain-vanilla app to demonstrate how easy it is to embed NanoStore in your project

Enjoy!

-- Tito

*********************
Tito Ciuro
R&D Group, Webbo, L.L.C.

_______________________________________________

Cocoa-dev mailing list ([email protected])

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com