Crush

Und wo sind die Ergebnisse nun?

Ich bin heute etwas faul, deshalb verweise ich auf ein paar alte Threads, in denen ich mal versucht habe (mehr oder weniger korrekt) Zeiger und Referenzen zu erklären (wiederholt sich eh alles ständig von vorne). !!!Aber Vorsicht!!! Meine Sicht auf Referenzen ist nur deklarativ aus technischem Verständnis heraus erklärt und nicht ganz realistisch - dafür aber verständlich, jedoch überhaupt nicht im Sinne der C/C++-Entwickler. Simpel Komplizierter Syntaxproblematik

Ich finde die Brasilianer haben extrem viel gefault und immer wieder simuliert (z.B. wie sich einer auf der Bahre wegschleppen läßt und am Rand lächelnd wieder runterspringt um weiterzuspielen). Unser von den Spikes zertrampelte blutverströmte Spieler durfte zu Fuß mit einem Pflaster vom Feld schlendern. Unsere Leute haben einfach zu fair gespielt gegen diese Dauerschubser. Von der Leistung fand ich an sich in den ersten 2 Dritteln die Deutschen und die Brasilianer gleich.

Ich wußte auch nur, daß es vor ein paar Jahren mal eine solche Waffen-Regelung für Kryptographie gab. Es ist ja nur gut, wenn die sowas Unsinniges abgeschafft haben, weil ein guter Coder sowas über den Feierabend selbst kurz zusammenbastelt.

Ich habe auch noch die Vorgänger-Version mit 168-Bit-Schlüssel, die in Amerika verboten wurde, weil sie wohl gegen dort gängige Normen verstieß (war glaub damals nur 128 Bit erlaubt). Die neue Version mit dem 1024-Bit-Schlüssel wird sicherlich ein ähnlicher Algorithmus zugrunde liegen. Warum sollte man auch etwas ändern was sich bewährt hat? Dieser muß dann theoretisch so schlimm sein, daß die Amis den Coder gleich auf die Liste neben Bin-Laden setzen werden =8-)

Ist ein 1024-Bit-Schlüssel sicher genug? Ich find das Programm ganz ordentlich.

Und wer weiß noch was die Phreax waren? (sorry, bestimmt wieder OT...)

Swing ist sehr böse. Dungeon Keeper 1 & 2 auch. Outcast genauso. The Sentinel finde ich noch genial. Die alten 8-Bit-Versionen haben übrigens denselben Spielspaß wie die Neuauflage nur von der Grafik her halt ein anderes Flair.

Es haben schon mehr Leute mit Hauptschulabschluß die FI-Prüfung bestanden als man glauben mag, also sollte einer mit Abi keine größere Schwierigkeiten haben. Die Kenntnisse aus der 8. Klasse hinsichtlich Mathematik reichen vollkommen aus (Plus, Minus, Mal, Geteilt, Prozent und schlimmstenfalls noch Bruchrechnen ... ok 1-2 mal kommt sogar noch eine Wurzel vor (Materialwirtschaft), aber die braucht keiner zu verstehen wird auch nicht erklärt, sondern nur als Mittel zum Zweck ohne den Sinn hinterfragen zu wollen in den Taschenrechner reingetippt). Der Rest ist meist Verständnis- und Lernsache. Physik und Chemie braucht man bestenfalls noch um in Normal- & Digitalelektronik einigermaßen mitzukommen. Das ist jedoch seeehr gerafft und dürftig. Es reicht wenn man mal eine kleine Zählschaltung oder einen Flip-Flop zusammengebastelt bekommt und simple Strome, Spannungen, bzw. Widerstände wenigstens ansatzweise berechnen kann. Englisch wird zwar nicht abgeprüft, ist aber fürs spätere Berufsleben und wie der Vorgänger schon sagte auch für Informationsquellen sehr sinnvoll und nützlich. Wenn Du´s hattest ... freu Dich und versuch es nicht zu verlernen. 3er beim Abi tun´s voll.

Da gehört eine Menge Mut dazu sowas ins Netz zu stellen - und sicherlich auch ein hoher Alkoholpegel =8-)

Ich weiß von Softwareprodukten die komplett in VB geschrieben sind. Selbst kompliziertere Anwendungen die stark datenbank- und netzwerkorientiert sind lassen sich mit VB offensichtlich gut realisieren. Allerdings gibt es halt sicherlich einige Schwierigkeiten wenn man "tieferliegende" Funktionen des Systems nutzen möchte oder die Geschwindigkeit eine Rolle spielt. Doch ich habe jedenfalls jetzt das erste mal gehört, daß VB objektorientiert sein soll - vielleicht eine Anspielung auf die COM-Objekte?!?! Also habe ich mich mal schlau gemacht... Beim Suchen fand ich das was die Aussage bestätigt. Schaut man sich die Erklärung zur Objektorientierung an, finde ich diese Kategorisierung ziemlich dürftig. Andere Links sagen das Gleiche (falsche). Professionellere, zuverlässigere (aber englische) Quellen und Wörterbücher meinen, daß Smalltalk die einzige wirklich objektorientierte Programmiersprache ist (nicht so Java oder C++ und schon zweimal nicht VB), an der sich alle anderen (möchtegern) objektorierntiert-erweiterten Sprachen messen lassen müssen. Genau diese Aussage habe ich mehrfach in meinem Bücherschrank zu C++ gelesen: Nur Smalltalk ist OO pur. Zu VB sagen die, daß es sich nicht um eine echte objektorientierte Sprache handelt, sondern eine mit objektorientierer Philosophie und einer Event-gesteuerten Objektbehandlungsmethode auf Drag´n´Drop-Objekte wie Buttons, Dialog-Boxen und Controls. Sieht mir sehr eingeschränkt aus man ist ziemlich abhängig von den zur Verfügung gestellten Elementen. Also sollten sich mal alle am Riemen reißen, akzeptieren, daß es nur eine einzige "echte" objektorientiere Programmiersprache (nämlich Smalltalk) gibt - auch wenn´s den C++ oder Java-Programmierer schmerzt ... das sind nur Programmiersprachen mit objektorientierter Erweiterung und alle sind noch einiges von Smalltalk und dem echten OO-Grundgedanken entfernt! Ich behaupte einfach mal, daß VB (außer .NET) eine schwer eingeschränkte Objektorientierung zugrunde liegt, aber ganz Ohne ist es wohl auch nicht. Aus der Sicht eines 4GL-Coders sind die OO-Möglichkeiten und Ansatze bei VB mehr als leicht eingeschränkt und somit sehen die das schon gleich gar nicht als objektorientiert an. Allerdings müssen die sich auch damit abfinden, daß selbst ihre Programmiersprachen noch lange nicht perfekt dem OO-Grundgedanken entsprechen. Man sollte hier nicht so aufeinander rumhacken und ELO Recht geben, weil ich weiß, daß der ein professioneller Smalltalk-Programmierer mit langjähriger Erfahrung ist (und das sind bestimmt verdammt Wenige in der FI-Welt)! Wenn hier einer etwas Genaues von der OO-Materie und Smalltalk-betreffendes weiß, wird er es mit Sicherheit sein, der da wirklich mitreden kann. Ich verstehe eh nicht, warum man plötzlich aus einer Aussage zum Thema einen neuen Thread gemacht hat, der erstens von den zugrundeliegenden Aussagen getrennt wurde und sich dann plötzlich so im Sande verlaufen hat weil die anderen Teilnehmer am Gespräch gar nicht genau wußten was die Vordiskussion überhaupt war und plötzlich wurde das Ganze auch noch gesperrt (wahrscheinlich dachten alle: Der ELO spinnt, sowas als Thread zu eröffnen). Also nochmal: Mit VB kann man schon was anfangen, "echt" objektorientiert ist nur Smalltalk und alles weitere nur ein mehr oder weniger schwer eingeschränkter Abklatsch davon.

Die Sache mit dem Fernstudium ist eine gute Idee. Man muß allerdings schon überdurchschnittlich fit sein um Ausbildung und Studium gleichzeitig unter einen Hut zu bringen - allerdings profitiert das eine vom anderen sicher mit. Warum bin ich Idiot eigentlich nicht darauf gekommen. Hört sich für mich nach der vernünftigsten Lösung an, welche die meisten Vorteile bietet und viel Zeit spart.

Ich weiß ja nicht, wie manche hier Programmieren. Allerdings gehört dazu weitaus mehr als nur Code einzutippen. Im echten Leben will man Dokus, Anleitungen, Bemerkungen, Mailverkehr mit Kunden, Kollegen oder sonstwem. Die Programmierung macht normalerweise NIE 100% der Schreibtätigkeiten aus, in den meisten Fällen ist es sogar ganz normal, daß das reine Sourceschreiben im Ideal 10-30 % überhaupt ausmacht. Zu behaupten, daß Schreibmaschinenkenntnisse einen überhaupt nichts nützen halte ich für etwas reißerisch, weil man diese auch anderweitig einsetzen kann. Vielleicht haben noch nicht viele so Leute kennengelernt. Ich kenne Softwareentwickler, die wirklich schneller programmieren können, als Bürotippsen Standardbriefe verfassen. Natürlich gibt es gewisse Denkaufgaben die einen abbremsen, aber irgendwann wiederholen sich viele Strukturen, die sich dann wie blind runterschreiben lassen. Schnelles Programmieren ist sehr wohl möglich.

Die Samplerate und die Tonhöhe stehen direkt miteinander in Verbindung. Bei 22050 Abtastungen kann ich eben maximal 22050 Hz. erreichen. Die Codecs versuchen ja mit DCT diese Herzzahl vereinfacht darzustellen, doch dabei gehen vor allem Spitzen verloren. Wie gesagt soll bald eine neue Teamsound-Version rauskommen mit absolut freier Sampling-Rate und verbesserter Kompression... ich warte schon drauf.

Erst immer suchen!

Hier gab´s da auch diverse Tips und Tricks dazu. Ich habe jedenfalls meiner Frau in 2 Stunden blindes 10-Finger-System beigebracht (steht im Thread) - geht alles, wenn man sich nur ein wenig zusammenreißt. Wie ich das selbst gelernt habe habe ich allerdings nicht erwähnt ... allerdings war damals meine alte mechanische Triumph-Adler (konnte ich selber kaum hochheben dieses Metallmonster) sicherlich sowas für mein Schreibsystem wie die Langhantel für Arnold Schwarzenegger =8-) Jedenfalls diese komischen Standard-Monoton-Fingerübungen wie asafasafasaf... oder klkmklknklkb und Ähnliches halte ich für verwirrend, unrealistisch und man versucht hier durch die Mechanik das "Gefühl" für die Buchstaben zu entwickeln. Andersrum geht aber schneller -> erst lernen, dann vorstellen welche Finger bei welchen Buchstaben getippt werden sollen und später dann direkt tippen. Liegt näher an der Realität und frustet weniger.

War VB eine Programmiersprache? Ich dachte, daß wäre unter Scripts einzuordnen =8-)

Wir hatten ein paar alte Prüfungen - aber ohne Lösungen - als Prüfungsvorbereitung vor 1,5 Jahren. Aber alles auf Papier ... das sollte noch irgendwo im Keller rumfliegen, doch ich bin zu faul die zu suchen und einzuscannen. Aber eines kann ich Dir sagen: Es hat sich praktisch keine Prüfung thematisch geglichen. Immer wurde ein neuer Schwerpunkt gelegt. Von daher bringen die alten Prüfungsaufgaben relativ wenig.

Echte Stimmen kommen eh nicht in solche Frequenzbereiche (vielleicht manch professionelle Operndiva, sonst niemand). Aber an sich könnte man sowas mal machen - warum eigentlich?

Teamsound geht bei 32KBps Übertragungsrate auf 22050 Hz hoch - aber auch wesentlich kleinere Übertragungsraten bieten eine super Qualität.

Ich jedenfalls glaube, daß es einem Anwendungsentwickler einfacher fällt den Bereich vom FISI eigenständig nachzuholen - zum Großteil hat man ohnehin gleiche Themen vermittelt bekommen. Leute aus der Uni sind natürlich besser dran, weil die vom Niveau her mehr Qualifikation und tieferes Wissen mitbringen(v.a. Mathematik, Algorithmen, Softwaretechnik, etc.). Allerdings gibt es dort auch genügend Heuler und die Quote der Programmier-Unfähigen liegt in etwa gleich wie die der FIs. Die FIAE-Ausbildung darf man eher als einen Einstieg in die Softwareentwicklung betrachten. Ein Dipl-Inf. kann sehr wohl von sich behaupten etwas mehr auf dem Kasten zu haben und auch ohne Weiteres in schwierigere Themen eintauchen. Dies bedeutet jedoch nicht, daß ein FIAE mit genügend Elan und Enthusiasmus es nicht auch schaffen kann, dieselbe Ebene oder sogar eine Höhere zu erreichen. Weiterlernen muß man ohnehin, egal was man lernt. Man weiß meist nicht im voraus wo man landen wird und muß sich dann entsprechend einarbeiten. Ein Studium hinten an die Ausbildung ranzuhängen halte ich für unsinnig weil einfach zuviel Zeit dabei drauf geht - wenn, dann sollte man das Studium lieber gleich starten und den FI auslassen.

Daß es ernsthaft noch jemand probiert an Prüfungsunterlagen ranzukommen... manche lernen es wohl nie! Falls Du´s noch nicht weißt: Schau mal nach, was letztes Jahr um diese Zeit los war, weil jemand solch einen Schlunz gemacht hat und Prüfungsthemen nannte.

Eine Grundregel besagt: Verwende Referenzen wenn möglich und Zeiger nur wenn nötig. Da steckt schon ein Hinweis auf die Problematik drin, aber es gibt eben Anwendungsfälle, die ohne Zeiger schwierig, langsam oder gar unmöglich zu realisieren sind. (habe grad gesehen, daß Gaius jUlius zeitgleich denselben Gedanken hatte) Trotzdem ist es sinnvoll die Technik zu beherrschen anstatt sich von ihr abzuwenden, weil es "gefährlich" ist. Man kann Programme auch ohne Zeiger abschießen. Selbst manche scheinbar simple Funktionsaufrufe können Exceptions auslösen bis zum Abwinken und Speicherlücken erzeugen, daß es nur so kracht. Sobald irgendwo irgendwas manipuliert wird, geht man schon Gefahren ein. Jegliche Schreibzugriffe aller Art stellen immer eine mögliche Absturzquelle dar, aber ohne solche Funktionen und Programmteile könnte man ja gar nichts mehr auf die Beine stellen. Man muß sich damit auseinandersetzen und versuchen die Problematik zu begreifen, erfassen, in den Griff zu bekommen und zukünftig zu kontrollieren. Ich jedenfalls verwende sooft Zeiger, daß ich mir erst gar nicht vorstellen kann ohne sie zu arbeiten.

Komisch, bei mir lief´s vorhin erst nach dem -1 einwandfrei, ohne gabs 1 richtiges und 1 falsches Ergebnis... jetzt habe ich das vom Board nochmal rauskopiert, das -1 rausgenommen (was ja logisch betrachtet auch richtig war und mich selber durcheinander gebracht hat) und plötzlich ist es auch so, daß es nur 1 richtiges Ergebnis liefert. Ich habe vorhin ziemlich an den Compile-Settings rumgespielt ... vielleicht hat den das durcheinander gebracht? Also einfach das -1 wegstreichen und dann klappt es. Wahrscheinlich hatte nur mein Compiler irgendwie gerade einen Schlag weg.

Ich hab den Spaß nochmal in einer einzelnen Schleife probiert. Vielleicht kann mir einer den Rundungsfehler erklären, der sich beim Hund ergibt (deshalb das -1 anfangs bei der If-Abfrage) ohne Welchem bei Position x=880705 noch ein zusätzliches falsches Ergebnis ausgespuckt wird: float maus=.5,katze=4.5,hund=5.; for (long x=10101;x<1000000;x++) { if ((x%100-1+(x/100)%100+(x/10000)%100)==100 && ((x%100)*hund+(((x+50)/100)%100)*katze+(((x+5000)/10000)%100)*maus)==100) TRACE("\nHund = %d, Katze=%d, Maus=%d\n",x%100,(x/100)%100,(x/10000)%100); } Ich finde, daß das Goto oben korrekt angewendet wurde. Warum der Aufrur? Der einzig sinnvolle Einsatz heutzutage ist der Sprung aus mehrfach verschachtelten Schleifen, was wesentlich übersichtlicher ist als unnötige Abbruchkriterien die den Source aufplustern.