Mehr Spaß in der Console

[7xCore]

Sarkasmus oder nicht, das ist hier die Frage

[rapso]

in klammern mit smiley ist sarkasmus, das andere, naja, ich dachte das endet hier in flames, aber du sagst du wirst es einfach verbessern, was gut ist.

hab schon miterlebt, dass kolegen sagten, dass sie ihren style nicht an die firmen guidelines anpassen und eher kuendigen als sich dazu zwingen zu lassen

[freaky]

rapso schrieb:

hab schon miterlebt, dass kolegen sagten, dass sie ihren style nicht an die firmen guidelines anpassen und eher kuendigen als sich dazu zwingen zu lassen

Wenn es Standardkonvention ist, wie z.B. bei C# wo wirklich alles einheitlich aussieht (zumindest im .NET Framework) und es von Haus aus Richtlinien gibt, welche die Firma missachtet und lieber ihre eigenen macht, ich aber seit Jahren die Standardkonvention nehme, würde ich darüber auch nachdenken. Das heißt nicht, dass ich nicht flexibel bin, aber ich würde es aus reinem Prinzip nicht machen wollen. Bei einem einzigen größerem Projekt, bei welchem man einen anderen Stil annimmt, hätte ich nichts dagegen, jedoch nicht dauerhaft. Aber wirklich kündigen, würde ich erst, wenn ich eine neue Stelle sicher haben würde.

[rapso]

ich wuerde das genau andersrum sehen, von projekt zu projekt wuerde ich keine unterschiedlichen guidlines haben wollen innerhalb einer firma, wenn jedoch die firma einhetliche coding guidelines hat, wuerde ich die annehmen. (und mache ich auch jedesmal).
Der sinn ist ja, dass alles einheitlich aussieht, damit somit jeder mit dem code von jedem anderen arbeiten kann. es duerte extrem selten sein, dass alle 20 programmierer genau dieselben guidelines moegen.

ich wuerde ein framework auch nicht als referenz fuer guidelines nehmen, eine firma sollte intern festlegen was gut ist und nicht von aussen absorbieren. Nur weil ein framework fuer irgendwas existiert, ist es noch lange nicht gut oder universal.

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. hat nur partiell was mit style zu tun, aber ich wollte jetzt kein beispiel bringen das einen religionsstreit anfangen wuerde

ich wuerde beim festlegen von guidelines vermutlich auch nicht irgendwelche regeln festsetzen, sondern ein paar guidelines von anderen firmen nehmen, und die die ihre entscheidungen am ueberzeugendesten rueberbringen (und sowas sollte immer teil der guidelines sein, nicht nur 'wie' sondern auch 'warum, wie es z.B. in effective c++ usw. steht), wuerde ich dann uebernehmen.

[cooky451]

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

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? Und wie willste den String dann beschreiben? Sorry aber das hört sich für mich nach ziemlich großem Mist an.

[kingcools]

Habs mir mal aus Interesse an dem "wie" angeschaut^^
Die Rauten sind ziemlich unnötig. Dann schreib dir doch lieber nach oben Kommentare mit Notizen was du ändern musst(quasi eine to-do liste).

[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:

1. 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.

2. 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