C Hassen...

net 0

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

Erhard Henkes

..

DrGreenthumb

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.

Erhard Henkes

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

Swordfish

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

THX 1138

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.

.filmor

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.

Blue-Tiger

.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

.filmor

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

THX 1138

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

Artchi

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

Artchi

#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?

net 0

1310-Logik schrieb:

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

und der gewinner ist eine skriptsprache. aber wir wussten's ja schon immer: compilersprachen taugen einfach nix

minhen

Artchi schrieb:

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

#include <string> 
#include <iostream> 

class ganz_unsicher { 
    public:
        ganz_unsicher() : dummy(2006), passwort("geheim") {}
    private: 
        int dummy; 
        std::string passwort; 
}; 

int main() {
	ganz_unsicher gleich_passierts; 
	int *boesewicht1 = (int*)&gleich_passierts;
	std::string *boesewicht2 = reinterpret_cast<std::string*>(&gleich_passierts) + 1;
	std::cout << *boesewicht1 << " und " << *boesewicht2 << std::endl; 
}

So viel dazu. Diesmal auch ohne hässlichem c_str()

.filmor

Und was machst du, wenn dir noch jemand eine vtable davor pflanzt?

#include <string> 
#include <iostream> 

class ganz_unsicher { 
    public:
        ganz_unsicher() : dummy(2006), passwort("geheim") {}
        virtual ganz_unsicher () {}
    private: 
        int dummy; 
        std::string passwort; 
};

Übrigens klappt deine Methode nur, falls sizeof (int) == sizeof (std::string) ist!

int main ()
{
    ganz_unsicher gleich_passierts;
    int* boesewicht1 = reinterpret_cast<int*> (&gleich_passierts);
    std::string* boesewicht2 = reinterpret_cast<std::string*> (boesewicht1 + 1);
    std::cout << *boesewicht1 << " und " << *boesewicht2 << std::endl;
}

So ists portabler

minhen

.filmor schrieb:

Übrigens klappt deine Methode nur, falls sizeof (int) == sizeof (std::string) ist!

Nein, leider falsch geraten.
Versuch es mal bei einem 64-Bit-System. Da siehst du sehr schnell, dass (zumindest beim GCC) int nach wie vor 32 Bit hat, während Zeiger 64 Bit haben. Damit ist sizeof(std::string) 8, während sizeof(int) 4 bleibt.
Die Methode funktioniert dennoch (ich hab hier schließlich ein 64-Bit-System). Und sie klappt, weil Zeiger immer die selbe Größe haben. Und das ist hier, worauf es ankommt!
Deswegen ist dein "Verbesserungsversuch" auch kein deut portabler. boesewicht1 ist schließlich ein Zeiger und kein int. Und wie gesagt, sizeof(int*) == sizeof(std::string) == sizeof(std::string*) == (bei dir) 4 == (bei mir) 8.
Deine Variante ist also im Grunde die selbe wie meine - nur dass boesewicht2 bei mir auch direkt abgefragt werden kann, während du es von boesewicht1 abhängig machst.

Artchi

1310-Logik schrieb:

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

Also das Python für textmanipulationen sehr beliebt ist, ist mir bekannt. Hört und liest man ja immer wieder.

Die Frage ist nur: welcher Compiler wurde eingesetzt? Steht nur gcc, aber nicht welche Version. Dann noch: hat jemand schon mal einen Versuch mit dem Intel C++ Compiler für Linux ausprobiert? Würde mich interessieren.

THX 1138

Nein, für Intel C++ ists fehlerhaft. Aber du kannst ja einen schreiben, die Bedingungen sind ja gegeben
http://shootout.alioth.debian.org/debian/benchmark.php?test=regexdna&lang=icpp

btw: g++ (GCC) 4.1.2 20060729 (prerelease) (Debian 4.1.1-10)

Artchi

Hem, fragt sich jetzt nur, wer schuld ist? Der Intel Compiler oder der Implementierer des Tests?

Würde gerne einen Test mit Boost Regex und Intel C++ Compiler sehen. Naja... falls jemand sowas hat, einfach melden.

THX 1138

Dürfte es nicht schwierig sein Intel C++ auf ner AMD CPU zu testen?
Hier die Fehlermeldung, entscheide selbst, wer schuld hat:

/opt/intel/cc/9.0/bin/icpc -c -O3 -ip -static -unroll regexdna.c++ -o regexdna.c++.o && \
/opt/intel/cc/9.0/bin/icpc regexdna.c++.o -o regexdna.icpp_run -O3 -ip -static -unroll
Command-line error: invalid GNU version number: 412

compilation aborted for regexdna.c++ (code 4)
make[3]: [regexdna.icpp_run] Error 4 (ignored)
rm: cannot remove regexdna.c++.o': No such file or directory rm: cannot removeregexdna.o': No such file or directory
make[3]: [regexdna.icpp_run] Error 1 (ignored)