g++ 4.1 & namespaces

[jogix]

Hi Leute.

Ich stehe gerade voll auf dem Schlauch und könnte mal einen Pointer gebrauchen...

Also, ich habe vor einem halben Jahr ein Stück Code gehackt, das auch einwandfrei lief und compilierbar war. Leider kann ich nicht sagen, unter welcher g++ Version ich gearbeitet habe, ob's 3.4 oder 4.0 war

However, wenn ich das Zeugs jetzt compiliere, beschwert sich der Compiler über diverse namespace Probleme.

Code: Alles auswählen

namespace liv {

typedef std::vector<std::string> data;

// ...
data myString;

Ok, also ich nutze Klassen aus dem namespace std in meinem eigenen namespace. Eine using Deklarative mag ich nicht verwenden, da nur ganz wenige Stellen auf std zurückgreifen, das häufigste habe ich durch den typedef abgedeckt.

zwei Arten von Fehlermeldungen kommen, wobei die erste wohl erledigt ist, wenn die zweite gesolvt ist:

Code: Alles auswählen

expected initializer before '<' token
'liv::std::string' has not been declared

Die erste Fehlermeldung bezieht sich direkt auf die typedef-Definition, sprich er kann nix mit dem std::vector anfangen, was man bei der zweiten Fehlermeldung auch schön sieht, da er den namespace std innerhalb des namespaves liv sucht. Warum?

Was hat sich bei der namespace-Verwendung geändert? Mein Code ist eigentlich direkt angelehnt an Stroustrup, der ja wiederum den Standard beschreibt. Hat sich im Standard was geändert (ist mir da tatsächlich was entgangen), oder ist durch die neue Stricktheit der GCC 4.1 da eine dermaßen gravierende Änderung eingeflossen....

Ich bin gerade ein wenig ratlos.

cheers,
Jogix

[Corcovado]

Hallo,
.. is schon ne Weile her mit Cpp bei mir (also einfach ignorieren, wenn die Vermutungen total diletantisch sind):

Vllt fehlt was von den folgenden Zeilen, using hatteste ja schon erwaehnt, aber die includes?

Code: Alles auswählen

#include <iostream>
#include <string>
using namespace std;

Ausserdem, myString is doch kein String?! Ich lese das als ein Object eines Vectors der String Elemente (Template) besitzt, bzw dessen Elemente als String angelegt werden, oder?

[crazyed]

Der gcc 4.1 ist nicht mehr so fehlertolerant wie die vorhergehenden Versionen, man kann schon behaupten, daß ein Debugger eingearbeitet ist.
Wo der Fehler sitzt kann ich dir nicht sagen, nur erzeugt der erste Fehter dann weitere und nicht umgekehrt...

[jogix]

Hallo,
.. is schon ne Weile her mit Cpp bei mir (also einfach ignorieren, wenn die Vermutungen total diletantisch sind):

Vllt fehlt was von den folgenden Zeilen, using hatteste ja schon erwaehnt, aber die includes?

Code: Alles auswählen

#include <iostream>
#include <string>
using namespace std;

Ausserdem, myString is doch kein String?! Ich lese das als ein Object eines Vectors der String Elemente (Template) besitzt, bzw dessen Elemente als String angelegt werden, oder?

Logisch, die includes sind drin... wie ja erwähnt, lief der Code ja auch mit gcc 3.4 oder 4.0.

using namespace std mag ich eben nicht verwenden, da ich nur ganz weniges davon brauche und meine Klasse (Teil einer Lib) nicht unnötig mit so'nem Kram belasten mag.

MyString ist ein Vector mit Strings drinne, ja. Ich habe auf die Schnelle irgendeinen Namen gebraucht. Der Originalname hätte eher zur Verwirrung als zur Klärung beigetragen Aber ok, das nächste Mal bin ich etwas einfallsreicher.... wie wärs mit myStringList

[jogix]

Der gcc 4.1 ist nicht mehr so fehlertolerant wie die vorhergehenden Versionen, man kann schon behaupten, daß ein Debugger eingearbeitet ist.
Wo der Fehler sitzt kann ich dir nicht sagen, nur erzeugt der erste Fehter dann weitere und nicht umgekehrt...

Ja, und das ist auch gut so! Aber mein Code orientiert sich am Standard, wenn ich nicht ganz daneben liege. Daher bin ich ein wenig verwirrt.

Was die Fehlerreihenfolge angeht: natürlich erzeugt der erste Fehler eine Reihe von Fehlern, nämlich überall dort, wo >>MyString<<, also der Typedef verwendet wird. Der zweite Fehler hat erstmal nix mit dem ersten zu tun. Allerdings, schaut man sich die Fehlermeldungen an, erkennt man, daß exakt der zweite Fehler auch beim ersten vorliegt, allerdings in einer anderen Schachtelungstiefe, daher wird eine andere Fehlermeldung erzeugt. Faktisch ist der erste Fehler aber genau gleich dem Zweiten, nur mit Context.

[Corcovado]

Bloede Frage, aber versuch doch das Problem mal in ein simples Demo einzupacken und poste die paar Zeilen. Der Fehler - wenn er denn wirklich generell ist und eben keine vergessenes Zeichen, o.ae. betrifft - sollte sich doch dabei reproduzieren lassen?

Wenn es mit dem neuen gcc nich mehr geht, dann wird es evtl beim alten schon ne Warnung gegeben haben, oder?

Gabs da nich auch diese extern Deklarationen in C++, vllt druecken die alten gcc's da einfach nur ein Auge zu?

[gms]

Bloede Frage, aber versuch doch das Problem mal in ein simples
Demo einzupacken und poste die paar Zeilen.

Gute Idee, denn mit den wenigen Informationen, die wir haben, läßt sich das Problem nicht reproduzieren:

Code: Alles auswählen

root@gms1:~# cat x.cpp
#include <vector>
#include <string>
namespace liv {
  typedef std::vector<std::string> data;

  data myString;
}
int main() {
  liv::myString.push_back("bla");
  return 0;
}
root@gms1:~# g++-4.1 -o x x.cpp
root@gms1:~# ./x

Gruß
gms

[Corcovado]

Hae - kapier jetz gar nix mehr?!

gms == jogix,

Ein Multiaccount? kann man dadurch jetz gleichzeitig mehr beantworten oder mehr Fragen stellen??? Ausserdem das Demo geht doch?

Was ich auch nicht ganz verstehe - weil vorher jemand meinte, der gcc haette nun einen Debugger drinnen? Wie ist das eig. zu verstehen, ich dachte dafuer gibt's den gdb? Setzt man nicht deshalb auch diese -Wall Flags, damit man das hernach mit gdb leichter debuggen kann?

PS: vllt hat jemand nen Link dazu, weil das wohl auch etwas dieses Thema sprengt. Danke.

[jogix]

gms =/= jogix

ok, ich schiebe Euch morgen mal ein gestripptes Codefragment hier rein.... bin jetzt zu müde und war den ganzen Nachmittag / Abend unterwegs.

Corcovado: der GCC hat natürlich keinen Debugger integriert. Der neue GCC ist eben sehr strikt und motzt über viele Kleinigkeiten, die vorher ohne murren geschluckt wurden. Dadurch können eben sehr viele Runtime-Errors eliminiert werden, für die vorher ein Debugger notwendig gewesen wäre. Es lebe sauberer Code! Eureka!

BTW, -Wall als Option bedeutet nur, daß alle Warnungen ausgegeben werden. Zum Debuggen mußt den den Debugger-Switch umlegen: -g

Und der alte GCC hat eben keine Warnung ausgegeben. Ich lege eigentlich immer sehr viel Wert darauf, daß mein Code ohne Warnungen durchläuft, und zwar bei eingeschlatetem -Wall

Ah, wo ich gerade das Codefragment von gms nochmal überdenke..... ich habe bei Herrn Google noch eine weitere Anregung gefunden, die scheinbar zu Problemen in gewissen Konfigurationen führen kann. Wenn Mehrfach-Includes bestehen, kann bei diversen Konstrukten eben ein Fehler herauskommen, wie ich ihn (zumindest ähnlich) habe. Ich glaube, ich muß morgen mit sehr viel Zeit und Ruhe das ganze nochmal tiefer untersuchen... sorry, heute fehlte mir die Zeit und jetzt bin ich zu müde.

[gms]

Ausserdem das Demo geht doch?

ja, das geht. Darum habe ich ja auch geschrieben "läßt sich das Problem nicht reproduzieren"

gms == jogix,

Ein Multiaccount?

wodurch wurdest du den so arg verwirrt ?
nein, das Codeschnipsel habe ich selbst erstellt, ganz ohne Hexerei

weil vorher jemand meinte, der gcc haette nun einen Debugger drinnen? Wie ist das eig. zu verstehen, ich dachte dafuer gibt's den gdb?

das wurde behauptet:

Der gcc 4.1 ist nicht mehr so fehlertolerant wie die vorhergehenden Versionen, man kann schon behaupten, daß ein Debugger eingearbeitet ist.

aber behaupten kann man ja viel Die angesprochene "Fehlertolerants" bezieht sich anscheinend auf dem Compiliervorgang und hat daher mit dem Debuggen überhaupt nichts zu tun.

Ich habe bei Herrn Google noch eine weitere Anregung gefunden, die scheinbar zu Problemen in gewissen Konfigurationen führen kann. Wenn Mehrfach-Includes bestehen, kann bei diversen Konstrukten eben ein Fehler herauskommen

kannst du bitte diesen Link posten, das interessiert mich auch

Gruß
gms

[crazyed]

Die angesprochene "Fehlertoleranz" bezieht sich anscheinend auf dem Compiliervorgang und hat, wenn man von der Qualitätsverbesserung und der damit verbundenen Reduktion von Laufzeitfehlern absieht, überhaupt nichts mit dem Debugvorgang zu tun.

Genau so hab ich es gemeint, war wohl eine missverständliche Ausdrucksweise von mir...
Was bei den 3er gcc als Warnung kam ist bei dem 4er ein Fehler und führt zum Abbruch des Übersetzungsvorgangs. Damit spart man viel Zeit die man sonst mit gdb verbringen würde. Und man muss sauberen Code schreiben, was auch gut ist (ich zeige dabei jetzt auf mich... )

[gms]

Ausserdem das Demo geht doch?

ja, das geht. Darum habe ich ja auch geschrieben "läßt sich das Problem nicht reproduzieren"

gms == jogix,

Ein Multiaccount?

wodurch wurdest du den so arg verwirrt ?
nein, das Codeschnipsel habe ich selbst erstellt, ganz ohne Hexerei

weil vorher jemand meinte, der gcc haette nun einen Debugger drinnen? Wie ist das eig. zu verstehen, ich dachte dafuer gibt's den gdb?

das wurde behauptet:

Der gcc 4.1 ist nicht mehr so fehlertolerant wie die vorhergehenden Versionen, man kann schon behaupten, daß ein Debugger eingearbeitet ist.

aber behaupten kann man ja viel Die angesprochene "Fehlertoleranz" bezieht sich anscheinend auf dem Compiliervorgang und hat, wenn man von der Qualitätsverbesserung und der damit verbundenen Reduktion von Laufzeitfehlern absieht, überhaupt nichts mit dem Debugvorgang zu tun.

Ich habe bei Herrn Google noch eine weitere Anregung gefunden, die scheinbar zu Problemen in gewissen Konfigurationen führen kann. Wenn Mehrfach-Includes bestehen, kann bei diversen Konstrukten eben ein Fehler herauskommen

kannst du bitte diesen Link posten, das interessiert mich auch

Gruß
gms

[jogix]

Ich habe bei Herrn Google noch eine weitere Anregung gefunden, die scheinbar zu Problemen in gewissen Konfigurationen führen kann. Wenn Mehrfach-Includes bestehen, kann bei diversen Konstrukten eben ein Fehler herauskommen

kannst du bitte diesen Link posten, das interessiert mich auch

Hell, ich suche schon die ganze Zeit und finde es nicht mehr....

Also, ich habe das ganze nochmal durchleuchtet. Ich schätze, das Problem liegt in den verschachtelten Includes. Leider kann ich das grad nicht weiter nachlesen, aber die Suche geht noch weiter. Das muß doch irgendwo auffindbar sein.....

Da frage ich mich nur, weshalb ich dann diese

Code: Alles auswählen

#ifndef HEADERFILE_H
#define HEADERFILE_H

//...

#endif

überall einbaue, wenn er dann doch Probleme mit Mehrfachincludes hat

[Corcovado]

@gms
Eieiei, nja es war schon etwas spaet gestern, ich dachte... , sry (peinlich!!!).

@Crazyed
Nja, so Warnungen sollte man aber i.d.R. auch nicht einfach ignorieren (kommt halt auf das "Trash-Niveau" Deines Codes, bzw auf dessen Qualitaet an). Wenn man sich da nicht drum kuemmert laeuft man automatisch Gefahr entweder sehr Compilierspezifischen Code zu produzieren oder das die Situationen, vor denen eben gewarnt wird auch eintreten.
Compilerfehler helfen zwar beim debuggen, aber ein Debugger leistet weitaus mehr, er hilft Dir v.a. Fehler zu finden in einem sog. Debugmodus, der Compiler dagegen bietet eher Moeglichkeiten den Code noch effektiver zu kompilieren. Natuerlich kann man auch einfach Debugging Code verwenden und das alles mitm Compilier durchkauen und nur im aeussersten Notfall auf den direkten Debugger zurueck greifen, aber das kommt drauf an, wie komplex eben der Bug ist. Imo lohnt es sich auf alle Faelle sich beim programmieren mal mit dem benutzten Tools auseinander setzen. Was man vllt noch erwaehnen sollte waeren Profiler zum nachmessen und effektivieren des Codes: messen statt glauben. Sie sind nicht zwingend notwendig, aber Fallen, bei denen sich der Speicher nach und nach fuellt oder das auffinden des sog. Flaschenhalses, der ein komplettes Prg abbremst sind imo nur damit moeglich.

@jogix
Benutzt Du denn immer den gleichen include Waechter? Ich denke auch dazu liesse sich ein reproduzierbares Fehler Bsp schnell schreiben, mir ist Dein Fehler immer unklarer - koennte aber wirklich interessant sein.
Hab ich das richtig verstanden, Du machst da an ner Library rum - fuer welches Prg is denn das, hoffentlich was fuer KDE??!!!

[jogix]

Hi Leute.

Sorry für das späte Feedback.... ich hatte einfach keine Zeit, mich der Sache anzunehmen

Ich bin jetzt File für File durchgegangen, jedes einzelne läßt sich fehler- und warnungsfrei compilieren. Sobald ich die eine neue Klasse hinzufüge, die zwar auf vorhandene zurückgreift, aber sonst noch nicht weiter eingebunden ist, bekomme ich die Fehler wie oben beschrieben.

Zumindest weiß ich jetzt grob, woher die Probleme kommen und kann mich dem ganzen annehmen. Das Projekt befindet sich noch im Entwicklungsstadium und diese Klasse ist letzlich auch noch ganz neu und ohne viel Funktionalität. Mit dem jetztigen Wissen komme ich weiter, wenn mir auch bis dato noch die genauen Internas des Problems ein wenig schleierhaft sind.