Wie verhindert man am besten "Class GGCar is implemented in both $A and $B. One of the two will be used. Which one is undefined."?

  • Namespaces in C++ verwendet man mit :: und nicht .

    Ich kann anstelle von using auch alles in "namespace foo {}" Klammern.
    Üblicherweise (aber nicht zwangsläufig) verwendet ein bestimmter Code abschnitt überwiegend Symbole, die ihm "nahe" stehen. In diesem Fall muss ich mich gar nicht um Namespaces kümmern, wenn ich nicht ein gleichnamiges Objekt eines anderen Namespaces ansprechen will.

    Das führt dann insgesamt dazu, dass ich in der Regel in meinem Code schreibe:
    Car
    Oder, wenn ich lieber ein Namespace alias für GritschProjekt::AutoVerwaltung::Objekte als "gauto" in der aktuellen TU verwenden will
    gauto::Car

    Das finde ich übersichtlicher, als
    GritschProjektAutoVerwaltungObjekteCar

    Wenn man versucht, Zeilen maximal auf 80 Zeichen zu halten, was (in meinen Augen) sehr hilfreich sein kann, hat man das Problem
    mit dem Ausschreiben, dass man 50% der Zeile für den "Namespace" der verschiedenen Klassen verwendet.

    Das ganze führt dann letztendlich dazu, dass viele Menschen nur kurze Namespace-Bezeichner, wie eben "GG" wählen, wie es auch von Apple mehr oder weniger vorgemacht wird. Und genau das kann dann schnell zu Kollisionen führen.

    Aber es freut mich, dass refactoring heutzutage so einfach und robust mit Xcode geht. Sollte ich mir mal wieder anschauen.
    ♥C++

  • zerm schrieb:

    Namespaces in C++ verwendet man mit :: und nicht .

    Da hast du selbstverständlich Recht.

    zerm schrieb:

    Ich kann anstelle von using auch alles in "namespace foo {}" Klammern.
    Üblicherweise (aber nicht zwangsläufig) verwendet ein bestimmter Code abschnitt überwiegend Symbole, die ihm "nahe" stehen. In diesem Fall muss ich mich gar nicht um Namespaces kümmern, wenn ich nicht ein gleichnamiges Objekt eines anderen Namespaces ansprechen will.

    Das führt dann insgesamt dazu, dass ich in der Regel in meinem Code schreibe:
    Car
    Oder, wenn ich lieber ein Namespace alias für GritschProjekt::AutoVerwaltung::Objekte als "gauto" in der aktuellen TU verwenden will
    gauto::Car

    Das finde ich übersichtlicher, als
    GritschProjektAutoVerwaltungObjekteCar

    Ja, Tipparbeit, sagte ich ja.

    zerm schrieb:

    Wenn man versucht, Zeilen maximal auf 80 Zeichen zu halten, was (in meinen Augen) sehr hilfreich sein kann, hat man das Problem
    mit dem Ausschreiben, dass man 50% der Zeile für den "Namespace" der verschiedenen Klassen verwendet.

    Das ganze führt dann letztendlich dazu, dass viele Menschen nur kurze Namespace-Bezeichner, wie eben "GG" wählen, wie es auch von Apple mehr oder weniger vorgemacht wird. Und genau das kann dann schnell zu Kollisionen führen.

    Nein, es führt nicht schnell zu Kollisionen. Ich hatte noch nie eine. Sie lässt sich auch leicht vermeiden. Und das aktuelle Problem hätte ich wirklich gerne mal konkret genannt.

    zerm schrieb:

    Aber es freut mich, dass refactoring heutzutage so einfach und robust mit Xcode geht. Sollte ich mir mal wieder anschauen.

    Nur zu
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • zerm schrieb:

    Aber es freut mich, dass refactoring heutzutage so einfach und robust mit Xcode geht. Sollte ich mir mal wieder anschauen.


    wo hast du denn das gelesen?
    das funktioniert ja so gut wie garnicht. kaum verwendet man obj-c++ schon scheitert er (und wenn man nur eine zeile c++ drin hat).

    dann gibts auch noch jede menge andere situationen wos nicht funktioniert.

    also kann man gleich ein search-and-replace machen und die files manuell umbenennen. wenn die klassen in nibs/xibs enthalten sind sollte man eh vorsichtig damit sein.

  • gritsch schrieb:

    konkret geht es um "Container" und "ContainerInfo" aber das ist auch nur ein beispielprojekt bei dem mir das aufgefallen ist.

    Ich habe noch nie Namespace-Kollisionen gehabt, vielleicht aber auch deshalb, weil ich noch nie auf die Idee gekommen bin, eine meiner Klassen einfach "Container" zu nennen. Die haben alle spezifischere Namen.

    Was ich eigentlich sagen wollte: Gibt's eigentlich @compatibility_alias noch? Damit kann man seine Klasse toll unique benennen und muss im eigenen Code trotzdem nicht den langen Namen schreiben.
    Multigrad - 360°-Produktfotografie für den Mac

  • gritsch schrieb:

    zerm schrieb:

    Aber es freut mich, dass refactoring heutzutage so einfach und robust mit Xcode geht. Sollte ich mir mal wieder anschauen.


    wo hast du denn das gelesen?
    das funktioniert ja so gut wie garnicht. kaum verwendet man obj-c++ schon scheitert er (und wenn man nur eine zeile c++ drin hat).

    dann gibts auch noch jede menge andere situationen wos nicht funktioniert.

    also kann man gleich ein search-and-replace machen und die files manuell umbenennen. wenn die klassen in nibs/xibs enthalten sind sollte man eh vorsichtig damit sein.

    Ich habe mich auf die Aussage von Amin bezogen :P
    ♥C++

  • mattik schrieb:

    gritsch schrieb:

    konkret geht es um "Container" und "ContainerInfo" aber das ist auch nur ein beispielprojekt bei dem mir das aufgefallen ist.

    Ich habe noch nie Namespace-Kollisionen gehabt, vielleicht aber auch deshalb, weil ich noch nie auf die Idee gekommen bin, eine meiner Klassen einfach "Container" zu nennen. Die haben alle spezifischere Namen.

    Was ich eigentlich sagen wollte: Gibt's eigentlich @compatibility_alias noch? Damit kann man seine Klasse toll unique benennen und muss im eigenen Code trotzdem nicht den langen Namen schreiben.

    Es geht sogar ein simpler #define.

    Aber ich bekomme das auch ums Verrecken nicht hin. Und die Laufzeitumgebung gibt mir immer nur die Klassen zurück, die in meiner Applikation und den für meine Applikation geladenen Framworks existieren.

    Bei Container rate ich mal eher, dass man innerhalb seines Bundles zweimal denselben Bezeichner hat. Ich neige zwar auch zu kurzen Bezeichnern, aber Container? Container was?

    HInzukommt, dasss in Apple-Frameworkjs eigentlich immer ein Prefix besteht. Muss ein seltsames Framework sein, bei dem das nicht der Fall ist.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Amin Negm-Awad ()

  • gritsch schrieb:

    zerm schrieb:

    Aber es freut mich, dass refactoring heutzutage so einfach und robust mit Xcode geht. Sollte ich mir mal wieder anschauen.


    wo hast du denn das gelesen?
    das funktioniert ja so gut wie garnicht. kaum verwendet man obj-c++ schon scheitert er (und wenn man nur eine zeile c++ drin hat).

    dann gibts auch noch jede menge andere situationen wos nicht funktioniert.

    also kann man gleich ein search-and-replace machen und die files manuell umbenennen. wenn die klassen in nibs/xibs enthalten sind sollte man eh vorsichtig damit sein.

    Ich habe bei der simplen Umbenennung einer Klasse noch nie ein Problem gehabt. Kannst du mir hier auch ein Beispiel geben? Immerhin bekommst du auch einen Laufzeitfehler hin, den ich nicht nachvollziehen kann.

    Vielleicht hast du auch einfach einen ganz besonderen "Stil" des Programmierens, der zahlreiche Herausforderungen enthält.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    mattik schrieb:

    gritsch schrieb:

    konkret geht es um "Container" und "ContainerInfo" aber das ist auch nur ein beispielprojekt bei dem mir das aufgefallen ist.

    Ich habe noch nie Namespace-Kollisionen gehabt, vielleicht aber auch deshalb, weil ich noch nie auf die Idee gekommen bin, eine meiner Klassen einfach "Container" zu nennen. Die haben alle spezifischere Namen.

    Was ich eigentlich sagen wollte: Gibt's eigentlich @compatibility_alias noch? Damit kann man seine Klasse toll unique benennen und muss im eigenen Code trotzdem nicht den langen Namen schreiben.

    Es geht sogar ein simpler #define.

    Aber ich bekomme das auch ums Verrecken nicht hin. Und die Laufzeitumgebung gibt mir immer nur die Klassen zurück, die in meiner Applikation und den für meine Applikation geladenen Framworks existieren.

    Bei Container rate ich mal eher, dass man innerhalb seines Bundles zweimal denselben Bezeichner hat. Ich neige zwar auch zu kurzen Bezeichnern, aber Container? Container was?

    HInzukommt, dasss in Apple-Frameworkjs eigentlich immer ein Prefix besteht. Muss ein seltsames Framework sein, bei dem das nicht der Fall ist.


    wie gesagt, es handelte sich um ein testprojekt das jemand unter 10.7 ausgeführt hat. ich glaube dev-preview 2

    und apple hat in dem framework eben kein prefix bei Container und ContainerInfo hinzugefügt!

  • Amin Negm-Awad schrieb:

    gritsch schrieb:

    zerm schrieb:

    Aber es freut mich, dass refactoring heutzutage so einfach und robust mit Xcode geht. Sollte ich mir mal wieder anschauen.


    wo hast du denn das gelesen?
    das funktioniert ja so gut wie garnicht. kaum verwendet man obj-c++ schon scheitert er (und wenn man nur eine zeile c++ drin hat).

    dann gibts auch noch jede menge andere situationen wos nicht funktioniert.

    also kann man gleich ein search-and-replace machen und die files manuell umbenennen. wenn die klassen in nibs/xibs enthalten sind sollte man eh vorsichtig damit sein.

    Ich habe bei der simplen Umbenennung einer Klasse noch nie ein Problem gehabt. Kannst du mir hier auch ein Beispiel geben? Immerhin bekommst du auch einen Laufzeitfehler hin, den ich nicht nachvollziehen kann.

    Vielleicht hast du auch einfach einen ganz besonderen "Stil" des Programmierens, der zahlreiche Herausforderungen enthält.


    search-and-replace funktioniert, refactor aber nicht.

    benenne einfach mal eine .m in .mm um schon tut sich gar nix mehr :(

  • gritsch schrieb:

    Amin Negm-Awad schrieb:

    mattik schrieb:

    gritsch schrieb:

    konkret geht es um "Container" und "ContainerInfo" aber das ist auch nur ein beispielprojekt bei dem mir das aufgefallen ist.

    Ich habe noch nie Namespace-Kollisionen gehabt, vielleicht aber auch deshalb, weil ich noch nie auf die Idee gekommen bin, eine meiner Klassen einfach "Container" zu nennen. Die haben alle spezifischere Namen.

    Was ich eigentlich sagen wollte: Gibt's eigentlich @compatibility_alias noch? Damit kann man seine Klasse toll unique benennen und muss im eigenen Code trotzdem nicht den langen Namen schreiben.

    Es geht sogar ein simpler #define.

    Aber ich bekomme das auch ums Verrecken nicht hin. Und die Laufzeitumgebung gibt mir immer nur die Klassen zurück, die in meiner Applikation und den für meine Applikation geladenen Framworks existieren.

    Bei Container rate ich mal eher, dass man innerhalb seines Bundles zweimal denselben Bezeichner hat. Ich neige zwar auch zu kurzen Bezeichnern, aber Container? Container was?

    HInzukommt, dasss in Apple-Frameworkjs eigentlich immer ein Prefix besteht. Muss ein seltsames Framework sein, bei dem das nicht der Fall ist.


    wie gesagt, es handelte sich um ein testprojekt das jemand unter 10.7 ausgeführt hat. ich glaube dev-preview 2

    und apple hat in dem framework eben kein prefix bei Container und ContainerInfo hinzugefügt!

    Ich wunder mich immer weiter. Auf meinem Mac ist WebKit installiert, Safari läuft sogar. Und trotzdem habe ich nicht das geringste Problem, eine Klasse WebView zu nennen. Wie bekommst du diese Kollision mit einem in /System/Library/PrivateFrameworks/ liegendem Framework nur hin?

    Dass übrigens bei einem neuen Betriebssystem neue Bezeichner reserviert sind, ist nichts Neues. Egal, jedenfalls hat das nun gar nichts mit deinem OP zu tun. Ich zitiere:
    "Also wenn ich in meinem code eine Klasse namens GGCar erstelle und dann durch irgend ein programm auf irgeneinem rechner irgendein framework installiert wird welches auch eine klasse GGCar enthällt kommt diese meldung."

    Nach der jetzigen Beschreibung dürfte es sich eher um eine Klasse des Laufzeitsystems handeln. Und das Problem hat man immer bei Betriebssystemwechseln. Das ist nichts Neues und auch kein Problem, selbst wenn man nichts sagende Namen hat. Es ist jedenfalls ganz bestimmt nicht das Problem, dass du befürchtest.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Amin Negm-Awad ()

  • Amin Negm-Awad schrieb:

    gritsch schrieb:

    Amin Negm-Awad schrieb:

    mattik schrieb:

    gritsch schrieb:

    konkret geht es um "Container" und "ContainerInfo" aber das ist auch nur ein beispielprojekt bei dem mir das aufgefallen ist.

    Ich habe noch nie Namespace-Kollisionen gehabt, vielleicht aber auch deshalb, weil ich noch nie auf die Idee gekommen bin, eine meiner Klassen einfach "Container" zu nennen. Die haben alle spezifischere Namen.

    Was ich eigentlich sagen wollte: Gibt's eigentlich @compatibility_alias noch? Damit kann man seine Klasse toll unique benennen und muss im eigenen Code trotzdem nicht den langen Namen schreiben.

    Es geht sogar ein simpler #define.

    Aber ich bekomme das auch ums Verrecken nicht hin. Und die Laufzeitumgebung gibt mir immer nur die Klassen zurück, die in meiner Applikation und den für meine Applikation geladenen Framworks existieren.

    Bei Container rate ich mal eher, dass man innerhalb seines Bundles zweimal denselben Bezeichner hat. Ich neige zwar auch zu kurzen Bezeichnern, aber Container? Container was?

    HInzukommt, dasss in Apple-Frameworkjs eigentlich immer ein Prefix besteht. Muss ein seltsames Framework sein, bei dem das nicht der Fall ist.


    wie gesagt, es handelte sich um ein testprojekt das jemand unter 10.7 ausgeführt hat. ich glaube dev-preview 2

    und apple hat in dem framework eben kein prefix bei Container und ContainerInfo hinzugefügt!

    Ich wunder mich immer weiter. Auf meinem Mac ist WebKit installiert, Safari läuft sogar. Und trotzdem habe ich nicht das geringste Problem, eine Klasse WebView zu nennen. Wie bekommst du diese Kollision mit einem in /System/Library/PrivateFrameworks/ liegendem Framework nur hin?

    Dass übrigens bei einem neuen Betriebssystem neue Bezeichner reserviert sind, ist nichts Neues. Egal, jedenfalls hat das nun gar nichts mit deinem OP zu tun. Ich zitiere:
    "Also wenn ich in meinem code eine Klasse namens GGCar erstelle und dann durch irgend ein programm auf irgeneinem rechner irgendein framework installiert wird welches auch eine klasse GGCar enthällt kommt diese meldung."


    dann füg doch das WebKit-Framework dazu!

    und NEIN, ich habe das private framework nicht im projekt mit drin (auch sonst kein anderes privates).

    in preview 1 gabs das problem noch nicht...

  • gritsch schrieb:



    dann füg doch das WebKit-Framework dazu!

    Bist du vom Wickeltisch gefallen?

    gritsch schrieb:

    und NEIN, ich habe das private framework nicht im projekt mit drin (auch sonst kein anderes privates).

    in preview 1 gabs das problem noch nicht...

    Welches? Das hier:
    "Also wenn ich in meinem code eine Klasse namens GGCar erstelle und dann durch irgend ein programm auf irgeneinem rechner irgendein framework installiert wird welches auch eine klasse GGCar enthällt kommt diese meldung."

    Das gab es noch nie und wird es auch nicht geben.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    gritsch schrieb:



    dann füg doch das WebKit-Framework dazu!

    Bist du vom Wickeltisch gefallen?

    gritsch schrieb:

    und NEIN, ich habe das private framework nicht im projekt mit drin (auch sonst kein anderes privates).

    in preview 1 gabs das problem noch nicht...

    Welches? Das hier:
    "Also wenn ich in meinem code eine Klasse namens GGCar erstelle und dann durch irgend ein programm auf irgeneinem rechner irgendein framework installiert wird welches auch eine klasse GGCar enthällt kommt diese meldung."

    Das gab es noch nie und wird es auch nicht geben.


    wickeltisch?

  • Captain Obvious, willst du wirklich wissen, wie man damit umgeht, dass ein von einem selbst verwendete Framework denselben Klassennamen verwendet wie eine selbst geschriebene Klasse? Ganz einfach: Vor dem Programmieren einfach programmieren lernen. Solltest du mal befolgen.

    Aber wie war das bei dir:
    "Also wenn ich in meinem code eine Klasse namens GGCar erstelle und dann durch irgend ein programm auf irgeneinem rechner irgendein framework installiert wird welches auch eine klasse GGCar enthällt kommt diese meldung."

    Ich bekomme und bekomme einfach das Problem nicht hin. Bitte erhelle mich.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    Captain Obvious, willst du wirklich wissen, wie man damit umgeht, dass ein von einem selbst verwendete Framework denselben Klassennamen verwendet wie eine selbst geschriebene Klasse? Ganz einfach: Vor dem Programmieren einfach programmieren lernen. Solltest du mal befolgen.

    Aber wie war das bei dir:
    "Also wenn ich in meinem code eine Klasse namens GGCar erstelle und dann durch irgend ein programm auf irgeneinem rechner irgendein framework installiert wird welches auch eine klasse GGCar enthällt kommt diese meldung."

    Ich bekomme und bekomme einfach das Problem nicht hin. Bitte erhelle mich.


    ich verwende das private framework nicht. das wurde mir untergeschoben (von apple).

    also was hat das mit wickeltisch zu tun? zeit in den sarg zu steigen oder was?