3. C Hassen...

C Hassen...

  • M

    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() 😉

    0
  • .

    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 😉

    0
  • M

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

    0
  • A

    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.

    0
  • T

    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)

    0
  • A

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

    0
  • T

    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)

    0
  • A

    Nein, warum sollte es ein Prob sein? Der AMD ist ja kompatibel zum Intel-Prozessor, oder nicht? Wäre ja witzlos, wenn Intel Compiler nur für Intel CPU funktionierenden Code erzeugen würden, weil dann müssten viele Spielefirmen zwei Versionen ihrer Spiele ausliefern. Außerdem geht das offiziell auch für AMD CPUs. Egal... zur Fehlermeldung:

    Command-line error: invalid GNU version number: 412

    Soll heißen er stört sich daran, das es kein GNU Compiler ist?

    Hab erst gedacht es wäre ein Laufzeitfehler. Wenn natürlich nicht mal das Kompilieren klappt...

    0
  • T

    Keine Ahnung, versteh nicht soviel von Linux-Compilern.
    Das ganze lief unter Debian. Aber bei keinem der Benchmarks funktionierte der Intel C++.
    Weis jetzt auch ned, ob der dann wirklich schneller wär, is ja der selbe Code, und ob der so viel besser optimieren kann?

    0
  • A

    Der Intel kann auf jeden Fall mit am besten optimieren, das zeigen viele Vergleichstests in entsprechenden Magazinen. Der VC++ ist schon sehr gut (hat damals immer den GCC 3.x ausgestochen), aber Intel legt ne Schippe nach. Also denke ich mal, macht er das auch mit einem GCC 4.x, sonst kann Intel seinen Compiler streichen.

    Es gibt ja noch schnellere, wie Pathscale, kosten aber viel mehr Geld.

    Gut, also es besteht noch die Möglichkeit das C++ mit einem anderen (besseren) Compiler den Python-Benchmark überholt. Nichts gegen GCC, weiß auch nicht wie gut der aktuelle ist, weiß nur das der GCC 3.x gegen VC++6 immer verloren hat. Und VC++ gegen den Intel.

    0
Anmelden zum Antworten