Preprozessor Makro, um assert() zu überschreiben

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • DanielBocksteger95 schrieb:

    gritsch schrieb:

    Quellcode

    1. #undef assert
    2. #define assert(x) NSLog("assert " #x)


    aber warum sollte man sowas machen?
    btw: es gibt noch die ganzen NSAssert...


    NSAssert lässt sich in purem C/C++-Code auch so gut verwenden...


    ich habs ja nur angemerkt. wusste ja nicht was genau du willst...
    außerdem hattest du UIAlertView in deiner anfrage darin. das lässt sich sicherlich in "purem" C/C++ auch verwenden oder?
    also lieber bedanken als den oberschlauen spielen sonst gibts sehr schnell keine antworten mehr (der ruft eilt einem voraus).
  • gritsch schrieb:

    DanielBocksteger95 schrieb:

    gritsch schrieb:

    Quellcode

    1. #undef assert
    2. #define assert(x) NSLog("assert " #x)


    aber warum sollte man sowas machen?
    btw: es gibt noch die ganzen NSAssert...


    NSAssert lässt sich in purem C/C++-Code auch so gut verwenden...


    ich habs ja nur angemerkt. wusste ja nicht was genau du willst...
    außerdem hattest du UIAlertView in deiner anfrage darin. das lässt sich sicherlich in "purem" C/C++ auch verwenden oder?
    also lieber bedanken als den oberschlauen spielen sonst gibts sehr schnell keine antworten mehr (der ruft eilt einem voraus).


    Okay, sorry. So war das eigentlich auch nicht gemeint. Ich bin ja schon roh über die Antwort. Ich hatte nur gehofft, über das Makro dann anstelle des NSLog in deinem Beispiel einen UIAlertView aufrufen zu können.

    Ich könnte aber assert(x) mit einem Aufruf von NSAssert versehen, oder?

    Danke,

    Daniel
    Man kann alles schaffen. Man muss es nur wollen ;)
    www.regetskcob.github.io
  • gritsch schrieb:

    DanielBocksteger95 schrieb:

    gritsch schrieb:

    Quellcode

    1. #undef assert
    2. #define assert(x) NSLog("assert " #x)


    aber warum sollte man sowas machen?
    btw: es gibt noch die ganzen NSAssert...


    NSAssert lässt sich in purem C/C++-Code auch so gut verwenden...


    ich habs ja nur angemerkt. wusste ja nicht was genau du willst...


    wie gesagt macht es normalerweise keinen sinn einen assert zu überschreiben. warum auch?
  • gritsch schrieb:

    gritsch schrieb:

    DanielBocksteger95 schrieb:

    gritsch schrieb:

    Quellcode

    1. #undef assert
    2. #define assert(x) NSLog("assert " #x)


    aber warum sollte man sowas machen?
    btw: es gibt noch die ganzen NSAssert...


    NSAssert lässt sich in purem C/C++-Code auch so gut verwenden...


    ich habs ja nur angemerkt. wusste ja nicht was genau du willst...


    wie gesagt macht es normalerweise keinen sinn einen assert zu überschreiben. warum auch?


    Mein Ausbilder hätte gerne neben dem Assert noch eine Meldung auf dem Bildschirm...
    Man kann alles schaffen. Man muss es nur wollen ;)
    www.regetskcob.github.io
  • macmoonshine schrieb:

    Du kannst es auch so machen, dass die App erst terminiert, wenn der Nutzer den Abort-Button des Alerts geklickt hat. So gesehen ist die Anforderung des Ausbilders nicht sinnlos.

    Allerdings ist das sehr Windows-like, +igitt+ ;)


    Das wäre ziemlich naheliegend, hauptprodukt ist für Windows :P

    Aber zum Thema, wie würde das gehen? Ich habe grad das Problem, dass die Bibliothek die verwendet wird trotzdem das normale assert benutzt...
    Man kann alles schaffen. Man muss es nur wollen ;)
    www.regetskcob.github.io
  • DanielBocksteger95 schrieb:

    macmoonshine schrieb:

    Du kannst es auch so machen, dass die App erst terminiert, wenn der Nutzer den Abort-Button des Alerts geklickt hat. So gesehen ist die Anforderung des Ausbilders nicht sinnlos.

    Allerdings ist das sehr Windows-like, +igitt+ ;)


    Das wäre ziemlich naheliegend, hauptprodukt ist für Windows :P

    Aber zum Thema, wie würde das gehen? Ich habe grad das Problem, dass die Bibliothek die verwendet wird trotzdem das normale assert benutzt...


    1. nein das geht so nicht unter iOS!
    2. damit das assert auch verwendet wird kannst du natürlich keine übersetzte biblithek verwenden sondern musst vor dem compilieren der entsprechenden stellen eben das undef und neue #define einbauen (auf jedenfall nach dem header in dem das originale includiert wird).

    aber tu dir, der meinschheit und deinem "prof" einen gefallen und vergiss das!
  • gritsch schrieb:

    nein das geht eben nicht. weil UIAlertView im gegensatz zu NSAlert NICHT blockiert.

    Doch, wo wir gerade so schön beim Rumfrickeln sind, das geht wohl. Du öffnest das Alert und schickst die App für immer in die Runloop. Dann fährt sie nach der Assert-Stelle nicht mit dem fehlerhaften Code fort.

    Also, wenn das jetzt keine wunderschöne Windows-Lösung ist. ;) +scnr+
    „Meine Komplikation hatte eine Komplikation.“
  • macmoonshine schrieb:

    gritsch schrieb:

    nein das geht eben nicht. weil UIAlertView im gegensatz zu NSAlert NICHT blockiert.

    Doch, wo wir gerade so schön beim Rumfrickeln sind, das geht wohl. Du öffnest das Alert und schickst die App für immer in die Runloop. Dann fährt sie nach der Assert-Stelle nicht mit dem fehlerhaften Code fort.

    Also, wenn das jetzt keine wunderschöne Windows-Lösung ist. ;) +scnr+


    nein das geht nicht, weil dann öffnet sich nichtmal der alert. oder hast dus versucht?

    dann zeig doch mal den code der zu folgendem führt:

    alert aufrufen -> wird angezeigt
    dein spezialcode -> wartet bis alert bestätigt wird
    NSLog() oder sonstwas (assert von mir aus).
  • Quellcode

    1. UIAlertView *theAlert = ...;
    2. NSLog(...);
    3. [theAlert show];
    4. [[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:1000000000.0]];

    Die Funktion abort() ruft dann die Delegate-Methode des Alertviews auf.

    gritsch schrieb:

    nein das geht nicht, weil dann öffnet sich nichtmal der alert. oder hast dus versucht?

    Gerade dafür verwende ich ja die Runloop.
    „Meine Komplikation hatte eine Komplikation.“
  • macmoonshine schrieb:

    runUntilDate


    macmoonshine schrieb:

    Quellcode

    1. UIAlertView *theAlert = ...;
    2. NSLog(...);
    3. [theAlert show];
    4. [[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:1000000000.0]];

    Die Funktion abort() ruft dann die Delegate-Methode des Alertviews auf.

    gritsch schrieb:

    nein das geht nicht, weil dann öffnet sich nichtmal der alert. oder hast dus versucht?

    Gerade dafür verwende ich ja die Runloop.


    nein eben nicht. wenn du nach der show-methode die run-loop nicht laufen lässt, dann wird der alert nie sichtbar!

    teste es doch einfach selbst (hier vollständiger code):

    Quellcode

    1. ​- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex
    2. {
    3. NSLog(@"- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex");
    4. }
    5. - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
    6. {
    7. UIAlertView *theAlert = [[UIAlertView alloc] initWithTitle:@"title" message:@"message" delegate:self cancelButtonTitle:@"cancel" otherButtonTitles:nil];
    8. [theAlert show];
    9. [[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:1000000000.0]];
    10. NSLog(@"ende!");
    11. return YES;
    12. }
    Alles anzeigen
  • Mal eben wieder zu meiner Frage zurück:

    Im Prefix-Header vom Projekt, dass auch die C++ Dateien einbindet (es ist keine richtige Library, mein Fehler.)

    Quellcode

    1. #ifdef __cplusplus
    2. #define spassert(x) NSAssert(x, @"Crashed while executing...")
    3. #endif


    Leider klappt folgendes in den C++ Ressourcen dann trotzdem nicht.

    Quellcode

    1. ...
    2. } else if (p1.x == p2.x) {
    3. // Repeat points
    4. spassert(false); // Expected expression
    5. }
    6. ...
    Man kann alles schaffen. Man muss es nur wollen ;)
    www.regetskcob.github.io
  • DanielBocksteger95 schrieb:

    Mal eben wieder zu meiner Frage zurück:

    Im Prefix-Header vom Projekt, dass auch die C++ Dateien einbindet (es ist keine richtige Library, mein Fehler.)

    Quellcode

    1. #ifdef __cplusplus
    2. #define spassert(x) NSAssert(x, @"Crashed while executing...")
    3. #endif


    Leider klappt folgendes in den C++ Ressourcen dann trotzdem nicht.

    Quellcode

    1. ...
    2. } else if (p1.x == p2.x) {
    3. // Repeat points
    4. spassert(false); // Expected expression
    5. }
    6. ...


    wozu auch das NSAssert. das wird dein C-code nicht kennen!

    aber nochmal: das was du machen willst geht nicht! sieh es endlich ein.
    schreib doch den C-bzw C++ code so um dass er exceptions wirft und fang diese dann ab.