Seltsame Interferenz von Boost.Asio und C++0x-Lambdas, die auf Klasseninterna zugreifen

krümelkacker

Das wundert mich gar nicht so richtig. Name-Lookup ist scheinbar "pfuschig" beim Microsoft-Compiler implementiert worden. Das merkt man auch an anderen Stellen.

Tachyon

krümelkacker schrieb:

Das wundert mich gar nicht so richtig. Name-Lookup ist scheinbar total "fuschig" beim Microsoft-Compiler implementiert. Das merkt man auch an anderen Stellen.

Nicht so pfuschig wie die Namen, die für Makros in den OS-Headern vergeben wurden. Das ist mal das Allerletzte. Ich sag nur #define WIN32_LEAN_AND_MEAN *kotz*. Okay, das ist Off-Topic aber ich musste gerade dran denken und bekomme dabei jedes Mal einen Hals.

Nexus

Tachyon schrieb:

Ich sag nur #define WIN32_LEAN_AND_MEAN

Wenigstens kommt hier kein normaler Mensch auf die Idee, selbst sowas zu definieren. Reden wir jetzt nicht über min und max ...

pumuckl, hast du den Bug schon gemeldet?

Tachyon

Nexus schrieb:

Wenigstens kommt hier kein normaler Mensch auf die Idee, selbst sowas zu definieren.

Das MUSS man selbst definieren, um einen Teil der Makros und Deklarationen im globalen Namensraum mit 0815 Namen los zu werden.

Nexus

Ich meine, dass niemand in seinem User-Code zufälligerweise einen Bezeichner wählt, der mit WIN32_LEAN_AND_MEAN kollidiert.

dot

Nexus schrieb:

Reden wir jetzt nicht über min und max ...

Ja, die sind in der Tat nervig. Allerdings gibts ja #define NOMINMAX

hustbaer

Tachyon schrieb:

Das ist mal das Allerletzte. Ich sag nur #define WIN32_LEAN_AND_MEAN *kotz*.

Was ist daran so schlimm, fängt wenigstens mit WIN32_ an.

Schlimm finde ich die min/max Makros die dot bereits erwähnt hat, bzw. auch manch anderen Makros in den MS-Headern, deren namen einach nach Kollisionen schreit.

OK, ich denke ich weiss jetzt was du meinst. Hm. Hmmmmm.
Naja. Finde ich immer noch nicht SO wild.

Da nervt es mich mehr, dass meine Member Funktionen z.T. LoadImageW heissen, obwohl ich LoadImage hingeschrieben habe. *grmpf*
(Und sowas wird man mit WIN32_LEAN_AND_MEAN auch nicht los)

Tachyon

hustbaer schrieb:

Was ist daran so schlimm, fängt wenigstens mit WIN32_ an.

Ich meinte eigentlicht nicht, dass #define WIN32_LEAN_AND_MEAN schlimm ist, sondern dass man dies und noch andere Dinger definieren muss, um diverses Zeugs mit 0815 Namen im globalen Namensraum loszuwerden. Grundsätzlich bekommt man immer wieder total beknackte Fehler deren Quelle schwer zu identifizieren ist (missing ; at <insert your line in your source file here>).
Teilweise hilft es nichtmal mehr, die diversen "lass es weg" Makros zu definieren. Da hilft es nur noch, das MS-Zeugs zu pimpeln.

dot

hustbaer schrieb:

Da nervt es mich mehr, dass meine Member Funktionen z.T. LoadImageW heissen, obwohl ich LoadImage hingeschrieben habe. *grmpf*

Jap, das ist, was dann wirklich nervt und wogegen wohl leider auch kein Kraut gewachsen ist. Aber gut, ist eben nunmal C, wüsste nicht, was MS da viel hätte besser machen können.

Tachyon schrieb:

hustbaer schrieb:

Was ist daran so schlimm, fängt wenigstens mit WIN32_ an.

Ich meinte eigentlicht nicht, dass #define WIN32_LEAN_AND_MEAN schlimm ist, sondern dass man dies und noch andere Dinger definieren muss, um diverses Zeugs mit 0815 Namen im globalen Namensraum loszuwerden.

Was für "0815 Namen" wirst du denn durch #define WIN32_LEAN_AND_MEAN los?

Tachyon

dot schrieb:

Was für "0815 Namen" wirst du denn durch #define WIN32_LEAN_AND_MEAN los?

ERROR
CONST
IN
OUT
OPTIONAL
CALLBACK

Um nur ein paar zu nennen. Ich selbst benutze die Bezeichner nicht, aber bei diversen Libs gibt es immer wieder Kollisionen (wobei es auch scheisse von den entsprechenen Libs ist, solche Bezeichner zu benutzen).

Tachyon

dot schrieb:

Aber gut, ist eben nunmal C, wüsste nicht, was MS da viel hätte besser machen können.

Sowas ist auch in C scheisse. Da kann man z.B. Präfixe benutzen um Namenskonflikte zu vermeiden.

dot

WIN32_LEAN_AND_MEAN dient meines Wissens nach ausschließlich dazu, nur die Header der wirklichen Core-Libraries einzubinden (Dinge wie z.B. Winsock oder OLE werden dann übersprungen). Die Tatsache, dass gewisse Makros dann nicht definiert werden, ist wohl nur ein Seiteneffekt davon und nicht der eigentliche Zweck. Ich würd mich da lieber auf #undef verlassen.

Tachyon schrieb:

dot schrieb:

Aber gut, ist eben nunmal C, wüsste nicht, was MS da viel hätte besser machen können.

Sowas ist auch in C scheisse. Da kann man z.B. Präfixe benutzen um Namenskonflikte zu vermeiden.

Gut, natürlich hast du da recht. Aber wir reden da von Code, der teilweise über 20 Jahre alt ist. Natürlich wär es super, wenn alle Hellsehen könnten und so niemand jemals etwas macht, dass sich in 20 Jahren dann als nicht ganz so toll herausstellt. Aber mal ehrlich, auch wenn es manchmal etwas unangenehm sein kann: Ich hab normalerweise wirklich wichtigere Probleme. Immerhin ist #include <windows.h> sowieso nur ein Implementierungsdetail in ein paar Ecken irgendwo ganz unten, abgeschottet vom richtigen Code.

Btw: Mich würd übrigens auch interessieren, ob pumuckl den Bug schon submitted hat.

pumuckl

Ist auf connect.microsoft.com gemeldet, fix ist schon in den sourcen für die nächste Version eingecheckt. Da ich grade vom Handy aus schreibe (bin im Urlaub), kann ichs nur schwer verlinken Suche nach lambda und [this]-Capture sollte das Ticket aber liefern

hustbaer

dot schrieb:

hustbaer schrieb:

Da nervt es mich mehr, dass meine Member Funktionen z.T. LoadImageW heissen, obwohl ich LoadImage hingeschrieben habe. *grmpf*

Jap, das ist, was dann wirklich nervt und wogegen wohl leider auch kein Kraut gewachsen ist. Aber gut, ist eben nunmal C, wüsste nicht, was MS da viel hätte besser machen können.

Naja, sie könnten das:

#if defined(_M_CEE)
#undef DeleteFile
__inline
BOOL
DeleteFile(
    LPCTSTR lpFileName
    )
{
#ifdef UNICODE
    return DeleteFileW(
#else
    return DeleteFileA(
#endif
        lpFileName
        );
}
#endif  /* _M_CEE */

auch für nicht-managed Builds machen.
Von mir aus mit einem "opt out" Makro, so dass man Projekte die damit dann Zahnräder spucken (warum auch immer) mit definiertem Opt-Out Makro immer noch kompilieren kann.

Wiso gibt's eigentlich niemanden, der genau so einen, sauberen, Ersatz für die windows.h-Dinger schreibt? Oder findet man das irgendwo?

Ethon

fdfdg schrieb:

Wiso gibt's eigentlich niemanden, der genau so einen, sauberen, Ersatz für die windows.h-Dinger schreibt? Oder findet man das irgendwo?

Weil die WinAPI ein allseits ungeliebtes Kind ist (nichtmal Microsoft mag sie), die in den meisten Fällen sowieso nur über stark abstrahierte Interfaces genutzt wird.

Witzig nur dass die freien Implementierungen der WinAPI den selben Mist machen, siehe Wine/MinGW etc.