3. C Hassen...

C Hassen...


  • .filmor schrieb:

    Ich mach mich direkt dran, eine bessere zu schreiben

    Ich bin schon richtig gespannt 😉

    Greetz, Swordfish

    0
  • ?

    .filmor schrieb:

    Optimizer schrieb:

    .filmor schrieb:

    Optimizer schrieb:

    Das interface ist doch gerade das schlimmste. length() und size() ist hirnrissig

    Ist es nicht. Sobald du einen Multibytestring implementierst ist das sinnvoll.

    Red nicht: http://cppreference.com/cppstring/length.html
    Das ist einfach nur doppelt gemoppelt, weil length() schöner klingt und size() gibt es, damit das Container-Interface erfüllt ist. Das ist halt gutes Design. size() darf nichts anderes als length() zurückgeben.

    Für den hypothetischen Fall, dass jemand einen Multibytestring implementiert (und std::string ist definitiv keiner) kann er length für die Anzahl der Zeichen und size für die Anzahl an gespeicherten chars oder ints oder was auch immer nehmen.

    Das darfst du aber nicht, wenn du dich an den Standard halten willst. So wie es definiert ist (size() == length()), ist es Teil eines unschönen Interface und daran kann man erstmal nichts ändern.

    Optimizer schrieb:

    boost::lexical_cast macht genau das fricklige, was ich beschrieben habe. Überhaupt nicht geil und überhaupt nicht performant. Aber gut, dass wir kurzzeitig mal nicht über die Standardbibliothek gesprochen haben. Lass uns zum Thema zurückkehren, schließlich hat hier keiner bezweifelt, dass es möglich ist, für C++ gute Libs zu schreiben.

    Wenn du es performant haben willst, dann nimm halt C. Hast du überhaupt Belege dafür, das die stringstreams so unglaublich lahm sind? Ich hatte bisher noch keine Probleme damit. Außerdem ist das wiederum stark implementierungsabhängig.

    Du instanzierst halt einen Stream und schmeißt ihn wieder weg, nimmst vorher den string raus und weist den Wert dem eigentlich Zielobjekt zu (wahrscheinlich eine Kopie, weil man könnte ja den extrahierten String auch noch verwenden wollen). Damit hast du
    - einen temporären Stream
    - einen temporären String
    - eine Zuweisung von temp an myString, die wahrscheinlich ne Kopie des Inhalts ist
    (das macht mindestens zwei buffer im Heap allokiert für nix und wieder nix)

    Da ist das Konzept schon so ungünstig, dass der Compiler nicht mehr alles rausreißen kann. Vergleich mal, was wäre wenn der String das einfach anhängen könnte. Er würde seinen internen Buffer, falls nötig, vergrößeren und die chars für die Zahl reinschreiben.

    Was zum Henker hat denn Formatierung mit strings zu tun?! Im Prinzip ist das sogar nur Aufgabe der Ausgabeoperationen (wo es ja auch drin ist, eben die Streams).

    Das ist ein Trugschluss, Formatierung hat erstmal gar nichts mit I/O zu tun. Die Formatierung in die Streams zu setzen halte ich für einen Fehler, da die auch benutzt werden, um binär zu schreiben. Eine strikte Trennung dieser beiden Sachen ist ein besseres Design.

    Dazu muss man mal sehen, dass man in einer echten Welt verschiedene Encodings braucht. Es ist reichlich bedenklich, das einfach so in das Stream I/O reinzupacken. Ein schönerer Ansatz ist, erstmal ne Stream I/O nur für bytes bereitzustellen und eine Lib für verschiedene Text-Sachen, dazu gehört dann String, meinetwegen eine Format-Klasse und ein TextWriter, der Strings unter Angabe eines bestimmten Encodings als bytes in einen bestimmten Stream schreibt. Und dann sieht man auch sofort, dass Formatierung eine Text-Sache ist und keine I/O-Sache. Ein Stream kann doch gar nicht wissen, welche Bytes er bei welchem Text jetzt schreiben soll, da muss vorher eine Umwandlung (Kodierung genannt) stattfinden und das genau das mit Standardmitteln nicht einstellbar ist, deckt den ganzen Design-Fehler auf.

    EDIT: Davon abgesehen reicht dir doch die Ausgabe-Formatierung gar nicht. Wie willst du denn so formatierten Text in eine Excel-Tabelle bringen? Achja richtig... in nen stringstream schreiben und wieder nen string rausgetten...

    Optimizer schrieb:

    Das geht mit einem so vermurkstem Konzept natürlich nicht, schon klar. Wie es meiner Meinung nach aussehen soll? Strings integriert man am besten auf Sprachebene wie in C# und Java. Da kannst du hundert + hinschreiben und der Compiler macht einen StringBuilder variabler Länge mit append() für jedes + draus und am Ende holt er den String, macht immer 2 Objekte.

    Wenn Strings fest in der Sprache eingebaut sind, dann sind sie doch noch unflexibler, als wenn sie als Klasse implementiert sind?!

    Ja, man ist insofern unflexibler, als das alle die selbe String-Klasse fast verwenden müssen. 😉 Wo siehst du Nachteile? Du hast ja auch Strings in C++ eingebaut - aber C-Strings.

    0
  • A

    size() von basic_string ist nur deshalb drin, falls man diesen als Container behandelt. Container haben nunmal size() als Funktion um die Elementanzahl abzufragen. Behandelt man basic_string nicht als Container, ist length() fachlich gesehen logischer.

    0
  • E

    Verstehe das Problem nicht so recht?

    time_t t = time(NULL);
string str(ctime(&t));
cout << str << endl;

    Gute Idee, aber nicht so schnell! 🙂
    ... denn schon motzt MSVC++ 2005:

    warning C4996: 'ctime' was declared deprecated
    Consider using ctime_s instead.

    Verwendet man ctime_s, das völlig anders aufgebaut ist, so hat man als ersten Parameter char* buffer.

    Das gilt auch, wenn man es mit _strtime_s(...) versucht.

    Von time_t und NULL will ich erst gar nicht anfangen. 😉

    Man ist selbst bei Neuerungen ständig umzingelt von char*. Daher benötigt C++ diesbezüglich unbedingt einen Neuanfang, oder man akzeptiert das char-Array und den Zeiger char* als die Repräsentation eines Strings auch in C++.

    0
  • A

    Ja, MSVC8.0 meint es gut, aber ctime ist ISO-konform und ctime_s von MS im Alleingang eingeführt um C-Funktionen sicherer zu machen. Oder sind die Dinger mittlerweile ISO-C?

    It should be noted that in this context, "deprecated" just means that a function's use is not recommended; it does not indicate that the function is scheduled to be removed from the CRT.

    Du kannst die Deprecated Warnings ausschalten, mit _CRT_SECURE_NO_DEPRECATE .
    http://msdn2.microsoft.com/en-us/library/8ef0s5kh.aspx

    Man ist selbst bei Neuerungen ständig umzingelt von char*. Daher benötigt C++ diesbezüglich unbedingt einen Neuanfang, oder man akzeptiert das char-Array und den Zeiger char* als die Repräsentation eines Strings auch in C++.

    Dann hast du meine letzten Postings nicht richtig gelesen... für dich nochmal:
    http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1981.html

    0
  • N

    Erhard Henkes schrieb:

    warning C4996: 'ctime' was declared deprecated
    Consider using ctime_s instead.

    ctime ist eigentlich harmlos, da braucht der m$ compiler nicht zu meckern. es ist nur nicht so richtig multithreading tauglich

    Artchi schrieb:

    Ja, MSVC8.0 meint es gut, aber ctime ist ISO-konform und ctime_s von MS im Alleingang eingeführt um C-Funktionen sicherer zu machen. Oder sind die Dinger mittlerweile ISO-C?

    also mickrichweich hat die 'safer c library', oder wie das heisst, glaube ich, nicht erfunden. watcom z.b. hat die auch...

    0
  • E

    Dann hast du meine letzten Postings nicht richtig gelesen...

    Doch habe ich. Ich wollte nur zeigen, dass man sich drehen und wenden kann, wie man will, von irgendeiner Seite wird man immer "angemacht". 😉

    Dann hast du meine letzten Postings nicht richtig gelesen... für dich nochmal:
    http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1981.html

    Danke für den Link.

    0
  • E

    ... und ctime_s von MS im Alleingang eingeführt um C-Funktionen sicherer zu machen.

    Diese Dinger geben dem immer noch üblichen C/C++-Mix jetzt wirklich den Rest. 😃

    0
  • N

    Erhard Henkes schrieb:

    Diese Dinger geben dem immer noch üblichen C/C++-Mix jetzt wirklich den Rest. 😃

    die sind ja eigentlich für 'c' gedacht. c++ user haben doch ihren stl/boost mischmasch und brauchen sowas nicht 😉

    0
  • E

    ..

    0
  • D

    Erhard Henkes schrieb:

    Wie man mit Zeigern und C-casts Blödsinn treiben kann, zeigt dieses berühmte Beispiel:

    // [ c++ objekt nach string gecastet ]

    Mit std::string gelingt dies nicht. 👍

    Das Beispiel zeigt, wie man in C/++ direkten Zugriff auf den Speicher hat.
    std::string schützt da überhaupt gar nicht.

    0
  • E

    Dann bastel dieses Beispiel mal mit std::string nach. Mir ist es nicht gelungen.

    0

  • Erhard Henkes schrieb:

    Dann bastel dieses Beispiel mal mit std::string nach. Mir ist es nicht gelungen.

    da hast du:

    #include <string>
#include <iostream>

class ganz_unsicher {

    public:

        ganz_unsicher( ) : passwort( "geheim" ) { }

    private:

        std::string passwort;
};

int main()
{
    ganz_unsicher gleich_passierts;
    std::string *boesewicht = reinterpret_cast< std::string* >( &gleich_passierts );
    std::cout << boesewicht->c_str( ) << std::endl;
}

    Greetz, Swordfish

    0
  • T

    Es stimmt schon, als ich anfing C zu lernen ( Erste Seite Tutorial, die Typen ) dachte ich erst: "Oh mein Gott, es gibt keine Strings, nur Zeichen?" Die Erleichterung kam aber mit C++ und std::string.
    Aber trotzdem ist die Sache nicht so doll. Bin wohl etwas verwöhnt, aber die string Funktionalität von Python ist um längen besser. Gerade wenn man lange Zeichenketten durchsuchen, bearbeiten, teilen und umkehren will. Da schlägt Python C und C++ auch in Punkto Effizienz.

    0
  • .

    1310-Logik schrieb:

    Gerade wenn man lange Zeichenketten durchsuchen, bearbeiten, teilen und umkehren will. Da schlägt Python C und C++ auch in Punkto Effizienz.

    Das wage ich zu bezweifeln. Mir ist schon bewusst, dass die Stringangelegenheiten in Python stark optimiert werden, dennoch glaube ich nicht, dass Python schneller ist. Mit sowas wie Psyco oder IronPython kann es ja von mir aus auf Augenhöhe sein, aber effizienter kann ich mir nicht vorstellen.
    Vielleicht meintest du ja etwas anderes, dann führe doch bitte "Effizienz" näher aus.

    0
  • B

    .filmor schrieb:

    1310-Logik schrieb:

    Gerade wenn man lange Zeichenketten durchsuchen, bearbeiten, teilen und umkehren will. Da schlägt Python C und C++ auch in Punkto Effizienz.

    Das wage ich zu bezweifeln. Mir ist schon bewusst, dass die Stringangelegenheiten in Python stark optimiert werden, dennoch glaube ich nicht, dass Python schneller ist. Mit sowas wie Psyco oder IronPython kann es ja von mir aus auf Augenhöhe sein, aber effizienter kann ich mir nicht vorstellen.
    Vielleicht meintest du ja etwas anderes, dann führe doch bitte "Effizienz" näher aus.

    Muss ja nicht gleich "Laufzeiteffizienz" (1310-Logik hat ja nicht von "Schnelligkeit" geredet) sein. Es ist einfach ein Unterschied ob ich einfach so Regex, Unicode, umfangreiche String-Bibliothek (mit Slicing etc.) direkt bei der Sprache dabei hab, oder ob ich dazu erstmal 2-3 verschiedene Bibliotheken suchen muss, die evtl. auch noch andere Code-Styles verwenden und vielleicht nicht mal auf allen Plattformen zur Verfuegung stehen 😉

    0
  • .

    Naja, ich denke das Thema, dass du Standardbibliothek da zu schmal ist haben wir bereits durch ...
    Python verfolgt dahingehend auch eine andere Philosophie.

    0
  • T

    Doch Laufzeiteffizienz --> weniger CPU time meinte ich
    aber auch Entwicklungszeit --> weniger Code Zeilen
    Regex-DNA Benchmark

    diff program output for this 100KB input file (generated with the fasta program N = 10000) with this output file to check your program is correct before contributing.

    We use FASTA files generated by the fasta benchmark as input for this benchmark. Note: the file may include both lowercase and uppercase codes.

    Each program should

    * read all of a redirected FASTA format file from stdin, and record the sequence length
    * use the same simple regex pattern match-replace to remove FASTA sequence descriptions and all linefeed characters, and record the sequence length
    * use the same simple regex patterns, representing DNA 8-mers and their reverse complement (with a wildcard in one position), and (one pattern at a time) count matches in the redirected file
    * write the regex pattern and count
    * use the same simple regex patterns to make IUB code alternatives explicit, and (one pattern at a time) match-replace the pattern in the redirect file, and record the sequence length
    * write the 3 recorded sequence lengths

    Revised BSD license

    C++ mag mithalten, C auf gcc hat ein Timeout bekommen, tja..

    edit: ja es ist ein gesuchtes Beispiel, da das einzige. Aber ist nunmal mein Hauptanwendungsbereich gewesen, mit den BLAST FASTA etc. rumzuwerkeln

    0
  • A

    Stringmanipulationen sind im ISO-C++ 2003 dürftig, stimmt. Aber bzgl. Regex hat ISO-C++ seit April 2006 kein Defizit mehr, siehe TR1.

    Wer noch mehr Stringmanipultionen benötigt, muß vorerst auf Boost zurück greifen. Halte das aber nicht für schlimm, da Boost einfach auf jede Festplatte eines C++-Entwicklers gehört.
    http://www.boost.org/libs/libraries.htm#String

    0
  • A
     

    #include <string> 
#include <iostream> 

class ganz_unsicher { 

    public: 

        ganz_unsicher( ) : passwort( "geheim" ) { } 

    private: 
        int dummy;
        std::string passwort; 
}; 

int main() 
{ 
    ganz_unsicher gleich_passierts; 
    std::string *boesewicht = reinterpret_cast< std::string* >( &gleich_passierts ); 
    std::cout << boesewicht->c_str( ) << std::endl; 
}

    Schon gehts nicht mehr bzw. seh ich nur noch quatsch zur Laufzeit!

    Also, wenn ich will, kann ich in C++ sowieso vieles machen. Aber wenn das Passwort sooo geheim wäre, würde ich es auch nur verschlüsselt ablegen. 😉 Was sollen diese Beispiele? Wir wissen hier doch alle, das man mit böswilliger Absicht schlimme Dinge erreichen kann. Ich denke nicht, das wir hier jetzt ein "Oh oh!" Erlebnis hatten, oder?

    0
Anmelden zum Antworten