[C/C++] Symbol-Konflikt mit anderen Libraries

[__makx]

Hallo.

 

Die aktuellen Tinkerforge C/C++ bindings definieren ein struct "Thread" in ip_connection.h.

Bisher habe ich mich nicht sehr daran gestört, dass Tinkerforge keine prefixes verwendet (auch wenn das eigentlich überhaupt nicht gut ist).

 

Das Symbol "Thread" brauche ich aber an anderer Stelle.

Ich habe keine Lust die ganzen Tinkerforge-Bindings umzuschreiben.

Gibt es eine einfache, schnelle, saubere Möglichkeit diesen Konflikt zu lösen?

 

Danke im Voraus.

[__makx]

Habe mir den source code der bindings jetzt nochmal angeschaut es einfach mit einem "search and replace" probiert um das TinkerForge struct umzubenennen.

Scheint soweit geklappt zu haben.

 

Finde ich zwar keine schöne Lösung aber Hauptsache es läuft.

[AuronX]

So sehr ich sowohl C als auch C++ nicht mag:

 

Aber ich finde es noch immer komisch die C-Bindings gleichzeitig als C++-Bindings zu verkaufen.

 

Klar es funktioniert. Aber die C-Bindings müssen sich ihre Objekt-orientierung selbst bauen, während das in C++ alles da wäre. (ich bin gerade wieder drauf gekommen, weil __makx was von Präfixen geschrieben hat... namespaces... geht natürlich nur in C++)

 

Vielleicht wäre das nochmal was? (das "es funktioniert"-Argument würde ja auch für viele andere Sprachen gelten, die native Libraries einbinden können)

[borg]

Das ist in der Tat unschön, ich schreib es mir mal auf die TODO-Liste das für die nächste Version umzubenennen.

 

@AuronX: Objektorientierte C++-Bindings wären natürlich besser. Wir haben nur erst noch ein paar andere Sprachen die wir vorher unterstützen wollen. Die aktuellen C/C++ Bindings sind schon absolut legales C++, sie verwenden nur keine Klassen . Das ist schon ein bisschen was anderes als eine C-Lib in C# einzubinden (z.B.).

[JavaLaurence]

Does Tinkerforge have approximate statistics (%) for how popular the different language bindings are? I'm curious how the current language spectrum is divided up.

[AuronX]

C#-Bindings mittels pInvoke sind auch "legales" C# ;-)

Aber ich verstehe schon was du meinst...

 

I would also be interested in such statistics, however... I am not sure if download-statistics would be sufficient to give n indication... but they might be...

[__makx]

@borg:

Danke.

Ich habe mir den source code nicht im Detail angeschaut, aber es scheint dass einige Symbole (structs) aus ip_connection.h sehr leicht mit anderen Projekten kollidieren können, obwohl sie ausschließlich in ip_connection.c verwendet werden. Das betrifft neben "Thread" auch "Queue", "QueueItem", "Table", "Semaphore", "Event" und "Mutex".

Es gibt keinen Grund diese dem User zugänglich zu machen, also könnte man sie auch beliebig verstecken oder umbenennen.

 

Ansonsten habe ich kein Problem damit, C bindings in C++ zu verwenden. "structs" sind in C++ genau dasselbe wie Objekte und ob ich nun member Funktionen aufrufe oder globalen statischen Funktionen einen pointer mitgebe ist auch dasselbe.

 

Mehr geärgert habe ich mich darüber, dass es keine Kompatibilität zwischen verschiedenen Versionen gibt:

Verwendet man einen neueren brickd, muss man auch die Bindings austauschen. D.h. alte kompilierte Versionen meines Projektes laufen nicht mehr.

Und dass obwohl die Kommunikation sowieso über einen lokalen Socket geht.

[borg]

Mehr geärgert habe ich mich darüber, dass es keine Kompatibilität zwischen verschiedenen Versionen gibt:

Verwendet man einen neueren brickd, muss man auch die Bindings austauschen. D.h. alte kompilierte Versionen meines Projektes laufen nicht mehr.

Und dass obwohl die Kommunikation sowieso über einen lokalen Socket geht.

Es gibt eine inkompatibilität zwischen 1.x.y und 2.x.y, weil wir da das Protokoll geändert haben (auch das was über den lokalen Socket geht). Alles was 1.x.y und alles was 2.x.y ist, ist zueinander kompatibel .

[photron]

Interne Typen wie Thread, Socket, Mutex und so weiter sind in C/c++ Bindings Version 2.0.9 nicht mehr öffentlicher Teil von ip_connection.h.