4. Fehlermeldung E2015 Mehrdeutigkeit zwischen 'funktion1' und 'funktion2'

Fehlermeldung E2015 Mehrdeutigkeit zwischen 'funktion1' und 'funktion2'

  • ?

    Hallo.

    Ich habe eine Komponente in mein C++Builder2009 eingebunden und C++Builder2009 hat dann hpp Dateien für die Komponente erstellt.

    Ich erhalte dann leider eine Fehlermeldung:

    [BCC32 Fehler] sysset.h(38): E2015 Mehrdeutigkeit zwischen 'Uobjdelphiimport::memset(void *,int,unsigned int) at ..\..\..\..\Shared\Lib\RAD2009\Uobjdelphiimport.hpp:96' und 'std::memset(void *,int,unsigned int)'

    In Uobjdelphiimport.hpp:96 steht:

    // CodeGear C++Builder
// Copyright (c) 1995, 2008 by CodeGear
// All rights reserved

// (DO NOT EDIT: machine generated header) 'Uobjdelphiimport.pas' rev: 20.00
extern PACKAGE void __cdecl memset(void * a, int b, unsigned c);

    Gibt es eine Möglichkeit hier was zu drehen, so das der Fehler verschwindet? Die Komponente ist Trial, ich habe keinen Zugriff auf die pas-Datei.

    0
  • A

    Das ist eine weitere Konsequenz des using namespace , das der Delphi-Compiler leider immer noch unweigerlich generiert.

    Erur schrieb:

    In Uobjdelphiimport.hpp:96 steht:

    // CodeGear C++Builder
// Copyright (c) 1995, 2008 by CodeGear
// All rights reserved

// (DO NOT EDIT: machine generated header) 'Uobjdelphiimport.pas' rev: 20.00
extern PACKAGE void __cdecl memset(void * a, int b, unsigned c);

    Es ist natürlich eine schlechte Idee, Funktionen der C-RTL einfach so neuzudefinieren, aber das hilft dir natürlich nicht weiter.

    Erur schrieb:

    Gibt es eine Möglichkeit hier was zu drehen, so das der Fehler verschwindet? Die Komponente ist Trial, ich habe keinen Zugriff auf die pas-Datei.

    Du kannst einfach die Definition in Uobjdelphiimport.hpp auskommentieren. Wenn du die Komponente erworben hast und im Besitz des Quelltextes bist, ist wohl die einfachste Option, die Funktion in Delphi umzubenennen (wenn du sowohl Delphi und C++Builder bzw. RAD Studio hast, kannst du dazu einfach das Rename-Refactoring verwenden), alternativ könntest du die Deklaration aus dem interface-Abschnitt der Unit entfernen und ggf. die Definition in die implementation-Abschnitte anderer Units einfügen.

    Die saubere Lösung wäre, alle Referenzierungen von memset in Delphi-Code durch Aufrufe von FillChar() zu ersetzen.

    0

  • std::fill ist eine andere Alternative

    0
  • A

    DocShoe schrieb:

    std::fill ist eine andere Alternative

    In Delphi? 🙂

    0

  • audacia schrieb:

    DocShoe schrieb:

    std::fill ist eine andere Alternative

    In Delphi? 🙂

    Achja, isja Embarcadero Delphi Gemurkse :p Hab deine Antwort nur halb gelesen und davon wohl auch nur die Hälfte wahrgenommen.

    Gibt´s in Delphi eigentlich keine unsigned Datentypen? Was mich bei der VCL immer noch stört sind ständige Warnungen wegen signed - unsigned Vergleichen und fehlende const-correctness.

    0
  • A

    DocShoe schrieb:

    Gibt´s in Delphi eigentlich keine unsigned Datentypen?

    Freilich gibts die: Byte, Word, Cardinal, UInt8, UInt16, UInt32, UInt64, NativeUInt - was immer dein Herz begehrt. Sie sind nur nicht gebräuchlich.

    DocShoe schrieb:

    Was mich bei der VCL immer noch stört sind ständige Warnungen wegen signed - unsigned Vergleichen und fehlende const-correctness.

    Const-Correctness gibt es in Delphi nicht (wohlgemerkt auch in fast keiner anderen modernen Sprache). Signed-unsigned-Warnungen und Probleme mit Const-Correctness vermeidest du, indem du dich auch in C++-Code - soweit er die VCL betrifft - an die Delphi-Konventionen hältst und auf Const-Correctness und unsigned-Datentypen verzichtest.

    0
Anmelden zum Antworten