Sehr freakig, hut ab. :D:A
Druckbare Version
Sehr freakig, hut ab. :D:A
Hab noch ein bisschen damit rumgespielt und muss sagen, es ist richtig cool. Lege ich jedem ans Herz, der ein bisschen Ahnung von OpenGL und eine Webcam hat.
Btw: Muss ich mir Gedanken machen, wenn mich Luki bittet, eine RPG Maker 2003 Map für ihn zu bearbeiten und ich einen Hexeditor nehme, statt den passenden Maker zu installieren?
Ähnliches, hervorgerufen durch copy & paste, ist mir vor kurzem in einem größeren Programm mit Dateioperationen passiert. Glücklicherweise aber schnell entdeckt. :|
Mein C ist nicht so wirklich gut, aber lese ich richtig das "&Buffer" das Problem ist? Weil es ist ja ein Pointer und soZitat:
Ähnliches, hervorgerufen durch copy & paste, ist mir vor kurzem in einem größeren Programm mit Dateioperationen passiert. Glücklicherweise aber schnell entdeckt. :|
calloc() macht doch das selbe, was du gemacht hast.
Naja, solange du den Speicher nicht genullt brauchst, ist calloc() halt unnötiger Mehraufwand. Andernfalls ist's aber echt eine gute Frage. ^^" Gewohnheit wohl, und die Tatsache, dass es meist nicht viel Unterschied macht, performanztechnisch.
@ Whiz: Er hat ja geschrieben, "Ähnliches", ist im Original also vielleicht eh sinnvoller, bzw. nicht der Punkt.
Ich denke, das hat wohl was damit zu tun, dass C für Unix gedacht war und Unix generell den Speicher mit Nullen belegt. Da macht es keinen Unterschied, ob malloc() oder calloc(). Nur unter Windows muss man da höllisch aufpassen. Auch wenn man den Speicher nicht genullt braucht, würde ich es dennoch machen. Schaden kann es nicht.
Daß malloc() den Speicher nullt ist auch unter Unix nicht garantiert. Die meisten oder alle neueren Unixe machen es zwar so, aber garantiert ist es absolut nicht.
Naja, der Zeitbedarf ist doch recht minimal, sodass man ihn schon quasi vernachlässigen kann.
Der Zeitunterschied zwischen den beiden Funktionen, bei 1.000.000 Blöcken a 1 MB Plus Freigeben des Speichers liegt, bei meinem Rechner, bei 124 ms.
Ich besitze einen Intel C2D E6600 (2x 2,4 Ghz) und 2 GB RAM.
Da gibt es eigentlich kein Optimierungspotenzial.
hab jetzt mal alle Programme geschlossen und mein Testprogramm durchlaufen lassen.
nun liegt der Unterschied sogar bei nur 47 ms.
Zitat:
1000000 mal 1048576 Bytes reservieren und freigeben
Zeit von malloc: 35047 ms
Zeit von calloc: 35000 ms
Zeitunterschied: 47 ms
Ja, richtig. Die interessantere Frage ist aber nicht wo die Ursache ist, sondern was genau dabei passiert. Da es eine lokale Variable auf dem Call Stack ist, wird dieser überschrieben und damit alle im Stack folgenden Rücksprungadressen, Funktionsparameter, etc. Kurz gesagt, Katastrophe. In diesem Fall ist es sogar noch schlimmer, da ohne Debugger das Programm an der Stelle der früher oder später resultierenden Zugriffsverletzung still beendet ("bla bla" wird nicht ausgegeben), ohne auf das Fehlverhalten mit einer entsprechenden Ausnahmebehandlung zu reagieren.
Ursprünglich war es wie erwähnt eine Dateioperation, fread um genau zu sein. memset sollte wirklich nur dem Vorführungszweck dienen.
Da würden dir die C-Entwickler vermutlich etwas anderes sagen. Redundanz im Zeichen der Fehlerreduzierung entspricht zum Beispiel nicht der C-Philosophie.
Die Frage, ob man auf malloc verzichten sollte erinnert mich an die Frage, ob man auf goto verzichten sollte. Hierzu:
Besonders in C hat goto einen festen Platz und vereinfacht oft den Code, wie zum Beispiel in der Ausnahmebehandlung. Ähnlich verhält es sich mit malloc und calloc. Beide haben Vor- und Nachteile, die je nach Situation andere Gewichtung haben können. Verdammen ist ist in meinen Augen nie gut und schädlicher als fragliche Anwendung.Zitat:
In computer science:
1st years don't use goto
2nd years use goto in assembly language
3rd years use goto when goto is needed.
Ohne Code sind diese Resultate nicht wirklich repräsentativ. Man kann auf eine Weise messen und auf eine andere mit jeweils völlig unterschiedlichen Ergebnissen. Entscheidend wären beispielsweise, Granularität, Mittelwertbildung mehrerer Messwerte um Abweichungen durch Interrupts und ähnliches zu minimieren, Reduzierung auf die Messung der tatsächlichen Arbeit (free ist ein Störfaktor), usw.
Ich habe mal einige Messungen auf meinem Pentium D 2.8 Ghz gemacht und bei mir braucht malloc für 1 MB im Schnitt (10 Messungen hintereinander) etwa 12500 clock cycles (entspricht etwa 4.46 us bei 2.8 Ghz) und calloc etwa 13500 clock cycles (etwa 4.82 us). Damit ist calloc um 8% langsamer als malloc. Nicht viel, aber viel hat man hier auch nicht erwartet, denn Nullsetzung ist sehr billig und in heutigen Zeiten in der Regel SIMD-optimiert. Natürlich erhebe ich keinen Anspruch, dass auch meine Messungen 100%-ig repräsentativ und fehlerfrei sind. Jedenfalls gibt es einen Unterschied, der in manchen Situationen sogar größer sein kann und damit eventuell abgewogen werden könnte, wie zum Beispiel auf Systemen ohne SIMD, wenigen und kleinen Caches etc.
Stellt sich die Frage, ob du auch noch sprintf() benutzt. Das ist ja bekanntermaßen eine gute Möglichkeit, unkontrolliert Speicher zu überschreiben und viele empfehlen, stattdessen snprintf() (bei C99-fähigen Compilern) oder asprintf() (bei GNU GCC) zu verwenden. Zugegeben, die sind vermutlich beide langsamer, aber solange man nicht per (semi-)formellem Beweis nachweisen will, daß der Puffer nicht überlaufen kann, stellen sie auch Schutz vor einem potentiellen Sicherheitsrisiko dar.
Hängt von den Softwarekriterien ab.
Also gut, ich verwende eigentlich automatisch schon snprintf() (auch wenn ich praktisch nie C programmiere), aber teilweise würde ich sehr wohl auch sprintf() für gerechtfertigt halten. Z.B. wenn man nur Integers in einen String schreibt – länger als 11/20 Stellen (je nach Größe) können die ja nicht werden. Genauso wenn man bei allen Wildcards auch die Maximallänge angibt (bei Strings halt – floats sind wohl echt problematisch).
"Verdammen" wäre da vielleicht auch falsch, selbst wenn es allgemein auch kaum schaden wird, einfach immer die sichereren Varianten zu benutzen.
Interessant wird's dann aber, wenn man in weiser Voraussicht den String auf 11 Stellen dimensioniert hat, weil der Code ja eh nur auf 32bittigen Plattformen zum Einsatz kommt. Und dann kommt plötzlich eine source-kompatible 64bittige Version der Plattform raus oder jemand portiert den Code.
Das ist (sicherheitstechnisch) das Blöde bei C: Die einzige Sicherheit, die du hast, ist die, die du einbaust. Das ist ein Grund, lieber defensiv zu programmieren als die letzten 0,1% Leistung rauszukitzeln.
Wie gesagt, am Ende kommt es immer auf die Anforderungen der Software an, die man programmiert. Es ist genauso falsch an den falschen Stellen zu optimieren, wie auch zu optimistisch, oder zu pessimistisch zu programmieren. Hundertprozentige Sicherheit gibt es sowieso nie.
Doch, gibt es. Sie nennt sich "EAL7-Zertifizierung". Gut, dafür mußt du sämtliche Software und IIRC auch Teile der Hardware formell verifizieren und testen. Aber dann kannst du dir absolut sicher sein, daß jegliche Fehler Hardwaredefekte und nicht Implementierungsfehler sind.
Okay, als Normalsterblicher wirst du nicht mit EAL7-Kram arbeiten. Aber du solltest schon wissen, wann du wo welche Risiken eingehen kannst. Ich würde mir wohl nicht die Mühe machen, bei jedem Befüllen eines Strings abzuwägen, ob es theoretisch möglich ist, den String mit zu vielen Daten zu befüllen – nicht, wenn es Funktionen gibt, die diese Mühe überflüssig machen.
Man kann's natürlich übertreiben, aber solange der Performanceverlust durch Verwendung von sprintf()-Alternativen nicht zu groß ist, würde ich sie grundsätzlich verwenden. Und das dürfte außerhalb von synthetischen Benchmarks immer der Fall sein.
Die CC ist auch keine Silberkugel und unangreifbar. Du kannst dich an absolute Sicherheit annähern, sie aber nie erreichen. Mit jedem erreichten EAL kannst du deine Software als "sicherer", oder als "zur Zeit sicher gegen dies und das" bezeichnen, aber nie als "sicher". Die Hardware spielt IMO auch eine entscheidende Rolle bei der Frage nach der Sicherheit eines Systems. Übrigens habe ich mal irgendwo gelesen, dass EAL7 für Low Level-Implementation nur semi-formelle Spezifikation fordert, so dass es keinen mathematischen Beweis gibt, dass die Low Level-Spezifikation der Implementation entspricht. Dass EAL7 nur für sehr spezielle Systeme mit sehr speziellen Sicherheitsfunktionen überhaupt praktikabel ist, da der Aufwand und die daraus resultierenden Kosten enorm sind, ist bekannt. Naja, ich bleibe dabei, dass absolute Sicherheit - und ich meine absolut - nicht möglich ist. Ich meine mich zudem zu erinnern gelesen zu haben, dass selbst bei der medizinischen Ausrüstung (und anderer Technik mit ähnlichen Sicherheitsstandards) nicht mit absoluter Fehlerfreiheit gerechnet wird und Todesfälle verursacht durch Fehler in diesen Geräten sowohl in Kauf genommen werden (wenn auch minimal), als auch schon vorgekommen sind.
Was sprintf angeht, überrascht es mich ein wenig, dass du nur die Performance, oder gerade die Performance in Betracht ziehst, da diese kaum bei der sprintf-Familie relevant sein kann. Ich kann mir jedenfalls nicht vorstellen aus welchem sinnvollen Grund sprintf und co. etwas in performancekritischen Bereichen zu suchen hätten. Vielmehr würde ich speziell bei snprintf/asprintf argumentieren, dass ihre Verwendung zusätzlichen Aufwand und damit Komplexität erzeugt in dem Fall, wenn man sich nicht auf einen Compiler beschränken möchte. MSVC ist zum Beispiel nicht C99-konform und hat keine snprintf-Implementation. Nun bietet MSVC zwar sein eigenes snprintf, nämlich _snprintf (was hätte man anderes erwartet), dieses ist aber semantisch von C99-snprintf verschieden -> Aufwand ist notwendig um hier Plattformunabhängigkeit zu erreichen. Man könnte argumentieren, dass dieser Aufwand relativ gering ist, es bleibt trotzdem Aufwand, der betrieben werden muss. IIRC ist das Trimmen von _snprintf auf C99-snprintf aus dem Grund der semantischen Unterschiede sogar nicht so effizient wie man es erwarten würde und würde im Worst Case viele Aufrufe erfordern, was vielleicht nicht wünschenswert ist. Wenn die Software klein genug ist und das Risiko, dass sprintf einen Überlauf verursacht gering ist und nur in Grenzfällen eintreten kann, wie etwa wie in deinem Beispiel mit der Portierung auf 64 Bit, kann man dieses durchaus in Kauf nehmen. Man kann auch mit größerem Buffer arbeiten, was absolut nicht unüblich ist. Ein Wechsel von sprintf zu snprintf/asprintf/_snprintf/etc. ist zu jedem Zeitpunkt immernoch möglich. Ich habe gelernt, dass vorzeitige Paranoia genauso schädlich ist, wie vorzeitige Optimierung und ähnliches Übel und Schritte in diese Richtungen erst gemacht werden sollten, wenn ein Anlass besteht. Es gibt natürlich Ausnahmen.
Im Übrigen bin ich alles andere als der Meinung, Performance geht über Stabilität und Sicherheit, falls (aus welchem Grund auch immer) bei irgendwem dieser Eindruck entstanden sein sollte. Um ehrlich zu sein, habe ich doch bis jetzt immer wieder auf eine oder andere Art betont, dass immer abgewogen werden sollte, je nach Situation und Anforderungen. Ich bin aber definitiv der Meinung, dass nicht vorschnell Dinge als impraktikabel erklärt werden sollten, allein aufgrund dessen, dass sie unter bestimmten Voraussetzungen unsicher sind. "sicher" erweckt meiner Meinung nach sowieso ein falsches Gefühl der Sicherheit, denn um überhaupt nur entfernt von Sicherheit zu reden ist weit mehr nötig, als nur calloc oder snprintf und co. zu verwenden. Davon abgesehen, dass calloc kaum als "sichere Variante von malloc" gedacht war, sondern vermutlich nur als "die bequeme Variante", im Fall, dass der erhaltene Speicher genullt sein muss. Im Fall von Gleitpunktzahlen und Zeigern ist calloc schonmal keine Silberkugel, denn alle Bits auf Null gesetzt, bedeutet nicht eine Gleitpunktzahl gleich Null, oder einen Nullzeiger, man hat also das gleiche Problem wie in deinem Beispiel mit sprintf und der Portierung auf 64 Bit.
C99 ist immer noch nicht flächendeckend implementiert? Oy vey; ich weiß schon, warum ich mich von lowlevel-Programmierung fern halte.
Ein kurzer Codeschnipsel, den ich mit euch teilen möchte:
Was macht das Ganze? Es ist sowas wie ein möglichst simpler Ersatz für eine Mailing List. Mit folgender Procmail Regel werden eingehende Mails an list@example.com an alle Adressen, die unter TO eingetragen sind, weitergeleitet und das Reply-To Feld so gesetzt, dass man bequem auf Antworten klicken kann.
Die Zeile mit dem Ausrufezeichen ist da, damit das Ganze keine Endlosschleife gibt. Wenn ihr nicht wollt, dass die Mails archiviert werden, fügt einfach noch eine weitere Regel hinzu, die alles, was Reply-to: list@example.com enthält, nach /dev/null schiebt.Code:#Mailverteiler
:0H
* !^Reply-to: list@example.com
* ^TO_list@example.com
| /home/person1/mailforward.sh
Noch einfacher wäre das Ganze, wenn man Sendmail beibringen könnte, das Bcc: Feld zu beachten, das To: Feld aber nicht. Leider gehen nur beide oder keins und für BCC scheint es keinen Kommandozeilenparameter zu geben.
Du kannst das ganze doch auch einfacher machen, und die Empfänger einfach als Argument zu sendmail übergeben, oder? o_O
Dann rewritest du vielleicht noch den Reply-To Header, damit die Menschen, die zu blöd sind, auf "Reply to all" zu klicken, trotzdem zu ihrem Glück kommen. Beim sendmail-Aufruf entfernst du das -t und machst hinten aus $SENDMAIL ein $SENDMAIL $TO (ich glaube, dann musst du die Kommata in $TO aber weglassen)
Der Punkt ist, die Leute sollen ja nicht allen einzeln antworten, sondern der Verteileradresse. Deshalb steht die im Reply-to Feld. Die einzelnen Empfänger stehen schon absichtlich in Bcc, nicht in To.
Mir ist die Funktionsweise einer Mailadresse durchaus klar. Wenn du sendmail die Empfänger auf der cmdline übergibst, schreibt dieses sie aber auch nicht ins To. Wenn aber die ursprüngliche Mail an list@domain.tld und außerdem noch person@example.com ging, obwohl person@example.com nicht in der Liste ist, sollte eine Antwort auf die Mail auch an person@example.com (und natürlich die Liste) gehen, oder? Daher sollte das ursprüngliche To nicht modifiziert werden.
Mich würde mal interessieren, ob jemand außer mir auch mit dem Problem zu kämpfen hat, gezwungen zu sein immer wieder den Code umzuschreiben, wenn einem ein treffenderer Name für eine Routine, eine bessere Namenskonvention, oder eine bessere Formulierung für einen Kommentar einfällt (von besseren Problemlösungsansätzen ganz zu schweigen...)? Oft ist es sogar so, dass ich immer wieder von einem Ansatz zum anderen wechsle, da zwar beide ausgewogene Vor- und Nachteile haben, die Vorteile des aktuell anderen Ansatzes aber immer zu überwiegen scheinen. Irgendwann schaffe ich es zwar, mich zusammenzureißen und einen Weg zu gehen, aber der Weg dahin ist mühsam. Das ist zum Kotzen, denn damit verbringe ich etwa 50% (wenn nicht mehr) der gesamten Zeit beim Programmieren. Das hat natürlich auch damit etwas zu tun, dass ich mir mein eigener Chef bin und aus dem Grund keine klaren Anweisungen habe, mich an etwas zu halten, aber ich denke, es hat auch einen nicht unwesentlichen Teil mit fehlender Erfahrung und Routine zu tun.
Oh Mann... ich bin so froh, wenn die Klausurenphase rum ist. Ich muss für morgen die Abschlusspräsentation von unserem Routenplanerprojekt fertig machen und bis Montag für die Betriebssysteme Klausur lernen. Naja, immerhin hat der Prof bei letzterem Humor:
Ich hab das Gefühl, dass der von mir hervorgehobene Punkt ein kleiner Seitenhieb auf Microsoft sein soll.Zitat:
Operating System Definition
- OS is a resource allocator
- Manages all resources
- Decides between conflicting requests for efficient and fair resource use
- OS is a control program
- Controls execution of programs to prevent errors and improper use of the computer
- Everything a vendor ships when you order an operating system
=> No universally accepted definition
Das ist bei mir normal Zustand.
Ich habe mein CMS schon tausend mal umgeschrieben ... vor kurzem habe ich mich z.B. mal einfach so dazu entschlossen es auf PHP-5.3 inkl. Namespaces umzustellen ... :p.
Und sogar auf der Arbeit ist es häufig so. "Das Modul ist scheiße das müssen wa mal neu machen" :D.
Ah, immerhin einer. :D Wobei bei mir es meistens eher Kleinigkeiten sind, was das Ganze noch ärgerlicher macht. ;)
Ich weiß nicht ob das wirklich so toll ist wie ich das denke, aber:
Ist das ein toller langer Befehl?
Was hier passiert ist dabei ziemlich einfach, für unseren vertikal Shooter haben wir die Gegner die in den einzelnen Level auftauchen in einen Array eines Arrays gepackt, der "obere" Array steht für das Level der "untere" für die Waves in denen die Gegner auftauchen.
Sprich ,die äußere Schleife kontrolliert die Nummer der Wave und die innere die Anzahl der Gegner der Wave.
Innen wird also nur der Gegner gezeichnet und für mich ist das schon ein ziemlich großer Schritt x_X
So, ich hab clang auf meinem Mac installiert. Irgendwie sind das viel angenehmere Fehlermeldungen, als mit dem gcc.
Muss er unbedingt die kompletten For-Schleifen durchlaufen?
Die Innere Schleife wird ja nur dann ausgeführt, wenn die Bedingung waveStart.get(i) < distance && waveStop.get(i) > distance erfüllt ist.
Wenn die Bedingung einmal nicht erfüllt wurde, kann sie dann nochmal erfüllt werden?
Wenn nein, würde ich eine While-Schleife nehmen oder sogar den Teil zu einer Rekursion umbauen.
Achso ja, das dient als Abstand zwischen den einzelnen Waves.
Geht das bei Vektoren? enemy ist nämlich ein Vektor (Ja ich hab array geschrieben .____.)
Naja, es können doch auch mal mehrere Waves auf dem Screen sein.
Evtl. wird das aber nochmal interessant wenn es um finishing geht, bisher werden da maximal 100 Elemente drin sein.
Ich habe mich da komisch ausgedrückt als ich erst sagte das der obere Array für das Level steht und dann das der obere für die welle steht xD Sry...
Es ist jedenfalls so dass das erste for die Wellen durchgeht. Wenn die Welle sichtbar ist dann werden die Gegner in der Welle gezeichnet^^ (also die am Leben sind und die im Bildschirm sind, daher das If.
Edit:
Ich muss nochmal drauf hinweisen, das der Code des Spiels nicht 100% von mir ist, die meiste Arbeit übernimmt mein Partner der so ein Java-Guru ist und durch den ich erst so schnell Java gelernt hab. Tolle Sprache irgendwie, mal sehen wie C++ ist.
Klar geht das, warum nicht?
enemy.get(i) und vllt. sogar enemy.get(i).size() ebenfalls zwischenzuspeichern könnte sich auch noch auszahlen. Auf jeden Fall macht das das Programm nicht nur schneller, sondern auch deutlich lesbarer – und der Codeblock sprengt bei mir nicht mehr das Design. XD
Schlechter. :DZitat:
Tolle Sprache irgendwie, mal sehen wie C++ ist.
*duck, wegrenn und den Krieg sich entfalten lass* XD
Ok, jetzt hab ichs kapiert.
Das ist ja ein Mega Unterschied o_O Bei Tests lag der Unterschied bei 1000 Millisekunden O_O
Traue niemandem, der von sich behauptet C++ zu können.
Ich habe mal irgendwo geschrieben, dass ich in Zukunft von C++ die Finger lassen werde. Zu dieser Zeit würde ich mich irgendwo im Tal dieses Graphs ansiedeln. Ich war ziemlich frustriert von all den Eigenheiten und Tücken, die man als C++-Programmierer kennen und zu meistern wissen muss und fand in D das, was ich mir ursprünglich von C++ erhofft hatte. Mittlerweile sehe ich die Dinge mit etwas anderen Augen. D fehlt im Moment leider noch (vernünftige) Unterstützung für DLLs, da Walter dieser noch keine hohe Priorität zuteilte, inzwischen es aber glücklicherweise anders sieht. Damit fällt D für mein aktuelles Hauptprojekt flach, da es von einer Plugin-Architektur profitieren soll. Mog hat mal Vala erwähnt, also habe ich mir Vala näher angesehen und war im ersten Augenblick positiv überrascht. Vala ist eine tolle Sprache, die sich stark an C# anlehnt und viele Stärken aufweist. Eine solche Stärke ist die absolute Kompatibilität zu C, da Vala komplett zu C (mit GObject) übersetzt wird. Leider befindet sich die Sprache noch mitten in Entwicklung, es fehlt an vernünftiger Windows-Unterstützung und - das K.O.-Kriterium - es fehlt an Dokumentation, so dass Vala für ernsthafte Projekte noch nicht geeignet ist. C++ ist alt, hat viele Designfehler und Probleme. Gleichzeitig ist C++ aber sehr umfangreich, so gut etabliert, dass man von C++ als Industriestandard sprechen kann und wird sehr gut in Form von hochwertigen Compilern auf beinahe allen Systemen unterstützt. Fazit: C++ ist ein notwendiges Übel und ich werde wohl auch weiterhin C++ im Privatbereich nutzen müssen. Im professionellen Bereich gehört fundiertes Wissen über C++ sowieso dazu. Bei all der Kritik: C++ ist natürlich allgemein gesehen trotz - oder gerade wegen - des hohen Alters immernoch eine sehr robuste Sprache, die in ihrem Sinne angewandt durchaus zu robustem und effizienten Code führen kann. D bleibt immernoch meine Lieblingssprache und ich hoffe Walter wird dynamische Bindung auf die Reihe bekommen, trotz der - zugegebenermaßen - vielen Stolpersteine, die dynamische Bindung vor allem in Windows mit sich bringt. Heute würde ich mich im Graph übrigens irgendwo beim Erklimmen des zweiten Peaks sehen.
Hm, ich denke, das passt hier halbwegs rein: Für alle, die's letzte Woche auch verpasst haben. XD
Weekends and long compiling times make monkey go… er, well, see for yourself. ;O
Das Ding ist für FireGestures – einfach auf irgendeine Geste legen und damit entweder im User-CP (falls ihr Foren abonniert habt) oder in einer Forenübersicht rumfuchteln. ;) Es werden dann alle ungelesenen Foren / Threads in neuen Tabs geöffnet und das aktuelle Tab geschlossen. :A
Mit etwas Anpassung könnte es für den kompletten Forenindex sicher auch klappen – man müsste dann aber wohl extra noch nach den Foren filtern, in die man überhaupt reinschauen will. *kratz*
Ahja, und falls man die Geste auf irgendeiner anderen Seite verwendet, wird einfach das User-CP im aktuellen Tab geöffnet.
Jedenfalls mal wieder mein Forensüchteln performanter gemacht! \o/
Office 11.0 Excel Interop in C#Zitat:
Willkommen, SmokingFish.
Dein letzter Besuch war: 03.03.2006 um 12:04 Uhr
261 Excel Files á 1,6 MB , gesamt 417,6MB, in 4 resultierende Excel Files umstrukturieren. ca. 1735s für 42 der 261 Files (18 518 Felder) - ca.3h für alle ca. 115 000 Felder. VIEL ZU LANGSAM...so langsam das ich ein Forum besuche in dem ich seit 4 Jahren nix mehr gepostet hab -_- Bei meinem Glück ist auch noch ein Fehler im Algo und ich kann die Daten nachher nochmal generieren...
Wb, Typ den ich nicht kenne! ^^"
Dank dir habe ich gemerkt, dass im XPath für die Forenübersicht noch ein Fehler steckt, wenn ein Forum Unterforen hat (wie eben das Pro-Forum hier). Der hier scheint aber zu klappen: "//div/a[contains(@href, 'goto=newpost')]". ^^'
Freut mich das ich helfen konnte xD
Ihr habt es übrigens echt schön hier, es hat sich einiges getan seit ich das letzte mal hier vorbeigeschaut hab. Werde wohl in Zukunft wieder öfter zuhause programmieren und ab und an reinschaun =).
XPath ging mir vor kurzem übrigens auch richtig auf die Nerven. Wollte Suchabfragen mit Xpath 1.0 machen und musste entnervt feststellen das es keine upper und lower case Funktionen gibt. Hab mir am Ende mit ein bissel JScript nen Workaround basteln können, schön war das aber auch nicht =(.
translate()?
Auch etwas unschön, aber immer noch besser als das Ganze ins Javascript auszulagern. ^^"
Ansonsten bin ich aber doch froh über XPath 2.0 – auch wenn ich gerade sehe, dass 1.0 eh deutlich mehr Funktionen hatte als ich dachte. o_O Hätte schwören können, contains() (ohne das ich oben wohl auch mit JS rumhacken hätte müssen ^^") hätte es da noch nicht gegeben…*kratz*
Aber eigentlich mag ich XPath, das "auch" kannst du bei deinem "auf die Nerven gehen" also ruhig streichen. ;) Habe auch selten mal Probleme damit – das hier war ja nur, weil ich eine Kleinigkeit im DOM nicht berücksichtigt habe.
(Btw habe ich oben noch eine Kleinigkeit ausbessern müssen – dass ich davor "var" vor allen drei xpath-Zuweisungen hatte, hat zu irgendeinem seltsamen Bug geführt. *kratz* Und war natürlich auch keine Absicht.)
Mögen tu ich es auch, für gewöhnlich arbeite ich aber nicht damit.
Normalerweise programmier ich in C# oder C++/C - bzw in VB/A wenn der Kunde mich ärgern will -_-. In C# ist XML Handling eh traumhaft. In dem Fall hab ich halt mal ein Webinterface gebraucht um die XML Datenbanken die meine Software generiert zu visualisieren.
Von translate() hab ich damals übrigens abgesehn weil es laut Dokumentation nicht als Ersatz geeignet war - hab gerade nochmal drüber geschaut, für das was ich gebraucht hab wär das absolut ausreichend gewesen -_- ....
Naja, der Hinweis soll wohl nur heißen, dass es nicht Unicode-sicher ist, also dass du händisch alle Zeichen einbauen müsstest, die in irgendeiner Sprache als Klein-/Großbuchstaben angesehen werden. o_O Solange aber eh alles Englisch (oder Deutsch) ist, ist das aber natürlich kein Problem – der Hinweis ist mal wieder einer dieser "OMG, das klappt in einem von tausend Fällen nicht!"-Dinger, die solche Standards so heiß lieben. <__<"
Und Mist, für den perfekten Forensurfkomfort bräuchte ich jetzt noch eine Möglichkeit, per GET-Request ein Forum als gelesen zu markieren. XD
Oho, SmokingFish, dass ich dich nochmal hier sehe! Hat dich unser Gespräch vor ein Tagen dazu inspiriert oder war das Zufall? Wie auch immer, machs dir bequem und bleib ein Weilchen.
War eher Zufall =)
Während mein Algo so vor sich hinackerte ging auf dem Rechner eh nicht mehr viel ausser surfen, also hab ich versucht mich an ein paar alte Seiten zu erinnern und n bissel zu stöbern. Bin irgentwann im RPG-Atelier gelandet (das hiess doch damals anders oder ?oO) und hab dann deinen Namen hier im Forum gelesen - für nen Offtopic Thread, perfekt, also schnell mal ausprobiern ob ich noch angemeldet bin (Standardpasswort von damals - 1360 Tage alt laut Forum xD) und voila ^^.
Da ich jetzt eh öfter in meinem neuen Arbeitszimmer am Rechner sitzen werde schau ich ab jetzt ab und an einfach mal rein, vielleicht hab ich ja irgentwann auch mal was sinnvolles beizutragen ;).
Hallö~
Ich melde mich mal wegen meinem derzeitigen Projekt.
Ich hab mir die Möglichkeiten der Speicherung durchgelesen, und hab mich für Jeez Variante entschieden.
Serializable ist echt genial und dazu muss ich nur mit einem JFrame arbeiten, so wie wir es ja schon mit unserem Java-Shooter machen.
Ich hab das jetzt so gelöst, das ich einen Starter haben, der von JFrame erbt und dann ein paar Anfangssachen macht (Fenstergröße, Resizable etc) und dann die Klasse PokeMOD aufruft, die zum Zeichen und usw. da ist (was abgegeuckt ist von dem Shooter 8D). Dieser Klasse erbt von JPanel in implementiert Runnable für die Listener. Ich hoffe ich habe das soweit richtig?
(Dann habe ich da noch eine nette Klasse gefunden die für Popup-Menüs da ist, die werde ich sicher nutzen /o)
Edit:
Achja und ich habe für Buttons die ein Bild haben sollen auch eine eigene Klasse, die so aufgerufen wird:
Die Bilder für den Button müssen natürlich da sein, sonst is doof :/
Edit:
Hat sich erledigt, hab das Problem gelöst :D
Sehr geile Liste. Meine Favoriten:
Zitat:
1801 [...] Redditers of the time are not impressed due to the lack of tail call recursion, concurrency, or proper capitalization.
[...]
Larry Wall falls asleep and hits Larry Wall's forehead on the keyboard. [...] Perl is born.
[...]
Programmable Hyperlinked Pasta (PHP)
Danke für den Link, der Artikel ist echt genial! XD
Auch die Kommentare, teils:
Zitat:
1801 - Joseph Marie Jacquard uses punch cards to instruct a loom to weave "hello, world" into a tapestry. Redditers of the time are not impressed due to the lack of tail call recursion, concurrency, or proper capitalization.
Aber meine Favoriten, da müsste ich praktisch alle zitieren. ^^" C/Unix, C++ und ObjectiveC waren aber z.B. besonders cool. XDZitat:
Jacquard's loom wasn't concurrent? It was pretty thoroughly multithreaded, I'd have thought!
PHP wird aber falsch dargestellt. Die PHP-Dokumentation wurde von kompetenten, hochmotivierten Experten geschrieben. Das Gleiche gilt auch für den Rest der Sprache, nur waren die Experten da gerade betrunken.
Mit "kompetente hochmotivierte Experten" meinst du "Entwickler, die in den Kommentaren schreiben, was nicht in der eigentlichen Doku steht", oder?
Was die Dokumentation von PHP angeht, hab ich zweigeteilte Meinungen.
Während viele Bereiche der Dokumentation doch recht gut geschrieben worden sind, sind viele andere Bereiche extremst miserabel, bis hin zur Unverständlichkeit, geschrieben.
Ein Beispiel wäre das tolle SSH2-Modul, was anscheinend auch noch nicht fertig programmiert wurde.
Wenn man unbedingt meint, so ein Modul zu veröffentlichen, sollte wenigstens die Dokumentation darauf hinweisen, was machbar ist und was nicht ...
PHP halte ich persönlich eh für eine Krankheit. Will alles können, kann aber nichts richtig.
Dude, die Entwickler haben dich nicht darum gebeten, ihre Software zu verwenden. Und das sage ich dir als ein Maintainer, undokumentierter Software. ;)
Die Typen, die das Binding veröffentlichen, wissen was sie brauchen. Warum sollten die sich zusätzlich den Arsch aufreißen?
Wenn die die Dokumentation fehlt, dann schreibe und ergänze sie. So läuft der Hase nun mal.
... die Leute stellen dir /gratis/ Bibliotheken zur Verfügung. Um diese Funktionalität selber zu implementieren, würdest du Monate brauchen.
Erkläre du mal lieber den Entwicklern, woher du die Frechheit her nimmst, auch noch Forderungen auf eine so unverschämte Art und Weise zu stellen, nachdem sie dir -- unter Anderem auch in ihrer Freizeit -- ihre Arbeitszeit und Fähigkeiten zur Verfügung stellen.
Wenn dir ihre Arbeit nicht gut genug ist, dann verwende sie nicht, sondern implementiere die notwendige Funktionalität selber, anstatt die Leute zu beleidigen, deren Arbeit du scheinbar nicht nachvollziehen kannst.
dann erkläre halt den Auftraggeber das ich das Rad neu erfinden muss, weil der Erfinder keine Lust hat, eine Beschreibung zu schreiben und somit die Produktion erstmal still steht.
Ich glaube, du willst nicht verstehen: Du hast kein Recht irgendetwas zu fordern. Du bist nicht der Auftragsgeber der Bibliothek. Du willst sie verwenden. Und das noch dazu ohne dazu etwas zu bezahlen.
Insofern du glaubst, nur weil jemand seine Arbeit zur freien Verwendung zur Verfügung stellt, muss er dir persönlich nach der Pfeife tanzen, dann hast du dich schlichtweg geschnitten.
Du hast kein Recht irgendetwas zu verlangen. Du willst konsumieren, und man hat dir die Erlaubnis gegeben dies auch zu tun. Sei froh, dass du das darfst und gefällig dankbar. Das ist nämlich keine Selbstverständlichkeit.
Noch dazu scheinst du, wenn auch indirekt, mit fremder Arbeit Geld zu machen. Dann solltest du erst recht dankbar sein, dass dir jemand die Möglichkeit dazu gibt, anstatt den undankbaren Geier zu spielen.
Was du da machst ist schlichtweg eine Frechheit. Würde es um Schokolade gehen, oder etwas anderes Materielles, würdest du das vielleicht verstehen, warum ich mich gerade fremd schaehme.
Ich hab mir den Mist nicht ausgedacht. Der Kunde will PHP und dann bekommt er PHP.
Und ich finde, zu jeder Bibliothek, egal ob nun OpenSource oder ClosedSource, gehört eine Dokumentation. Die muss ja nicht 1000 Seiten dick sein. Eine kleine Beschreibung zur Bibliothek und deren Funktionen würde schon reichen.
Und sowas ist bei PHP oftmals nicht gegeben, sodass selbst die Entwickler rätseln, was überhaupt einige Funktionen können und was nicht.
Schon traurig, dass sowas keine Selbstverständlichkeit ist ... Bei einer Welt, die angeblich sooooo viel Wert auf Dokumentation und Kommunikation legt ...
:hehe:
Jetzt klingst du gerade, wie ein Realitaetsverweigerer. Dokumentation ist -- egal ob bezahlt, oder nicht bezahlt -- alles andere als normal. ICh habe schon oft kommerzielle Bibliotheken in der Hand gehabt, bei denen man einfach durch probieren heraus finden musste, was Sache ist.
Du hast hier mindestens den Source. Da sehe ich echt kein Problem.
Prinzipiell gebe ich dir aber recht: Die Realität ist in dem Punkt nicht so schön.
Aber, wenn es was mit SSH ist, ist die Lib sowieso gebunden. Schau mla in ie C-Doku. Die hilft sicher weiter.
Imho hat php eine sehr gute Doku o_O. Auf php.net habe ich bisher eigentlich fast immer das gefunden was ich suchte.
Das einzige was mir gerade einfällt ist eine Konstante für die Curl-Bibliothek welche in der Doku nicht auftaucht, aber das eine Konstante von weiß ich wie vielen vergessen wird ... *.
Und ich weiß nicht wo dein Problem liegt ... auch die SSH-Lib ist ausreichend dokumentiert ...
http://de2.php.net/manual/en/book.ssh2.php
Das würde ich mir für manche Software welche ich auf der Arbeit benutze wünschen ...
Die PHP-Doku ist eine gemischte Sache: Für die üblichen Module ist sie vollständig und (abgesehen von Cocoa) jeder anderen mir bekannten Programmierumgebung deutlich überlegen. (Ja, Pythons Doku geht mehr in die Tiefe, dafür ist es schwer, das zu finden, was man eigentlich braucht.) Dafür sind die obskuren Module, die nur sehr selten mal jemand benutzt, teilweise komplett undokumentiert.
Generell funktioniert die PHP-Doku wirklich gut. Die Probleme treten fast immer in Randfällen auf und da für gewöhnlich bei Bindings zu externen Bibliotheken.
Ich bin übrigens dafür, dass wir die Threadnummer bei 256 oder 512 erhöhen (bzw. einen neuen Thread aufmachen), einfach weils so schön glatte Zahlen sind.
10nded! :D