there are no arguments to ‘memset’ that depend on a template parameter
-
Hallo,
ich kompiliere einen code bei dem die folgende fehlermeldung kommt:
there are no arguments to ‘memset’ that depend on a template parameter,. Ich kompiliere mit g++ 4.1.2 (gcc) unter Linux. Das Makefile muss stimmen weil ich auf einer anderen Maschine den code problemlos compilieren kann. Warum aber auf dieser nicht? Woran könnte das liegen?
Danke
-
Woran könnte das liegen?
Am Code, den wir nicht kennen!
-
Ich kann unmöglich 10tausende Zeilen code hierhin verfrachten.
-
Nein, natürlich nicht. Deshalb sollst du ein Minimalbeispiel (im Umfang 1-20 Zeilen) anfertigen, das besagten Fehler erzeugt. Meist findet man dann schon selbst den Fehler. Sollte das nicht der Fall sein, einfach das Minimalbeispiel mit Fehlerbeschreibung posten.
Gruß
Don06
-
hmm ok..später sagt er auch noch
‘sort’ is not a member of ‘std’ich versuch mich mal an einem beispiel was aber wohl sehr lange dauern dürfte....
-
fragender3 schrieb:
hmm ok..später sagt er auch noch
‘sort’ is not a member of ‘std’ich versuch mich mal an einem beispiel was aber wohl sehr lange dauern dürfte....
Die richtigen includes hast du schon gemacht, oder? (<algorithm> oder was du sonst noch brauchst..)
-
Ja eigentlich dachte ich schon weil es auf anderen Systemen läuft....
Kann es sein dass er auf dem einen system kompiliert ohne probelem und auf dem anderen nicht? Und das nur wegen den includes?
-
Fragender3 schrieb:
Ja eigentlich dachte ich schon weil es auf anderen Systemen läuft....
Kann es sein dass er auf dem einen system kompiliert ohne probelem und auf dem anderen nicht? Und das nur wegen den includes?Sollte nicht, wenn sich beide Compiler an den Standard weitestgehend halten.
Schau sonst mal in der Dokumentation zum Compiler nach, was der Fehler genau bedeutet und du umgehen kannst. Vielleicht findest du was.
-
Fragender3 schrieb:
Kann es sein dass er auf dem einen system kompiliert ohne probelem und auf dem anderen nicht? Und das nur wegen den includes?
Durchaus möglich. Inkludierst du denn den richtigen Header für memset (das wäre <cstring>)? Evtl. wird der auf einem anderen System schon indirekt durch andere Header eingebunden. Sowas kommt vor, aber verlassen sollte man sich darauf eben nicht.
-
fragender3 schrieb:
hmm ok..später sagt er auch noch
‘sort’ is not a member of ‘std’ich versuch mich mal an einem beispiel was aber wohl sehr lange dauern dürfte....
schaut so aus als hättest du zumindest vergessen, den <algorithm>-header einzubinden...
-
Fragender3 schrieb:
Ja eigentlich dachte ich schon weil es auf anderen Systemen läuft....
Kann es sein dass er auf dem einen system kompiliert ohne probelem und auf dem anderen nicht? Und das nur wegen den includes?Ja, nennt sich Standardpfad fuer Includes. Scheint unterschiedlich auf beiden Systemen zu sein.
-
drakon schrieb:
Fragender3 schrieb:
Ja eigentlich dachte ich schon weil es auf anderen Systemen läuft....
Kann es sein dass er auf dem einen system kompiliert ohne probelem und auf dem anderen nicht? Und das nur wegen den includes?Sollte nicht, wenn sich beide Compiler an den Standard weitestgehend halten.
Schau sonst mal in der Dokumentation zum Compiler nach, was der Fehler genau bedeutet und du umgehen kannst. Vielleicht findest du was.Natürlich kann das sein. Es ist nicht verboten dass ein Standard-Header-File ein anderes inkludiert. Es ist aber auch nicht vorgeschrieben.
z.B. kann es leicht sein dass <string> auch <vector> mit reinzieht. Kann aber auch sein dass es nicht so ist.
Daher kann ein Programm mit einem Compiler problemlos bauen, mit einem anderen aber nicht. Und das ohne dass einer der beiden Compiler irgendwo "nicht Standardkonform" wäre.
-
hustbaer schrieb:
Natürlich kann das sein. Es ist nicht verboten dass ein Standard-Header-File ein anderes inkludiert. Es ist aber auch nicht vorgeschrieben.
z.B. kann es leicht sein dass <string> auch <vector> mit reinzieht. Kann aber auch sein dass es nicht so ist.
Daher kann ein Programm mit einem Compiler problemlos bauen, mit einem anderen aber nicht. Und das ohne dass einer der beiden Compiler irgendwo "nicht Standardkonform" wäre.Davon habe ich auch nichts gesagt..
Und eine C++ Implementierung muss alle Standardheader zur Verfügung stellen, ansonsten ist es nicht standardkonform. Oder verstehe ich dich falsch?!
-
Es stimmt schon, was hustbaer sagt. Die Frage war ja, ob ein Code nur aufgrund der Includes bei einem Compiler kompilieren kann und bei einem anderen nicht, ohne den Standard zu verletzen. Und das kann sein, wenn gewisse Header andere einbinden können (und dabei immer noch standardkonform sind).
-
Nexus schrieb:
Es stimmt schon, was hustbaer sagt. Die Frage war ja, ob ein Code nur aufgrund der Includes bei einem Compiler kompilieren kann und bei einem anderen nicht, ohne den Standard zu verletzen. Und das kann sein, wenn gewisse Header andere einbinden können (und dabei immer noch standardkonform sind).
Ja, aber dann hat er in seinem eigenen Code die includes vergessen und nur durch Glück die richtigen inkludiert. Und das habe ich eigentlich ausgeschlossen, weil ich ja gefragt habe, ob er die includes (algorithm) gemacht hat.
Und zugegeben ich habe dem "nur wegen den includes" bei der Frage nicht viel Aufmerksamkeit geschenkt und daher meine Aussage, dass es so eigentlich gehen sollte, wenn sich die Implementierung an den Standard hält.
Möglich ist es ja, wenn man die Header selbst nicht einbindet..
-
Also es liegt tatsächlich an den #includes. Hab da einiges hinzugefügt <algorithm> und <cstring> etc...
Jetzt ist aber meine Frage:
Wenn das Programm ohne diese includes unter einem compiler läuft und unter dem nächsten nicht - was wäre eine saubere Möglichkeit das Programm auf beiden zum problemlosen kompilieren zu bringen?
Sollte man jetzt die fehlenden includes drin lassen? Beschwert sich der andere compiler dann nicht irgendwie dass ein include 2-mal drin ist? So nach dem Motto "algorithm already included" ? Ich kann doch programmtechnisch nicht wissen welche includes schon eingebunden sind und welche nicht.Ist also der Weg: Möglichst die wichtigsten (alle) includes von Haus aus mitzuliefern im Programm?
Danke euch für euren Ratschlag...
-
Fragender3 schrieb:
Sollte man jetzt die fehlenden includes drin lassen?
Ja
Fragender3 schrieb:
Beschwert sich der andere compiler dann nicht irgendwie dass ein include 2-mal drin ist?
Nein.
Solange die Include-Guards in den Headern sind, ist das kein Problem.Fragender3 schrieb:
Ist also der Weg: Möglichst die wichtigsten (alle) includes von Haus aus mitzuliefern im Programm?
Auf keinem Fall alle Includes. Das erhöht sinnlos die Compilezeit. Nur die, die du brauchst.
-
Ist also der Weg: Möglichst die wichtigsten (alle) includes von Haus aus mitzuliefern im Programm?
Wie Braunstein schon sagte eher nicht. Probier soweit möglich gar keine, oder lediglich Vorwärtsdeklarationen zu benutzen. Und die Header dann in der .cpp zu inkludieren, wenn du sie brauchst. Aber wenn du eine Klasse brauchst, dann solltest du wissen, von wo die kommt und welchen Header du inkluden sollst und dann den miteinbeziehen. Sonst passiert einmal genau das, was du jetzt hattest.
