amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Suche [ - Suche - Neue Beiträge - Registrieren - Login - ]

Erste << 97 98 99 100 101 -102- 103 104 105 106 107 >> Letzte Ergebnisse der Suche: 3680 Treffer (30 pro Seite)
Solar   Nutzer

20.05.2003, 09:10 Uhr

[ - Direktlink - ]
Thema: Biowaffen-Telegramm Nr. 16
Brett: Get a Life

Zitat:
Original von DrNOP:
Ich muß zugeben, daß ich keine Ahnung habe, was Voltaire gesagt hat...


Ich find's gerade nicht wörtlich, aber sinngemäß etwa:

"Ich bin zwar nicht Deiner Meinung, aber ich würde mit meinem Leben dafür kämpfen, daß Du diese Meinung äußern darfst."

Zitat:
Demokratie oder Gottesstaat ist völlig unerheblich, solange es solche Intoleranz zwischen den Religionen gibt, wie wir sie vor allem aus Richtung der Moslems immer wieder erfahren.

Ach was?

Gerade im nahen Osten ist das Ganze doch wohl das klassische Henne - Ei - Problem. Da wurden im Mittelalter die Kreuzzüge unternommen, da haben die Briten im 19. und frühen 20. Jahrhundert Politik mit der Brechstange (und reichlich Senfgas) betrieben (man was gut, das die RAF und Mr. Arthur Harris da Erfahrungen sammeln konnten, wie man ein Land in die Knie bombt, das war dann am 1940 wieder sehr aktuell), da läßt die "Staatengemeinschaft" seit den späten 1940'ern dem Retortenstaat Israel so ziemlich alles durchgehen (Angriffskrieg, Annektion, Bombardement der Einrichtungen souveräner Staaten), weil die USA dahinterstehen (oder umgekehrt?) - genauso wie den USA im 21. Jahrhundert - und "die Moslems" sind die Bösen, weil einige Menschen das Scheiße finden und sich auf die einzige Art wehren, die zumindest Aufmerksamkeit bei den satten, zufriedenen Besserwessis (im globalen Sinn) erregt?

Wer sind eigentlich "die Moslems"?

Jetzt, in diesem Moment, sitzt vier Tische weiter ein Vertreter dieser Gruppe. Und weißt Du was? Ich fühle mich nicht im geringsten Bedroht. Ich habe selten einen freundlicheren, zurückhaltenderen Menschen erlebt.

*Bedroht* fühle ich mich im Moment in erster Linie durch die USA...

Zitat:
Die Konsequenz wäre, nicht Staaten zu bekriegen, in denen religiöse Führer regieren, sondern den Islam als Religion auszurotten. Aber versuch das mal jemand ...

Au ja. Noch jemand Interesse an einem Kreuzzug?

Der Islam als Religion ist grob 500 Jahre jünger als das Christentum.

Wie "zivilisiert" waren wir Christen so um 1600? War doch etwa die Zeit, zu der wir die Eingeborenen Amerikas ausgerottet und die "Wilden" Afrikas "zivilisiert" haben - also, ist mal wieder Zeit eine Zivilisation "anzuwesseln", weil sie uns nicht in den Kram paßt.

Mann, DrNOP... Menschen wie Du machen mir mehr Angst als alle Terroristen unserer Generation zusammen. Solche Meinungen führen nämlich dazu, daß auch nächste Generation der Terror nicht weniger wird.

Terror kann man nicht bekriegen. Das sollten Nordirland, Baskenland, Israel etc. etc. bewiesen haben.

Aber man kann Terror die Grundlage entziehen, man kann Menschen Gründe geben, *nicht* Terrorist zu werden. Der beste Grund ist Hoffnung, die Hoffnung auf eine friedliche Lösung der Probleme.

Sowohl Israel als auch Nordirland haben gezeigt, daß in Zeiten der Annäherung der Terror zurückgeht, weil nur noch die "Hardliner" - die es *immer* geben wird - zum Terror greifen. Seit Israel wieder die harte Linie fährt, hat der Terror dort deutlich zugenommen.

Von dem alltäglichen, schleichenden Terror der Staatsgewalt gegenüber den eigenen Bürgern mal ganz zu schweigen. Was man heute (nicht nur) in den USA an Überwachungsstaat erdulden muß, läßt Orwell einen Optimisten scheinen.
 
Solar   Nutzer

19.05.2003, 19:18 Uhr

[ - Direktlink - ]
Thema: StormC/Miami/Farcode/Nearcode...
Brett: Programmierung

Alle betreffenden Bibliotheken mit demselben Compiler-Setting compilieren.

Evtl. gibt's da noch den einen oder anderen Trick, aber das ist dann AmigaOS-spezifisch, da muß ich leider passen.
 
Solar   Nutzer

19.05.2003, 19:17 Uhr

[ - Direktlink - ]
Thema: pc-task v4
Brett: AROS und Amiga-Emulatoren

Leider schon abgetreten an die Jungs von BAUD, http://www.baud.de. Evtl. ist die Software dort aber auch "verwaist", am besten mal nachfragen.
 
Solar   Nutzer

19.05.2003, 19:08 Uhr

[ - Direktlink - ]
Thema: StormC/Miami/Farcode/Nearcode...
Brett: Programmierung

Wie gesagt, das Problem ist nicht die Miami.h - die teilt dem Compiler nur mit, welche Symbole in der Objektdatei vorhanden sind.

Die Probleme treten dann auf, wenn das Programm, das Miami.h includet, mit einer anderen Option als die Miami-Bibliothek compiliert wurde - dann fliegt nämlich der Linker (gute Umgebung) bzw. das Executable (nicht so gute Umgebung) auf die Nase.
 
Solar   Nutzer

19.05.2003, 10:36 Uhr

[ - Direktlink - ]
Thema: Biowaffen-Telegramm Nr. 16
Brett: Get a Life

Und was gibt uns das Recht, denen vorzuschreiben, daß Religion und Staat bitteschön zu trennen seien und die Staatsform Demokratie einzig seligmachend ist? Müssen wir ein anderes Volk solange an der Leine dressieren und auf unsere Kulturwerte eichen, bis es in einer freien und gleichen Wahl sich dann nicht mehr - aus freiem Willen! - für einen Gottesstaat entscheidet?

(Nicht daß ich für einen Gottesstaat wäre, aber ich halte es mit Voltaire...)
 
Solar   Nutzer

19.05.2003, 10:27 Uhr

[ - Direktlink - ]
Thema: Maxon C++ Updates
Brett: Programmierung

Zitat:
Original von Darki:
Wie sieht es eigentlich mit C# am Amiga aus, gibt es da schon was?


Das ist jetzt ein Scherz, oder?

Mensch, ich würde mir eher Gedanken um sowas wie eine aktuelle Perl- oder C++-Umgebung machen, bevor ich mir um "Spielereien" wie C# Gedanken mache, das selbst auf Linux noch nicht fertig und aufgrund der .NET-Anforderungen auf dem AmigaOS (3.x) wahrscheinlich gar nicht umsetzbar ist...

?( :lickout:
 
Solar   Nutzer

19.05.2003, 10:22 Uhr

[ - Direktlink - ]
Thema: StormC/Miami/Farcode/Nearcode...
Brett: Programmierung

ACHTUNG - das folgende ist allgemein (statt Amiga-spezifisch) und stark vereinfacht dargestellt!

Es geht um die Größe des Offset bei Codeverzweigungen.

Wird z.B. eine Funktion angesprungen, ist dies auf Maschinensprache-Ebene ein Sprung an eine andere Speicheradresse.

Bei "Nearcode" (nahem Code) wird nun ein "kleiner" Offset genommen, sagen wir einmal 16 bit. Das reicht, um 32kByte nach "vorn" oder 32kByte nach "hinten" zu springen. Wird das Executable / die Library größer als 64kByte, dann wird's schwierig.

Bei "Farcode" wird nun ein "größerer" Offset verwendet, i.d.R. sogar eine absolute Adresse statt des Offset. Damit ist jeder Code im Speicher ansprechbar; allerdings kostet "Farcode" Speicher und Taktzyklen.

Die "Problemchen" beim verlinken von Near- und Farcode-Objektdateien kannst Du Dir dann selbst ausmalen. ;-)
 
Solar   Nutzer

08.05.2003, 08:52 Uhr

[ - Direktlink - ]
Thema: Wie programmiert man denn am besten folgendes:
Brett: Programmierung

Zitat:
Original von mrbbc:
Zu der "unzulässigen Verallgemeinerung": man müsste sehen, was für eine CPU/wieviele. Moderne CPUs haben mehrere parallele Befehlsinterpreter, beim sog. "Hyperthreading" sind's besonders viele. Im Grunde hat man also virtuell einen Multiprozessorcomputer.


Hyperthreading ist die Abbildung von mehreren, mehr oder minder unabhängigen CPUs auf einem CPU-Core. (Der neue Intel Xeon, für die die nicht wissen worum es geht.)

Die "parallelen Befehlsinterpreter" sind die Ausführungseinheiten bei einer superskalaren CPU. Das gibt's schon seit dem 68060 IIRC.

Das Finden der optimalen Anzahl von Threads ist eine Wissenschaft für sich. Der Server, für den ich gerade programmiere, hat 20 CPUs (Sun E10k) - merkwürdigerweise ist die optimale Anzahl von Verarbeitungsthreads aber näher bei 30 (haben wir per Profiling ermittelt) - und das, obwohl auf der Maschine noch diverser anderer Kram im Hintergrund läuft...

Zitat:
Multithreading kostet ein wenig Performance. Wenn man aber im Gegenzug die Last effektiver verteilen kann, hat man einen kleinen Leistungsschub.

Die Performanceeinbußen hängen auch noch stark vom OS ab (leichtgewichtige Prozesse, Kernel-Level Threads vs. User-Level Threads etc. etc.).

Zitat:
Zwingend notwendig ist es aber nicht.

Letztendlich, und wenn es nicht auf das letzte bißchen Performance ankommt (prof. Serveranwendung, High-End 3D o.ä.), dann sollte das Programmiermodell den Ausschlag geben - keep it as simple as possible, but no simpler.
 
Solar   Nutzer

07.05.2003, 11:32 Uhr

[ - Direktlink - ]
Thema: Wie programmiert man denn am besten folgendes:
Brett: Programmierung

Statt eine Endlosschleife zu haben, die jeden Durchlauf beim Wait...() blockiert, ist eine andere Implementierung recht verbreitet: Eventhandler / Callbacks. Dabei wird eine Funktion (Handler) beim System "registriert", und dann beim Auftreten des Events vom System aufgerufen (Callback).

Inwieweit das AmigaOS dies unterstützt, weiß ich nicht. Als ich mit "fortgeschrittener" Programmierung anfing, war Amiga schon auf dem absteigenden Ast ;( , so daß ich kaum praktische Erfahrung mit der AmigaOS-API habe. Aber quasi alle Systeme, die ich seither kennengelernt habe, arbeiten mit Callbacks.
 
Solar   Nutzer

07.05.2003, 10:49 Uhr

[ - Direktlink - ]
Thema: Wie programmiert man denn am besten folgendes:
Brett: Programmierung

Zitat:
Original von mrbbc:
Also erstens gäb's es keinen triftigen Grund, C++ zu nehmen, wenn du mit C bestens vertraut bist.


Erweiterung des Horizonts? Vorteile von C++ bei wachsendem Programmumfang (Modularisierung, Namensräume etc.)? Man muß noch nicht einmal OO, Templates oder Exceptions nutzen, um von C++ zu profitieren... aber das ist bei vielen eher eine Glaubensfrage...

Zitat:
Eine Endlosschleife ist ja auch das Eventsystem. Wenn was passiert, verarbeitet es das Ereignis und generiert ein passendes Event...

?(

Komische Auffassung von einem Eventsystem...

Zitat:
...der Timer müsste aber mindestens im Dezisekundentakt auslösen und das bremst wieder wie sau...

...ein Event alle 0,1 Sekunden? "Bremsen wie Sau"? Oh Gott, ich darf nie wieder meine Maus anfassen... :)

Zitat:
Tasks bzw. Threads machen nur bei bestimmten CPUs Sinn, z.B. Multiprozessormaschinen.

Unfug. I/O- vs. CPU-Phasen, und alleine schon das Round Robin des Exec, machen Mutlithreading / Multitasking auch innerhalb einer einzigen Anwendung durchaus sinnvoll.

Zitat:
Schwachsinn ist es aber, so viele Threads wie möglich zu machen. Das Optimum sind wohl so 4 Threads für ein Programm.

Stimmt auch nicht. Klar bremsen übermäßig viele Threads ein System aus. Die "richtige" Anzahl hängt aber zum ersten von der CPU ab (siehe Hyperthreading), zum zweiten von der OS-Unterstützung, zum dritten von der Anwendung. Was Du hier sagt, mrbbc, ist eine unzulässige Verallgemeinerung.

Zitat:
Original von Reth:
(kenne keine Threadbibliothek für AmigaOS, Tasks dürften OK sein)


Aufgrund seiner Architektur (kein Speicherschutz) kennt AmigaOS prinzipiell keinen Unterschied zwischen Task und Thread. (Ein "Thread" im klassischen Sinne ist ein Kontrollfluß in einem Adreßraum / Prozeß; "Multithreading" meint mehrere Kontrollflüsse in demselben Adreßraum.)

Zitat:
...und die ereignisbasierten Teile der Anwendung (Userinteraktionen usw.) in einen anderen?

Genau. So wird der Kontrollfluß der Grafik-Task nicht unterbrochen, wenn ein User-Input eintrifft. (Natürlich *wird* er unterbrochen, aber automatisch durch das OS statt durch Programmierung deinerseits.)

Zitat:
Wie sorge ich dafür, dass mein Zeichentask kein Busy-Waiting macht? Schicke ich ihm ein Signal, wenn mein Message-Handler eine INTUITICKS-Nachricht bekommt?

Klingt gut.

Zitat:
Original von mrbbc:
Alternativ kannst du auch eine Wartesequenz einfügen, die jeden Frame auf x Millisekunden synchronisiert, d.h. nach z.B. 100 Millisekunden wird immer ein neuer Frame erst sichtbar gemacht[1], egal, ob er 10 oder 80 Millisekunden zum Zeichnen gebraucht hat...
[1] mit flipscreen/swapscreen/doublebuffering oder wie es auch immer genannt wird


Doublebuffering.


[ Dieser Beitrag wurde von Solar am 07.05.2003 editiert. ]
 
Solar   Nutzer

06.05.2003, 09:07 Uhr

[ - Direktlink - ]
Thema: Vor fast 10 Jahren
Brett: Get a Life

...und Cygwin als Hirn dazu - zumindest bei mir. ;-)
 
Solar   Nutzer

17.04.2003, 13:59 Uhr

[ - Direktlink - ]
Thema: Library & Devices proggen
Brett: Programmierung

Zitat:
Original von Cyborg:
-- We would die for :commo:


:boing: has died for :commo: ... :lickout:
 
Solar   Nutzer

17.04.2003, 10:51 Uhr

[ - Direktlink - ]
Thema: Neues Jugendschutzgesetz ist das letzte!
Brett: Get a Life

Mal die Gegenposition: Du willst also, daß nicht geprüfte Spiele weiter "frei" erhältlich sind, weil Du z.B. Biene Maja oder Tetris für unbedenklich hältst.

Womit wir bei der Frage wären, was "unbedenklich" ist, und wo die "Unbedenklichkeit" aufhört. Biene Maja? Tetris? Civilisation? Moorhuhn? Worms? Panzer General? F-117? Doom?

Wo ist die Grenze?

Genau. Das müßte man dann festlegen. Und genau das macht die USK.

Ich finde das Gesetz eigentlich gar nicht *so* blöd. Das in Deutschland jetzt das EU-Gegenstück zum DMCA gilt, Software demnächst auch hier patentiert werden kann und "Trusted Computing" de fakto nicht mehr aufzuhalten ist (und z.B. verhindern kann, daß auf Deinem Rechner eine Software ohne USK überhaupt läuft) - darüber kann man sich sehr viel mehr Sorgen machen.
 
Solar   Nutzer

14.04.2003, 13:01 Uhr

[ - Direktlink - ]
Thema: Laufwerke Feststellen
Brett: Programmierung

Leider ist es nicht ganz so einfach. Wenn Du "die sichere Linie" fahren willst, müßtest Du z.B. auch malloc() mit einem Garbage Collector versehen... und der "perfekte" GC muß auch noch erst entwickelt werden.
 
Solar   Nutzer

11.04.2003, 10:07 Uhr

[ - Direktlink - ]
Thema: Laufwerke Feststellen
Brett: Programmierung

Zitat:
Original von Holger:
In jedem Programm, das kein Bespiel für ein bestimmtes Teilproblem darstellt, ist dies natürlich richtig.


OK, der Punkt ist angekommen und akzeptiert: Dein Beispielcode war halt nur ein Beispiel. Wir kritisieren nicht, wir fachsimpeln.

Zitat:
Und zeige mir den Programmierer, der in seiner Software an den Fall denkt, das printf fehlschlagen könnte...

fprintf() in jedem Fall. Aber Du hast recht, die meisten interessieren sich nicht mal für den ach-so-unwahrscheinlichen Fall, daß malloc() ein NULL zurückgeben könnte... das hat neulich einer Anwendung auf einer mit zig GByte Arbeitsspeicher ausgestatteten Sun E10000 ein abruptes Ende beschert...

Zitat:
Da ja jedes sauber geschriebene Programm eine Kopie anlegt (das sagen wir doch alle), wäre es das naheliegenste, eine Funktion im OS zu implementieren, die gleich eine Kopie zurückliefert. Damit sind Deadlocks an dieser Stelle absolut sicher ausgeschlossen...

Nein. Die Gefahr wäre nur in die OS-Funktion verlagert. Es ist ziemlich schwierig, eine solche Funktion in eienr Weise zu implementieren, die jedem worst-case von multitasking, multiprocessing und Fehlbedienung standhält. Und wenn man eine solche ösung hat, kostet sie erhebliches an Laufzeit...

Zitat:
...und es ist effizienter, da eine einzelne OS-Routine den Prozessorcache besser ausnutzt, als n eigene Versionen dieser Kopierroutine in jedem Programm.

Na, na. Die allermeisten OS-Routinen werden wohl kaum oft genug aufgerufen, um zwischen zwei Aufrufen nicht aus dem Cache zu wandern. (Wie oft fragst Du die verfügbaren Laufwerke ab?)
 
Solar   Nutzer

10.04.2003, 12:39 Uhr

[ - Direktlink - ]
Thema: Laufwerke Feststellen
Brett: Programmierung

Zitat:
Original von Holger:
Wie soll ich dann die DOSList auslesen, wenn ich keine DOS-Funktionen benutzen darf.


Ganz grundsätzlich gilt: Lock, schnellstmögliches Verarbeiten, Unlock. Schnellstmöglich heißt i.d.R. zwischenpuffern. Dazu kommt die gesunde Paranoia gegenüber jeder Aktion, die komplexer ist als eine Wertzuweisung an fertig allozierten Speicher.

Zitat:
Zitat:
Im Autodoc steht ausdrücklich, die Zeit kurz zu halten, während der die DOSList gesperrt ist. Besser wäre es also, die Namen in einen Puffer zu kopieren.
Beweise erst einmal, daß eine solche Kopieroperation tatsächlich schneller geht, als die mit der Print-Anweisung assoziierte write-Operation.

Öhm... in jedem Fall nicht langsamer? (Abgesehen davon hat man beim Zwischenpuffern die Daten auch nach der Ausgabe noch zur Verfügung; caching, re-use und Konsorten...)

Zitat:
Wenn eine einfache Write-Operation eine Modifikation der DOSList verursacht, ist dies definitiv ein Bug des darunterliegenden File-Systems.

Nebenbei gesagt, für mich bleibt es ein design-Fehler des AmigaOS, daß solche Deadlock-Gefahren überhaupt existieren...


Es geht hier wohl eher nicht darum, das die Liste sich ändern könnte, oder um Deadlocks, sondern daß das Programm bei Problemen mit der Write-Operation bei gesetztem Lock abbrechen könnte.

Das Vermeiden von Deadlocks ist eine akademische Kunst. Ist wie mit Speicherschutz: Perfekt geht nicht. Und wahrscheinlich haben sich die ur-Amiganer bei Deadlocks dasselbe gedacht wie bei Speicherschutz: Wenn wir's nicht perfekt hinbekommen können, dann lassen wir's ganz und freuen uns an der zusätzlichen Performance.

Man kann halt nicht auf der einen Seite die Effizienz des AmigaOS anpreisen und auf der anderen Seite Dinge fordern wie die perfekte Vermeidung von Deadlocks...
 
Solar   Nutzer

09.04.2003, 15:53 Uhr

[ - Direktlink - ]
Thema: Amithlon noch zu kaufen ?
Brett: Andere Systeme

Zitat:
Original von Thorty:
Was willste mit Amithlon? Schon mal von WinUAE gehört?

Was stört Dich an WinUAE (bitte mal auflisten!)


Ich mische mich mal ein:


  • UAE benötigt ein Hostsystem, das getrennt administriert werden will;
  • UAE bietet weniger Leistung;
  • UAE bietet keine Möglichkeit für "native" Plug-Ins (wer's mag).


Dazu kommt, das ich persönlich unter UAE ein Timing-Problem habe, mit dem mir noch niemand helfen konnte, das aber anscheinend nur mich betrifft (trotz Neuinstallationen, Up- und Downgrades etc. etc. pp.). Das die Uhr zu schnell geht, ist dabei nur ein Symptom, das bei Texteingabe Buchstaben sich wwwwwwwiiiiiiiieeeeeeederholen ein anderes.

(Nachtrag: Habe ich was von Link gesagt, als ich das "w" ein paarmal wiederholt habe? Steht da irgendetwas von "weh-weh-weh-punkt-" in meinem Text? Nein. Hallo Admins, Euer Forum hält sich für etwas zu schlau...)

[ Dieser Beitrag wurde von Solar am 09.04.2003 editiert. ]
 
Solar   Nutzer

09.04.2003, 15:13 Uhr

[ - Direktlink - ]
Thema: Schliessen eines Socket
Brett: Programmierung

Wo Du die Funktion findest, kann ich nicht sagen. Schließen solltest Du den Socket aber auf jeden Fall: bei einer einfach abgebrochenen Verbundung weiß der Server nicht, ob der Client noch da ist. Der Server hält die Verbindung offen, bis ein Timeout eintritt, der je nach Server ganz schön lange dauern kann. Im Extremfall gehen dem Server dann irgendwann die Verbindungen aus.
 
Solar   Nutzer

09.04.2003, 15:10 Uhr

[ - Direktlink - ]
Thema: Laufwerke Feststellen
Brett: Programmierung

Zitat:
Original von thomas:

Nein, das ist falsch. LockDosList gibt keinen gültigen DosEntry zurück. Du mußt mindestens einmal NextDosEntry aufrufen.


Sorry, hatte ich übersehen.

Aber so ist's ja noch besser:

code:
if ((dlist = (struct DosList*) LockDosList(flags)) == NULL)
{
    PutStr("Couldn't lock DosListn");
    return RETURN_FAIL;
}

while ((dlist = (struct DosList*)NextDosEntry(dlist, flags)) != NULL)
{
    ...
}


Zitat:
Oder

dl = NextDosEntry();
while (dl != NULL)
{
...
dl = NextDosEntry();
}

(so lernt man es beim Software-Engeneering).


Hm. Lehrbuch-SE: formal korrekt, praktisch unhandlich. Informatik-Studium?

Zumindest scheinen wir uns einig, was das break; angeht.
 
Solar   Nutzer

09.04.2003, 14:07 Uhr

[ - Direktlink - ]
Thema: Laufwerke Feststellen
Brett: Programmierung

Ich hätte einen syntaktischen Verbesserungsvorschlag zu machen. (Auf die Sache mit dem Puffer gehe ich jetzt mal gar nicht ein, ich habe mich zu sehr an die STL gewöhnt um das jetzt ad hoc richtig zu machen. ;-) )

code:
dlist = (struct DosList*) LockDosList(flags);
if (dlist == NULL)
{
    PutStr("Couldn't lock DosListn");
    return RETURN_FAIL;
}

while (dlist != NULL)
{
    name = (char*) BADDR(dlist->dol_Name)+1;
    VPrintf("Volume: %sn", &name); // FIXME: siehe oben
    dlist = (struct DosList*)NextDosEntry(dlist, flags);
}
UnLockDosList(flags);

return RETURN_OK;


Vorteile:


  • kürzer (um 4 Zeilen bzw. 22%);
  • Fehlerbehandlung da wo der Fehler auftritt, nicht am Ende der Funktion;
  • kein break, keine do-while "Endlos"-Schleife.


Zu letzterem... break ist nur unwesentlich "besser" als goto, und die "kanonische" Schreibweise für eine Endlosschleife ist eigentlich "for (;;)".

Und eine Endlosschleife mit einem break ist ein ziemlich sicheres Zeichen für einen vermurksten Algorithmus.

(Kein Angriff auf Holger; aber Lesbarkeit von Code ist genauso wichtig wie fehlerfreies funktionieren desselben.)

[ Dieser Beitrag wurde von Solar am 09.04.2003 editiert. ]
 
Solar   Nutzer

09.04.2003, 12:37 Uhr

[ - Direktlink - ]
Thema: Wohin will die USA
Brett: Get a Life

Zitat:
Original von Maja:
Wenn es bei diesem Krieg um Öl gehen würde, dann hätte man nicht den Irak angegriffen. Im Irak befinden sich gerade mal 15% der bekannten Ölvorkommen der ganzen Welt.


Überprüfe Deine Quellen, bzw. deren Bezugsgrößen.

Zitat:
http://www.spiegel.de/politik/ausland/0,1518,231854,00.html:


Die nachgewiesenen irakischen Ölreserven belaufen sich auf 150 Milliarden Barrel, das sind rund 15 Prozent der weltweit nachgewiesenen Reserven. Darüber hinaus verfügt der Irak noch über geschätzte Reserven von 215 Milliarden Barrel. Damit hat der Irak insgesamt rund 50 Prozent mehr Öl als Saudi-Arabien.


"Nur" 15% bedeutet, daß in keinem anderen Land der Welt so einfach ein so großer Anteil der Weltölreserven "annektiert" werden kann.

http://www.spiegel.de/politik/ausland/0,1518,grossbild-168239-239559,00.html

 
Solar   Nutzer

09.04.2003, 12:26 Uhr

[ - Direktlink - ]
Thema: Irakkrieg Ölquellen brennen, was kommt noch?
Brett: Get a Life

Zitat:
Aber gottseidank haben das schon viele andere vor ihnen versucht und, wie der Spiegel es nannte, starben allesamt an "imperialer Überdehnung". wenn Bush wirklich so ignorant ist (naja, er ist ja auch Amerikaner ...) daß er keine Vergleiche zu früheren "Supermächten zieht, geschieht es ihm recht. :angry:

Die Nebeneffekte solch einer "imperialen Überdehnung" sind allerdings immer schon Krieg, Vertreibung und der Tod unzähliger eigentlich Unbeteiligter gewesen...
 
Solar   Nutzer

09.04.2003, 12:23 Uhr

[ - Direktlink - ]
Thema: Auf Socken weniger elektrostatische Aufladung?
Brett: Get a Life

Die größte Aufladungsgefahr besteht in der Reibung bestimmter Materialien aneinander. Oft übersehen wird aber auch die Aufladung, die z.B. beim Aufstehen vom Schreibtischstuhl entstehen kann. (Wer hat nicht schon einmal beim Aussteigen aus dem Auto eine von der Tür gewischt bekommen?)

Wenn bei Beginn der "Baumaßnahme" geerdet wird, und man auf solche Dinge wie Haarekämmen oder Sitz-Reggae-Schubbeleien verzichtet, dürfte sich die Aufladung während der Arbeit in engen Grenzen halten. Man berührt auch recht häufig das Gehäuse, was ebenfalls zum Potentialausgleich beiträgt.

Man darf nur nicht vergessen, nach dem Aufstehen und Herumlaufen (...ich brauche doch noch einen anderen Schraubendreher...) sich erneut zu entladen.

Ich persönlich passe mein "Entladungsverhalten" auch dem betroffenen Bauteil an. Wenn ich den Sitz eines IDE-Kabels überprüfe, dann reicht mir, kurz vorher ja das Gehäuse berührt zu haben. Beim Einbau einer neuen CPU bin ich da etwas paranoider... ;-)

(Warnung an Besitzer von Plastiktowern: Das oben gesagte trifft natürlich nur auf Metalltower zu...)
 
Solar   Nutzer

09.04.2003, 12:13 Uhr

[ - Direktlink - ]
Thema: Schönbohm über Folter
Brett: Get a Life

http://www.spiegel.de/panorama/0,1518,243992,00.html


Wenn ich den Artikel richtig interpretiere, gab es zum Zeitpunkt der Folterandrohung kein Geständnis - das kam erst später.

(Wobei mein Standpunkt bestehen bleibt: Man hat solange als unschuldig zu gelten, bis die Schuld in einem ordentlichen und gerechten Verfahren festgestellt wurde. Und selbst nach der Schuldfeststellung lehne ich die Folter unter allen Umständen ab.)
 
Solar   Nutzer

31.03.2003, 10:57 Uhr

[ - Direktlink - ]
Thema: Irakkrieg Ölquellen brennen, was kommt noch?
Brett: Get a Life

Ich stimme zu, die Gegenwart können wir kaum ändern. Wohin es mit der Zukunft geht... ich finde, die aktuellen Drohgebärden der USA gegenüber Iran und Syrien bestätigen meine schlimmsten Befürchtungen. Wer nicht für die USA ist, ist gegen sie, und die USA sehen sich weder durch UNO, Scham oder gesunden Menschenverstand daran gehindert, ihre Machtposition auch auszuspielen.

http://www.spiegel.de/politik/ausland/0,1518,242776,00.html
 
Solar   Nutzer

30.03.2003, 16:00 Uhr

[ - Direktlink - ]
Thema: Ford Cougar-Tuning - ein paar Fragen
Brett: Get a Life

Zitat:
Original von Gutzi:
Aber mal aus reiner Neugier: wieviel Tuning ist denn in Deutschland erlaubt? In der Schwiz z.B. darf man die Motorleistung um 20% tunen, ohne die Karre neu vorführen zu müssen. Wie siet das bei euch aus?


StVZO §19, http://verkehrsportal.de/stvzo/stvzo_19.php3.
 
Solar   Nutzer

29.03.2003, 14:04 Uhr

[ - Direktlink - ]
Thema: Irakkrieg Ölquellen brennen, was kommt noch?
Brett: Get a Life

@ Askane:

Selbst bei "taktischen" Nuklearwaffen ist der Verseuchungsradius größer als 500m. Die Zahl, die Du da im Kopf hast, bezieht sich höchstwahrscheinlich auf einen Fall, bei dem das waffenfähige Material ausgetreten ist, nicht explodiert...

@ thomash:

Gegen Alpha-Strahlung kann man sich zwar leicht schützen - aber wenn man sich nicht schützt, ist sie aufgrund ihrer Eigenschaften wohl die gefährlichste Strahlungsart. Und welcher Zivilist kann einen Uran-Gefechtskopf z.B. von einem Wolfram-Schwermetall-Gefechtskopf unterscheiden, und sich entsprechend schützen?

Abgesehen davon haben noch nicht einmal die USA oder die Russen die Auswirkungen solcher Exponierung erschöpfend erforscht.
 
Solar   Nutzer

28.03.2003, 19:08 Uhr

[ - Direktlink - ]
Thema: Irakkrieg Ölquellen brennen, was kommt noch?
Brett: Get a Life

Zitat:
Original von Askane:
Bei den A-Waffen gab es eine Verseuchungsweite
von bis zu 200 oder 500 m. So genau weiß ich das jetzt nicht mehr.


Da hast Du aber zumindest ein "k" vor dem "m" vergessen...
 
Solar   Nutzer

27.03.2003, 16:38 Uhr

[ - Direktlink - ]
Thema: Irakkrieg Ölquellen brennen, was kommt noch?
Brett: Get a Life

Weil die einfache Antwort nur in den seltensten Fällen die richtige ist, und nur die richtigen Antworten zu den richtigen Fragen führen.

IMHO.
 
Solar   Nutzer

27.03.2003, 12:51 Uhr

[ - Direktlink - ]
Thema: Irakkrieg Ölquellen brennen, was kommt noch?
Brett: Get a Life

Zitat:
Original von Holger:
Zitat:
Original von Solar:
Um einen chemischen Angriff zu führen, braucht es nicht nur die C-Waffen, sondern auch die Mittel sie "unter's Volk" zu bringen. Wie ich schon einmal sagte, einfach rein in die Granate und ab dafür bringt's nicht wirklich.

Aber geeignete Raketen mit 150km Reichweite waren Saddam Hussein ja erlaubt.

Es geht nicht um Reichweite. Bei B- und C-Waffen ist ein Aufschlag- oder selbst ein Abstandszünder denkbar ungeeignet. Optimal wäre ein langsam fliegendes Objekt mit einer Sprühanlage, oder eine ähnliche Einrichtung zur großflächigen Verteilung des Stoffes. (Denk' mal an die Unkrautvernichter-Flugzeuge, die sich die WTC-Attentäter in den Monaten zuvor angesehen hatten.)

Zitat:
Zitat:
Als ob Mossad, CIA und Konsorten das nicht ganz simpel mit einem Scharfschützengewehr erledigen könnten.
Dann rückt einfach nur ein anderer anti-amerikanischer Diktator nach. Die USA wollen aber einen pro-amerikanischen Diktator.

Genau. (Von wegen demokratische Wahlen.) Und warum wohl?

Zitat:
Nur der Wiederaufbau wird mit irakischen Öl finanziert. Er beinhaltet natürlich den Aufbau von Industrieanlagen der Ölkonzerne, danach gehen die Einnahmen natürlich an den Besitzer dieser neuen Anlagen. Was wohl nicht der Irak sein wird, schließlich haben ja die Amerikaner die Anlagen wieder neu aufgebaut, nicht die Iraker. Außerdem gehörten die Anlagen ja vor dem Krieg schon dem Irak und wozu soll so ein Krieg gut sein, wenn die Anlagen hinter her wieder dem Irak gehören?

Na also, damit sind wir uns in der Sache ja einig.

@ hillking:

Auch ohne Illuminaten und Weltverschwörung ist internationale Diplomatie schon dreckig genug.
 
 
Erste << 97 98 99 100 101 -102- 103 104 105 106 107 >> Letzte Ergebnisse der Suche: 3680 Treffer (30 pro Seite)

Suchbegriffe
Schlüsselwörter      Benutzername
Suchoptionen
Nur in diesen Foren suchen
   nur ganze Wörter
Nur Titel anzeigen
alle Treffer anzeigen

.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.