|
|
|
|
|
|
|
Ich finde cplusplus.com furchtbar 
unique_ptr
Sorgt dafür, dass das Objekt immer nur aus einem Scope heraus referenziert
wird (sole ownership).
Wenn das Objekt nicht mehr referenziert wird, weil der unqiue_ptr seinen Scope
verlässt, ohne den Pointer an einen anderen unique_ptr zu übergeben,
wird es gelöscht.
shared_ptr
Implementiert shared ownership durch reference counting, es wird also gezählt,
wieviele shared_ptr den gleichen Pointer wrappen. Wenn ein shared_ptr seinen
Scope verlässt (~shared_ptr), wird geprüft, ob der Referenzzähler 0 ist und wenn
dem so ist, das Objekt gelöscht.
Stolperfalle: Man darf nicht einfach neue shared_ptr erzeugen, indem man einen
bereits gewrappten Pointer in shared_ptr stopft, man muss den Copyconstructor
oder = benutzten.
weak_ptr
Schwache Referenz, die selbst kein Objekt verwaltet, sondern den Zugriff auf
ein von shared_ptr gemanagedes Objekt ermöglicht, wobei das, wie bei schwachen
Referenzen nunmal üblich, zwischenzeitlich auch verschwunden sein kann.
Also quasi eine shared_ptr Implementierung ohne eine Erhöhung des Referenz-
zählers.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 26.07.2013 13:15]
|
|
|
|
|
|
|
|
|
|
weiß wer, wo man so Lichtwellenleiterdinge einkauft, die also mehr in Richtung Labor+Lasergebrauch gehen als für Telko?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich finde cplusplus.com auch ziemlich gelungen. Gefaellt mir deutlich besser als cppreference.com
|
|
|
|
|
|
|
|
|
|
|
Bei cplusplus.com stören mich die oft ein wenig an den Haaren herbeigezogenen
Beispiele, außerdem gibt's keine Beispiele für ganze Klassen, sondern meist nur
für nen paar Member.
Die Navigation finde ich dort weniger gut als bei cppreference.com.
Dafür haben die ein Forum, wo es öfter ganz gute Antworten gibt. Daher
einfach Geschmackssache, inhaltlich sind beide vermutlich auf dem selben Stand.
Wo wir gerade dabei sind ein schamloser Crosspost:
Wenn ich in C viele exakt vier Zeichen lange Strings vergleichen möchte
und das möglichst schnell, so könnte man auf die Idee kommen den String als
32-Bit Integer zu interpretieren und einfach Integervergleiche zu machen.
In der konkreten Implementierung funktioniert das super und reduziert die
Gesamtlaufzeit des Programms um etwa 40 %.
(Das wurde mit cachegrind Ir ermittelt, was in meinem Fall deterministisch ist.
Soweit ich das. Ir ist die Anzahl der ausgeführten Instruktionen.)
Jetzt bin ich mir aber nicht sicher, ob das überhaupt portabel ist.
-Erstmal das Speicherlayout, dass ist aber portabel. Die vier Zeichen liegen direkt
hintereinander im Speicher, das sollte überall so sein.
-Endianness? Sollte eigentlich keine Rolle spielen, da die Zeichen immer in
der gleichen Reihenfolge im Speicher liegen und Integerkonstanten, auch Hexdec,
in die native Endianness konvertiert werden. Oder?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 26.07.2013 15:21]
|
|
|
|
|
|
|
|
|
Wenn es dir nur darum geht, ob die Strings gleich sind, kann es dir doch egal sein, ob die Integerdarstellung sich unterscheidet. Sie unterscheidet sich ja für jeden String gleich.
Ich versteh nicht warum dich der spezielle Wert des Integers überhaupt interessiert. Dich sollte doch nur der Vergleichswert aus zwei Integern interessieren!? 
|
|
|
|
|
|
|
|
|
|
|
Ich vergleiche nicht zwei Strings, sondern einen variablen String mit einer
Konstante. Daher das Problem mit der Integerdarstellung...
(e: Ich idiot. Ich kann natürlich einfach die konstanten als Strings ablegen
und auf Integer casten. Dann sollte es portabel sein.
Kleines Makro dazu:
#define INTSTRING(s) reinterpret_cast<const uint32_t*>(s)[0]
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von csde_rats am 26.07.2013 15:39]
|
|
|
|
|
|
|
|
|
Womit hast du Strings verglichen, was so viel schlechter performt? Strcmp oder memcmp?
¤: Und ja, prinzipiell sollte das passen. Die Probleme damit siehst du wahrscheinlich auch selbst, wenn z.B. einer der Strings plötzlich länger ist aber die ersten 4 Zeichen gleich.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 26.07.2013 15:39]
|
|
|
|
|
|
|
|
|
strncmp, Länge von Hand eingetragen. Danach memcmp probiert, aber das war
nur unwesentlich schneller. memcmp ist ja letzlich nur strncmp minus zwei strlen.
Das Hauptproblem dürfte schon der Call-Overhead gewesen sein.
Das ist ein Parser für .desktop-Dateien, der auf meinem System etwa ~600 Dateien
beackert mit um die 100000 Zeilen. Für jede Zeile innerhalb eines aktiven Blocks
(es wird alles irrelevant außerhalb einer bestimmten Sektion ignoriert, die meisten
Dateien bestehen aber größenteils aus dieser bestimmten Sektion) müssen bis zu
sieben Vergleiche gemacht werden.
Die aktuelle Version mit dem Integer-Hack braucht da nur noch ~17 ms für.
Ein Problem mit einem gemeinsamen Präfix >= 4 Zeichen gibt es bisher nicht,
da die gültigen Schlüssel für [Desktop Entry] keine solche Überschneidung
aufweisen, insb. nicht in den behandelten Werten.
Sollte das mal passieren, wäre es trivial auf 64-Bit aufzurüsten, da muss ein
gemeinsames Präfix schon 8 Zeichen lang sein.
Warum nicht gleich 64-Bit? Weil es einen Schlüssel gibt, dessen lokalisierter
Wert mich interessiert (Name heißt der, genau 4 Zeichen). Wenn ich also die ersten
vier Byte des Schlüssels mit Name vergleiche und die Aussage wahr ist, erwische
ich ohne weiteres Hickhack alle lokalisierten Werte, die dann auf Übereinstimmung
mit den Locale-Einstellungen untersucht werden können.
http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html
Ein kleines Puzzlestück fehlt mir aber noch. Bitte mal die C/C++ Experten vortreten!
Oben postete ich folgendes Makro:
#define INTSTRING(s) reinterpret_cast<const uint32_t*>(s)[0]
Für ein constexpr s ist das Makro allerdings nicht constexpr, wie dieser Test zeigt:
% cat t.cc
#define INTSTRING(s) reinterpret_cast<const int*>(s)[0]
constexpr int x = INTSTRING("1234");
% g++ -std=c++0x t.cc
t.cc:1:55: error: accessing value of ‘"1234"’ through a ‘const int’ glvalue in a constant expression
#define INTSTRING(s) reinterpret_cast<const int*>(s)[0]
^
t.cc:3:19: note: in expansion of macro ‘INTSTRING’
constexpr int x = INTSTRING("1234");
Um das ganze in einem switch-Statement zu benutzen, benötige ich aber zwingend
einen Wert, der constexpr erfüllt.
Jemand eine Idee?
(Nicht zwingend, um das produktiv einzusetzen, aber einfach um es mal gemacht
zu haben...)
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von csde_rats am 26.07.2013 16:00]
|
|
|
|
|
|
|
|
|
Passt, auch wenn halt fugly. Muss auch mal sein.
¤: Und du meinst wohl eher "warum nicht gleich 64 bit".
¤: Und damit kann ich nicht helfen, C++ ist dunkles Voodoo.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von SwissBushIndian am 26.07.2013 16:07]
|
|
|
|
|
|
|
|
|
Danke.
Kennst du dich da ein bisschen aus? Ich hab ne Laseröhre, die ne FC-Kupplung hat und ein Spektrometereingang mit SMA-Eingang und leider nur SMA-Fasern. Gibt's da Adapter um an ne FC-Kupplung ne SMA-Faser anzuschließen? Ich hab bisher nur welche gefunden, um ne SMA-Faser und ne FC-Faser zu kuppeln...
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SwissBushIndian
Passt, auch wenn halt fugly. Muss auch mal sein.
¤: Und du meinst wohl eher "warum nicht gleich 64 bit".
¤: Und damit kann ich nicht helfen, C++ ist dunkles Voodoo.
| |
Das ist nicht so wirklich C++ (ich bin mit der constexpr-Bitshifterei aber wieder in der Endianness-Hölle gelandet, glaube ich)
http://pastebin.com/JkKebeRu
Ich schwöre, ich schreibe das irgendwann nochmal komplett in reinem C neu! 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 26.07.2013 16:18]
|
|
|
|
|
|
|
|
|
|
Hübsch
|
|
|
|
|
|
|
|
|
|
|
Hab ich gerade auf tdwtf geklickt? 
|
|
|
|
|
|
|
|
|
|
|
|
Das passiert wenn man irgendwas ganz hässliches parsen darf. Du kennst ja noch meinen Bitfield Hack um Zahlen auseinanderzupflücken?
|
|
|
|
|
|
|
|
|
|
|
Jep.
War jetzt nichtmal direkt negativ auf den Code bezogen. Ich behaupte sogar, dass wenn man hässliche Dinge mit C/C++ parst der Code die Schönheit des Input-Files annimmt. Aber etwas erschrocken hab ich mich beim Klick auf den Quellcode doch. 
|
|
|
|
|
|
|
|
|
|
|
Ist ein schön gewachsener Hack, nich?
CMake ist echt nice.
INCLUDE(TestBigEndian)
TEST_BIG_ENDIAN(BIGENDIAN)
IF(${BIGENDIAN})
ADD_DEFINITIONS(-DBIGENDIAN)
ENDIF(${BIGENDIAN})
=>
#ifdef BIGENDIAN
// Untested
#define INTSTRING(d, c, b, a) (static_cast<uint32_t>((a) | (b) << 8 | (c) << 16 | (d) << 24))
#else
#define INTSTRING(a, b, c, d) (static_cast<uint32_t>((a) | (b) << 8 | (c) << 16 | (d) << 24))
#endif
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 26.07.2013 16:40]
|
|
|
|
|
|
|
|
|
Absolut grausam, könnte von mir sein.
|
|
|
|
|
|
|
|
|
|
Kleine Runde "grausamste eigene hacks"? :)
|
Irgendwann in Prog 1 kam mal eine Aufgabe nen Integer ivalue von Hand binär auszugeben. (Ich glaube das habe ich schon damals hier gepostet)
for(j=sizeof(int)*8-1;j>=0;j--) printf("%i" (ivalue&(1<<j))>>j);
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von csde_rats am 26.07.2013 16:43]
|
|
|
|
|
|
|
|
|
Da gibt's einige ganz schlimme, einer der mich kürzlich vom schlafen abgehalten hat ist sowas:
| |
| Code: |
typedef struct {
unsigned char b1 : 1;
unsigned char b2 : 1;
unsigned char b3 : 1;
unsigned char b4 : 1;
unsigned char b5 : 1;
unsigned char b6 : 1;
unsigned char b7 : 1;
unsigned char b8 : 1;
} byte; |
|
in Kombination mit:
| |
| Code: |
byte* b = (byte*)# |
|
Den Rest kann man sich wohl denken...
¤: Was aber noch eigentlich viel schlimmer ist: Irgendwo an meiner alten Stelle geistert noch eine gegenseitig-referenzierende MySQL Datenbank rum, die durch Trigger und dann mit Kaskadierung korrekt bleibt. Hammermässig schlimm, aber funktioniert seit Jahr und Tag...
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 26.07.2013 16:51]
|
|
|
|
|
|
|
|
|
|
Der is richtig gut!
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Irgendwann in Prog 1 kam mal eine Aufgabe nen Integer ivalue von Hand binär auszugeben. (Ich glaube das habe ich schon damals hier gepostet)
for(j=sizeof(int)*8-1;j>=0;j--) printf("%i" (ivalue&(1<<j))>>j);
| |
Das hässliche hier ist doch eigentlich nur, dass du eine komplette For-Schleife in eine Zeile schreibst. Ansonsten find ich das eigentlich recht schlüssig.
... oder bin ich solch Zeug mittlerweile einfach gewohnt? :/
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von wuSel
... oder bin ich solch Zeug mittlerweile einfach gewohnt? :/
| |
Du pfeifst dir mein Zeug zu viel rein
¤: Und überhaupt, mir ist das noch nicht hässlich genug:
| |
| Code: |
for(j=sizeof(int)*8-1;j>=0;printf("%i" (ivalue&(1<<j))>>j--)) ;
|
|
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 26.07.2013 17:13]
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Um das ganze in einem switch-Statement zu benutzen, benötige ich aber zwingend
einen Wert, der constexpr erfüllt.
Jemand eine Idee?
(Nicht zwingend, um das produktiv einzusetzen, aber einfach um es mal gemacht
zu haben...)
| |
Ich bin nicht sicher in wie weit das passt: http://dev.krzaq.cc/switch-on-strings-with-c11/
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Admiral Bohm
| | Zitat von csde_rats
Um das ganze in einem switch-Statement zu benutzen, benötige ich aber zwingend
einen Wert, der constexpr erfüllt.
Jemand eine Idee?
(Nicht zwingend, um das produktiv einzusetzen, aber einfach um es mal gemacht
zu haben...)
| |
Ich bin nicht sicher in wie weit das passt: http://dev.krzaq.cc/switch-on-strings-with-c11/
| |
Ah, Mithilfe von eigenen Suffixen lässt sich das eleganter schreiben:
constexpr uint32_t operator "" _istr(char const* p, size_t)
{
#ifdef BIGENDIAN
return p[3] | p[2] << 8 | p[1] << 16 | p[0] << 24;
#else
return p[0] | p[1] << 8 | p[2] << 16 | p[3] << 24;
#endif
}
switch... {
case "Name"_istr:
...
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von RichterSkala
Danke.
Kennst du dich da ein bisschen aus? Ich hab ne Laseröhre, die ne FC-Kupplung hat und ein Spektrometereingang mit SMA-Eingang und leider nur SMA-Fasern. Gibt's da Adapter um an ne FC-Kupplung ne SMA-Faser anzuschließen? Ich hab bisher nur welche gefunden, um ne SMA-Faser und ne FC-Faser zu kuppeln...
| |
Ich bin da leider überhaupt kein Spezialist, ich hab bisher Fasern an Spektrometer angeschlossen und nicht mehr. Ich wusste nur wo man das bekommt 
|
|
|
|
|
|
|
|
|
|
|
Hmmmm, der GCC erzeugt hier ganz komischen Code.
Nach meinem Verständnis sind diese Formulierungen nahezu äquivalent:
for(apps_t::iterator it = apps.begin(); it != apps.end(); ++it)
keys.push_back(it->first.c_str());
for(auto app : apps)
keys.push_back(app.first.c_str());
Dennoch erzeugt der GCC hier Code, der exakt 1632 mal öfter new/new[]/malloc
aufruft als ersterer. Es befinden sich in apps 272 Elemente, ergo führt der
Code der Range-based Loop exakt sechs Speicheranforderungen und -freigaben pro
Element durch.
Soweit klar, liegt wahrscheinlich daran, dass app by-value übergeben wird.
for(auto& app : apps)
keys.push_back(app.first.c_str());
=> genauso viele allocs wie die Iterator-Lösung.
Mich würde jetzt nur mal schwer interessieren, woher er bei einem
std:: pair<> sechs Allocs hernimmt?
So spare ich auch nochmal ordentlich Zyklen, MM ist bekanntermaßen nicht umsonst.
Cachegrind sagt mir, dass ich durch dieses Ampersand in meinem
repräsentativen Testfall™ von 17,4 Mio Irefs auf 16,6 Mio Irefs runter bin.
———
Was wäre denn so der effizienteste weg eine Datei zeilenweise zu lesen?
Ich habe bisher fgets benutzt.
Dann habe ich getline ausprobiert, und zwar in dem Betriebsmodus, wo *lineptr
NULL ist und *n ignoriert wird. Ergo beschafft getline den Puffer, was irgendwie
schneller geht als das was fgets da treibt (im callgrind sehe ich innerhalb von
fgets viel Zeit für memcpy).
Relative Perfomance der beiden: fgets=22, getline=20.4
Da ich aber die Werte, die ich später (lies: zwischen den Aufrufen von getline)
eh wegkopiere, ist mir eigentlich egal was mit dem Buffer passiert, ergo
bräuchte ich nichtmal einen eigenen Buffer wie ihn getline einrichtet.
Gibt's da vielleicht was, womit ich ohne "eigenen" Buffer auskomme?
Denn wenn ich mir den Zeitverbrauch anschaue, dann sehe ich immernoch in getline
einen großen Block memcpy...
...den eigentlichen I/O scheint getline mittels mmap abzuwickeln(?)
Im Callgrind sehe ich innerhalb von getline exakt 380 mmap-Calls, wobei das
Programm darüber eben genau 380 Dateien liest.
Oder müsste ich mir das selber mit mmap basteln?
Edit:
Gerade eben eine std::map<> gegen einen POD ausgetauscht, das war dann wohl
die effizienteste Optimierung bisher.
6'500 Allocs weniger, halbes MB RAM gespart, 5 Mio Irefs weniger...
für den repräsentativen Fall™ also 1800 Allocs, 900 kB RAM und 12 Mio Irefs.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von csde_rats am 28.07.2013 15:05]
|
|
|
|
|
|
|
|
Computer-Forensik
|
Tach, hat hier jemand Erfahrung mit toten USB-Sticks?
Habe einen Stick eines Bekannten hier (mit Firmendaten, Belehrung bekam er schon). Habe bisher nur versucht, ob der Stick überhaupt noch irgendwie erkannt wird, aber meine Bash sagt nach lsusb nicht, dass sie etwas finden würde.
Im Prinzip ist der Stick schon abgeschrieben mitsamt Daten, aber ich hab jetzt Bock mich damit zu beschäftigen bis zu dem Punkt ihn eventuell zu öffnen und gucken, ob man die Chips auslöten und in einen gleichwertigen Stick einlöten kann. Ja ich weiss, die Chancen sind klein - aber was hab ich zu verlieren?
Hat das schonmal jemand gemacht?
|
|
|
|
|
|
|
|
|
|
|
Ola Folks, ich bin grade in einem Vorbereitungskurs der die wichtigen Fächer und ihre Themen aus der früheren Schulzeit auffrischen soll.
Mal davon abgesehen das ich da 10 Jahre raus bin, geht es grade um Brüche, die als solches zwar eigentlich keine "Gefahr" darstellen, aber sobald auch nur zwei Variablen im Spiel sind, setzt es bei völlig mir aus. 
Diese Aufgaben zB bring ich einfach nicht mehr hin...
Multiplizieren bzw Dividieren Sie die folgenden Bruchterme:
p0T to the rescue im to dump for this.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Underboss am 28.07.2013 19:26]
|
|
|
|
|
|
|
|
|
Hi, Tipps.
1. Brüche multiplizieren heißt, Zähler mit Zähler und Nenner mit Nenner multiplizieren
2. Brüche dividieren heißt, mit dem Kehrwert zu mutliplizieren. D.h. 
3. Ein Term ohne Nenner hat quasi eine 1 im Nenner stehen 
Mit den drei Sachen solltest du weiter kommen´.
|
|
|
|
|
|
|
|
| Thema: pOT-lnformatik, Mathematik, Physik XIII ( Completely Automated Public User Test To tell PIMP ) |
