Mehr Spaß in der Console

rapso

cooky451 schrieb:

rapso schrieb:

hat nur partiell was mit style zu tun, aber ich wollte jetzt kein beispiel bringen das einen religionsstreit anfangen wuerde

Tja, nicht geschafft. :p

gibt immer 'special ppl'

rapso schrieb:

fuer c++ gibt es z.B. die STL und ich wuerde die heutzutage nicht als referenz nehmen, alleine schon dass man mit c_str() auf eigentlich gekapselte daten zugreifen kann und es schon oft eine fehlerquelle war, wuerde ich z.b. verbieten sowas zu machen und firmen intern eine von std::string abgeleitete klasse als ersatz vorschreiben, die die daten auf sichere art bereitstellt.

Hä? operator [] gibt auch eine Referenz zurück, willst du das auch verhindern?

nein, wie sollte ich und wozu?vector auf array kopieren bringt keinen unterschied.

Und wie willste den String dann beschreiben?

welches genie beschreibt denn einen string indem er auf c_str() zugreift? aber das ist noch ein grund c_str().

Sorry aber das hört sich für mich nach ziemlich großem Mist an.

nicht wirklich murks, die verwendung von c_str ist einfach nur bequaemlichkeit die auch bei erfahrenen programmierern zu fehlern fuehrt. gibt es c_str nicht, schreiben die leute den code so um, dass er auch ohne funktioniert. den raw string braucht man bestenfalls wenn man aus seinem eigenen code raus callt (z.b. stdio oder sowas).

ein beispiel

const char* name = (File+".tga").c_str();
sprintf(FullPath,"texturen/%s",name);
return fopen(FullPath);

j: looks legit
s: does not look legit
p: not legit, but will work

cooky451

Die Frage ist eher welche Genie .c_str() bei sowas aufruft. oO

rapso

cooky451 schrieb:

Die Frage ist eher welche Genie .c_str() bei sowas aufruft. oO

muss eines dieser sein die c_str nutzt um auf strings zu schreiben

[edit]

void getBuiltInVariableInfo(const TType& type,
                            const TString& name,
                            const TString& mappedName,
                            TVariableInfoList& infoList)
{
    ASSERT(type.getBasicType() != EbtStruct);

    TVariableInfo varInfo;
    if (type.isArray()) {
        varInfo.name = (name + "[0]").c_str();//legit?
        varInfo.mappedName = (mappedName + "[0]").c_str();//legit?
        varInfo.size = type.getArraySize();
    } else {
        varInfo.name = name.c_str();
        varInfo.mappedName = mappedName.c_str();
        varInfo.size = 1;
    }
    varInfo.type = getVariableDataType(type);
    infoList.push_back(varInfo);
}

lastest fire fox

cooky451

rapso schrieb:

cooky451 schrieb:

Die Frage ist eher welche Genie .c_str() bei sowas aufruft. oO

muss eines dieser sein die c_str nutzt um auf strings zu schreiben

lol, die Frage bezog sich natürlich auf operator [] und nicht auf c_str.
Zum Beispiel: Ja, das ist ziemlich übel. Trotzdem ändert sich doch nichts, wenn c_str weg ist nutzen sie halt &(..)[0].

rapso

cooky451 schrieb:

Zum Beispiel: Ja, das ist ziemlich übel. Trotzdem ändert sich doch nichts, wenn c_str weg ist nutzen sie halt &(..)[0].

operator[] zeigt nicht zwingen auf einen zero terminated string.
ich habe ehrlich gesagt aber auch noch nie diesen operator beim string verwendet und seh sowas auch nie im code, wenn man auf dem string arbeitet kommt man ohne eigentlich aus.

einzelne chars aendern

std::transform(Str.begin(),Str.end(),Str.begin(),tolower);

tokenizen

std::string::size_type Start	=	0;
std::string::size_type SSize	=	Separator.size();
for(;(Pt = Tokens.find(Separator,Start))!=std::string::npos;Start = Pt + SSize)
	Ret.push_back(Tokens.substr(Start,Pt-Start));
Ret.push_back(Tokens.substr(Start));

wuesten nicht, wann man zwingen [] braucht.

cooky451

Dann nimmste halt &*s.begin(), fakt bleibt, dass du den Zugriff eh erteilen musst. Daran kommst du nicht vorbei, es wäre anders auch nicht sinnvoll und da macht c_str() dann auch keinen Unterschied mehr. Wer Pointer vorher nicht verstanden hat, hat sie auch nachher nicht verstanden. Ne Schulung von 30 Minuten wäre da sinnvoller.

DocShoe

#include <cstring>
#include <vector>

using namespace std;
int main()
{
   vector<char> vec; 
   vec[0] = 47;           // UB, also wird std::vector verboten

   double source = 17.4;
   float target;

   memcpy( &target, &source, sizeof( source ) );

   // noch besser: float, double, memcpy und sizeof verbieten, weil
   // sie UB erzeugen
}

Sieht gut aus, wird anstandslos übersetzt und läuft manchmal sogar durch. C++ ist nun mal eine Sprache, mit der man sich in den Fuß schießen kann und sich dabei das ganze Bein abreißt. Wie man jetzt einen ungültigen Speicherzugriff erzeugt spielt keine Rolle, man sollte schon immer wissen, was man macht. Und wenn so eine kreuzblöde Richtlinie verbietet, std::string zu benutzten, weil man über c_str() den Inhalt beschreiben kann, dann sollte man kein C/C++ verwenden, weil man über Pointer so ziemlich alles kaputtschreiben kann.

Hier im Forum gab´s mal eine kurze Diskussion, ob man Binärdaten in einem std::string ablegen darf. Der TE hat nach kurzer Diskussion auf einen EA (Chef!-)Programmierer verwiesen, der ausdrücklich davor gewarnt hat, weil strlen( c_str() ) möglicherweise eine falsche Länge zurückgibt. Wer nicht mit seinem Werkezeug umgehen kann, dem helfen auch keine Richtlinien.

rapso

gegen absichtliche dummheit hilft keine style guide.

aber ich weiss nicht, was es bringen soll, von einer potentiellen fehlerquelle zu behaupten sie werde nie einen fehler verursachen und mit einem polemischen honk beispielen dagegen halten. really? dieses niveau nun?

es gibt aus gutem grund buecher wie effective c++ usw. in denen viel maginalerere dinge als 'guter coding style' gelehrt werden, z.b. statt

if(foo==2)

dass man

if(2==foo)

schreibt, natuerlich kann auch dagegen jeder mit nem honk beispiel kommen. wer schliesslich weiss wie sich c_str verhaelt und wie man damit umgeht, wird alle mal nicht == mit = verwerchseln.
und man braucht c++ cast operatoren auch nicht, denn mit c style casts geht auch alles und auch hier kann man behaupten, ein faehiger programmierer wird hier nie einen fehler machen. dennoch empfehlen viele buecher (z.b. more effective c++), dass man die c++ variante verwenden sollte.

ich denke, einmal einen fehler zu machen kann passieren, nichts dagegen zu tun und ihn zu wiederholen, obwohl es einfach waere, ist dummheit. wenn ich von erfahrenen programmierern lese welche fehler sie begingen und wie sie diesen vorsorgen, hab ich persoenlich den ergeiz die qualitaet meines sources auch auf das niveau anzuheben. "c_str is evil" (und 1min googlen zeigt diese fehler in FireFox und Chrome), "macros are evil, use const+functions", konstanten zuerste im compare zu schreiben, c++ casts, sind nicht aus meinem hirn entsprungen. ich folge diesen nur weil andere schrieben wie sie aus ihren fehlern damit lernten.
ich wege nicht ab niemals mehr memset/memcpy zu nutzen, aber ich sehe potentielle fehlerquellen die static code analyser zeigen, z.b. PVS, und verbesser meinen code entsprechend, sprich: wenn memcpy etc. nicht noetig ist, weil eine zuweisung dasselbe macht, waehle ich 100mal lieber die zuweisung.
(wenn es primitive types sind und memcpy valid ist, wird gcc einen memcpy aufruf generieren!)

DocShoe

c_str ist vermutlich implementiert worden, um Kompatibilität mit C zu gewährleisten, also für den Fall, wo man C und C++ mischen muss. Wenn man bei C++ bleibt benötigt man die Funktion wahrscheinlich nie bis selten. Ich stelle einfach mal die gewagte Behauptung auf, dass es zwei Programmierertypen gibt, die damit in Kontakt kommen:

programmiert C mit Klassen. Stellt fest, dass die STL einige nützliche Dinge bietet und vermischt C und C++. Hier möchte ich nicht ausschließen, dass er auch strcpy o.Ä. auf c_str anwendet. Allerdings bewegt sich dieser Programmierer C++ mäßig auf einem Niveau, wo es andere größere Baustellen gibt.
der erfahren C++ Programmierer, der Legacy C Code pflegen/bedienen muss und sich darüber im Klaren ist, dass c_str für den Brückenschlag zwischen C und C++ notwendig ist.

Aus beiden Fällen sehe ich keine Notwendigkeit, c_str grundsätzlich abzulehnen.

PS:
Der Vergleich zwischen C und C++ casts hinkt gewaltig.

PPS:
Natürlich gebe ich dir recht, dass eine API möglichst wenig Fehlerquellen besitzen sollte. Aber Flexibilität hat eben ihren Preis.

Ulli

DocShoe schrieb:

(...) man sollte schon immer wissen, was man macht. (...)

Nach meiner Meinung bringt es dieser unscheinbare, halb versteckte Nebensatz auf den Punkt.

/Ulli