Hier kann über allgemeine Themen diskutiert werden, die sonst in kein Forum passen.
Insbesondere über Szene, Games, Kultur, Weltgeschehen, Persönliches, Recht, Hard- und Software.
Chromanoid hat geschrieben:Ich halte zwei Schilder für sinnvoll. Insbesondere wenn dann auch noch freie Durchfahrt für Fahrräder dazu kommt. Dann weiß ich als Fahrradfahrer, dass mir dort ggf. Autos entgegenkommen.
Okay, das wäre dann ein klitzekleiner Nutzen für Radfahrer.
auch jemand der falsch aus einer Einbahnstraße kommt, hat bei rechts vor links soweit ich weiß Vorfahrt
Jemand, der fälschlicherweise aus einer komplett gesperrten Straße kommt, dann doch auch?
Chromanoid hat geschrieben:auch jemand der falsch aus einer Einbahnstraße
Es gibt einen Unterschied zwischen Einfahrt verboten und Einbahnstraße. Bei ersterem darf man theoretisch in der Straße, die mit einem "Einfahrt verboten"-Schild gekennzeichnet ist, wenden und in die andere Richtung fahren, solange es kein Einbahnstraßenschild gibt. Das unterstützt dann auch Deine rechts-vor-links These.
Das eine sagt halt "du kommst hier nicht rein!", das andere "andersrum kommst du rein".
Gesperrte Straßen sind mit Sondererlaubnis befahrbar (Anlieger, Nutzfahrzeuge, Baustellenfahrzeuge, Lieferverkehr etc. - z.B. durch Zusatzschild oder Ausweis).
(Hab nochmal geändert, bei dem Rest bin ich mir nicht ganz sicher)
Zuletzt geändert von joeydee am 20.09.2017, 15:07, insgesamt 1-mal geändert.
Es geht imho eher darum dass du beim Einfahrt Verboten Schild zwingend mit Verkehr aus der Richtung rechnen musst. Du darfst da in diese Richtung zwar nicht rein, aber andere können da raus. Und evenutell sogar Vorfahrt haben. Und das Schild zeigt dir dass du wohl von der anderen Seite rein kannst. Denn das steht meist am Ende von Einbahnstrassen.
Beim Durchfahrt Verboten Schild ist das nicht so. Da ist die Durchfahrt generell verboten. Aus beiden Richtungen. Manchmal ist das Ding aber in Verbindung mit Zusatzschildern zu finden. Landwirtschaftliche Gerätschaften oder Lieferverkehr frei. Dir kann da also unter Umständen trotzdem was entgegenkommen ^^
Krishty, das mit den Schildern hat schon seinen Sinn. Stell dir vor dir wird eine Adresse gegeben bei der du jemand besuchen willst/sollst: bei der Anfahrt zur Adresse siehst du an der Zielstraße das EInbahnstraßenschild: alles, was du deinem "Ziel" vorwerfen kannst, ist dass es kompliziert zu erreichen ist. Stell dir vor, du siehst das Gesperrt-Schild: derjenige der dich zur Adresse geschickt hat, ist ein Troll.
Zwei Schilder, zweil Situationen. Daher nicht identisch.
Unterschiedliche Keyboard Layouts sind doch was feines. Da machste eine Keymap die für das deutsche Keyboardlayout optimiert ist, mit y, x und c nebeneinander weils so super bgequem ist. Und deine User meckern dich dann an wieso Y so weit weg sein muss von X und C. Und wieso man da nicht einfach Z nimmt. Denn auf dem amerikanischen Layout ist Y und Z vertauscht ...
Das schlimme ist, ich weiss es doch. Wieso denk ich da nicht dran? O_O
Du kannst die Keymap vielleicht nach Scancodes definieren statt nach Virtual Keys. Mit WASD muss man das z.B. unbedingt machen, sonst beschweren sich die kanadischen Spieler, dass sie kreuz und quer über die Tastatur greifen müssen ;)
Ist ja nicht so, als ob ich das nicht kommen gesehen hätte.
I am happy to note that this suggestion has been at the very top ever since I wrote it more than five years ago. To understand its popularity, one can simply enter "billion dollar mistake" into any search engine.
Non-nullability is difficult to retrofit into a language like C#. There are many approaches, who solve the problem to varying degrees. Furthermore, the discussion is tricky, because people easily mix up the semantics of initialization, nullability, and optionality.
Sie mussten sich ja unbedingt an Java orientieren statt an richtigen Sprachen! :D
If you are looking very beautiful call girls in Chandigarh area at very affordable prices provide your places hotels and room with safe and secure escorts agency. http://www.kajrai.in/
(ich hoffe ich finde eines Tages mal die Zeit mir das selben anzuschauen - ich mache seit Jahren Werbung dafür weil es so geil klingt, habs aber noch nicht wirklich getestet).
Ich habe jetzt einige Zeit mit Kotlin gearbeitet und es ist meine neue Lieblingssprache. Dort sind Objekte non-null by default und man kann sie optional mit ? versehen um null zu erlauben. Damit darf man dann keine normalen Funktionen mehr darauf aufrufen (könnte ja null sein). Dazu gehört mMn das tolle Feature flow-dependent typing:
val s: String? = foo()
println(s.length) // error, length auf nullable darf nicht aufgerufen werden
if (s != null)
println(s.length) // OK, im then-scope hat s den Typ String, nicht mehr String?
Bisher habe ich null und nullable nur äußerst selten gebraucht. Ein gutes Zeichen. NullReferenceExceptions können in Kotlin nur an ganz speziellen Punkten auftreten.
throw NullReferenceException() - explizit und wird quasi nicht verwendet
s!!.length - der Operator !! macht Object? zu Object und wirft wenn null (explizit und sollte man normalerweise nicht nutzen, kann aber beim interfacen mit java praktisch sein)
man ruft eine Java Funktion auf die intern wirft (nicht wirklich Kotlins Schuld)
leider möglich bei initialisierung von Objekten wenn man die Reihenfolge verranzt (Basisklassen-ctor ruft virtual function auf die auf uninitialisierte member in der aktuellen Klasse zugreift). Das hat aber noch keine Sprache richtig gelöst oder?
leider möglich bei initialisierung von Objekten wenn man die Reihenfolge verranzt (Basisklassen-ctor ruft virtual function auf die auf uninitialisierte member in der aktuellen Klasse zugreift). Das hat aber noch keine Sprache richtig gelöst oder?
Doch: C++. Virtual function call in Basisklassen Ctor ruft die Implementierung der Basisklasse auf. Macht auch Sinn: Zum Zeitpunkt da der Basisklassen Ctor läuft, ist der dynamische Typ des Objektes das gerade konstruiert wird logischerweise noch der Typ der Basisklasse und noch nicht der des fertigen Objektes...
dot hat geschrieben:Doch: C++. Virtual function call in Basisklassen Ctor ruft die Implementierung der Basisklasse auf. Macht auch Sinn: Zum Zeitpunkt da der Basisklassen Ctor läuft, ist der dynamische Typ des Objektes das gerade konstruiert wird logischerweise noch der Typ der Basisklasse und noch nicht der des fertigen Objektes...
Das ist in der Regel aber dennoch ein Fehler und tut nicht das, was man möchte. Eine virtuelle Funktion soll überschrieben werden können um die Funktionalität zu erweitern/ändern. "virtual function calls" in C++ im Ctor sind de facto nicht virtuell wie du sagst.
Beispiel auf das ich schon ein paar Mal reingefallen bin: Basisklasse hat eine "virtual void init();", abgeleitete Klasse überschreibt init und implementiert Initialisierungscode. init wird im Ctor von der Basisklasse aufgerufen. Verhält sich nicht wie gewollt.
Ein weiterer CMake / C++ / Umgebungsvariablen sind doof Rant:
Ich versuche pbrt zu kompilieren, welches diverse Abhängigkeiten über git-Submodule einbindet. Unter anderem zlib und ptex, welches zlib als Abhängigkeit hat. Letzteres wurde erst neulich hinzugefügt und nach dem merge kompilliert bei mir nichts mehr. Wegen Fehler mit ZLIB. 2 Stunden später habe ich jetzt rausgefunden, dass ptex eine falsche zlib version einbindet (kleine Spaßstatistik: Ich habe es nie selber installiert und trotzdem an 18 verschiedenen Orten eine zlib.h rumliegen... - und 11 zlib.dll's - wieso benutzen Leute eigentlich noch immer dynamisches linken??). Die falsche Version findet er bei Anaconda, was eigentlich eine Python Distribution ist. Ein weiterer Beweis dafür, dass Umgebungsvariablen einfach nicht funktionieren, wenn eine Python-Installation meinen C++ Compiler kaputt machen kann. Das CMake Skript von pbrt kann zwar zlib aus dem eingebundenen Submodul benutzen, tut das aber nur, wenn kein anderes zlib gefunden wurde. Alternativ wäre es jetzt natürlich auch schön gewesen, wenn man ptex einfach hätte sagen können, dass es die zlib Version im Nebenordner benutzen soll, aber Submodule auch noch zu ändern macht deren Benutzung in git auch nicht einfacher.
Ich mag es ja schon nicht, wenn man vor Benutzung Programme selber kompilieren muss. Aber CMake schießt den Vogel definitiv damit ab, dass ich jedes zweite Script selber debuggen muss, weil einfach nie irgendetwas funktioniert. Und weil Menschen für Dinge die eigentlich trivial zu kompilieren sein sollten hunderte und tausende Zeilen CMake Code schreiben, die ansich zu 80% aus Fixen bestehen, die abstruse Ausnahmefälle abfangen, die irgendwann bei irgendeinem mal aufgetreten sind. Man hat echt das Gefühl dass das Ziel "läuft auf allen Systemen automatisch" durch ein "wir Coden für jedes System einen neuen Hack" erreicht wird.
Software ist natürlich nicht drauf vorbereitet, weil bisher jedes EXE-/DLL-Tool versucht, dort einen Zeitstempel zu lesen. Markierung ist das höchstwertige Bit. Die DLLs in System32 werden also seit dem Creators Update mit zufälligen Daten ab 2038 angezeigt.
Ich jammere, weil es so schön bequem war. Man musste kein Datum/Zeit in seine EXE schreiben. Ich brauchte meine Plugins nie nach Versionsnummern fragen, weil ja Zeitstempel drinlagen. Man konnte die Stempel weder vergessen noch vermasseln, weil sich der Linker drum gekümmert hat. Und jetzt? Alles kaputt. Nie kann ich was Schönes haben.
Nachtrag: Menschen die in CMake Scripte Dinge schreiben, die offensichtlich nur auf einer Plattform funktionieren können,
SET(ZLIB_LIBRARY "${CMAKE_CURRENT_BINARY_DIR}/src/ext/zlib/$<CONFIGURATION>/zlibstatic.lib")
Unter Linux ist die Lib aber anscheinend: src/ext/zlib/libz.a d.h. falscher Ordner, falscher Name und falsche Endung.
bestätigen meine neue These, dass CMake Scripte zu 100% aus Hacks und Fixes bestehen, und für absolut jedes neue System um weitere Fixes und Hacks erweitert werden müssen, weil nie irgendetwas von alleine funktioniert was offensichtlich auch niemals so geplant gewesen sein kann, denn so spektakulär kann man gar nicht scheitern können. Statt 10 verschiedene Projektdateien für verschiedene Plattformen und Compiler zu haben, hat man in CMake einfach alle 10 Projekte in eine einzelne Datei gepackt, die insgesamt länger ist als die Summe ihrer Bestandteile (das nennt man dann wohl Emergenz?) und in einer vollkommen unleserlichen und inhärent missverständlichen Syntax geschrieben ist.
Jonathan hat geschrieben:[...] meine neue These, dass CMake Scripte zu 100% aus Hacks und Fixes bestehen, und für absolut jedes neue System um weitere Fixes und Hacks erweitert werden müssen, weil nie irgendetwas von alleine funktioniert was offensichtlich auch niemals so geplant gewesen sein kann, denn so spektakulär kann man gar nicht scheitern können. Statt 10 verschiedene Projektdateien für verschiedene Plattformen und Compiler zu haben, hat man in CMake einfach alle 10 Projekte in eine einzelne Datei gepackt, die insgesamt länger ist als die Summe ihrer Bestandteile (das nennt man dann wohl Emergenz?) und in einer vollkommen unleserlichen und inhärent missverständlichen Syntax geschrieben ist.
Danke für die Bestätigung. Manchmal denke ich mir echt, CMake kann doch gar nicht SO schlecht sein, ich muss doch irgendetwas falsch machen, das muss doch nur mir so gehen, sonst würde das doch niemand freiwillig benutzen... Gut zu wissen, dass ich nicht an Realitätsverlust leide. Wobei die Alternative eigentlich tatsächlich weniger traurig wäre...
Jonathan hat geschrieben:Gut zu wissen, dass ich nicht an Realitätsverlust leide.
Definitiv nicht. Was du da oben beschreibst deckt sich zu 100% mit meinen Erfahrungen...von denen ich in diesem Fall leider mehr hab als mir lieb ist...
Ich wurde gebeten, für VersaTile Travis-CI zu verwenden, damit eben für versch. Systeme automatisiert Builds gemacht werden. Sollte ja eigentlich nich so schwer sein?
Nur: Ubuntu 14.04 hat folgende Probleme:
a) Alter GCC, nutzt by-default noch C++98
b) Altes Qt (4.8)
c) Neuestes Qt in den Paketquellen ist 5.5, ich nutze aber 5.9, da dort das OpenGL-Handling massiv verbessert wurde (und das QGLWidget aus Qt4 endgültig als deprecated markiert wurde)
d) Alte Pakete von: Assimp, GLM, ...
GRAH! Zum Glück nutze ich QMake und nicht CMake, aber wirklich viel gibt sich das leider auch nicht, was den platformabhängigen fuckup angeht.
War mal MasterQ32, findet den Namen aber mittlerweile ziemlich albern…
Ich nutze ja den FF nun schon seit vielen Jahren. Aber diesmal haben sie es echt geschafft. Gerade Version 56 runtergeladen. Ich finde NICHTS wieder. Er ist für mich UNBENUTZBAR geworden. So einen umständlich verqueren Usabilitymist kann man doch eigentlich nur auf Droge verzapfen -.-
Ich kann sowieso nicht nachvollziehen, wieso absolut jeder alle paar Jahre wieder und mancher sogar noch öfter meint, die ganze UI seiner Software unbedingt kaputt verschlimmbessern zu müssen. Was zur Hölle reizt alle so daran, alles daran zu setzen, möglichst viele Nutzer zu vergraulen?
"Mir ist auch klar, dass der Tag, an dem ZFX und Developia zusammengehen werden der selbe Tag sein wird, an dem DirectGL rauskommt."
DirectGL, endlich ist es da :)
"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
YouTube hat geschrieben:Appreciate the feedback, this update helps make sure channels linking to external websites are compliant w/ our Community Guidelines.
Meine Güte, irgendwie regt mich diese Ausdrucksweise auf. Als ob es drum ginge, dass das Update dabei hilft, die schönen neuen und guten Regeln in voller Qualität beim Kunden ankommen zu lassen - meine Güte, das Update ist doch egal, die neuen Regeln sind das Problem. Wieso kann man nicht einfach einmal ehrlich sein, es weiß doch eh jeder, was gemeint ist. Ungefähr so:
Honest YouTube hat geschrieben:We don't really care about what you think. We felt like changing the rules and now force everybody to follow them with all our might.
(Was übrigens ok ist - niemand sollte dazu gezwungen werden können, eine bestimmte Dienstleistung zu bestimmten Konditionen anbieten zu müssen. Und Youtube ist immerhin ein kostenloser State-of-the-Art Video Hoster, sowas will man eigentlich gar nicht selber machen. Wie es dann mit Gleichstellung aussieht ist nochmal eine andere Frage, aber eigentlich ist das Problem nicht die neuen Regeln von YouTube, sondern der monopolisierte Markt)
Jonathan hat geschrieben:(Was übrigens ok ist - niemand sollte dazu gezwungen werden können, eine bestimmte Dienstleistung zu bestimmten Konditionen anbieten zu müssen. Und Youtube ist immerhin ein kostenloser State-of-the-Art Video Hoster, sowas will man eigentlich gar nicht selber machen. Wie es dann mit Gleichstellung aussieht ist nochmal eine andere Frage, aber eigentlich ist das Problem nicht die neuen Regeln von YouTube, sondern der monopolisierte Markt)
Bis letztes Jahr habe ich mich übrigens noch gefreut, dass Vimeo und YouTube bei der Google-Suche gefühlt gleich behandelt wurden. Jetzt ist das aber auch Geschichte; bei keine Videos, die ich gern auf Vimeo gesehen habe, tauchen jetzt noch vorn in der Suche auf. Nur die YouTube-Versionen.
(Wobei man natürlich auch argumentieren könnte, dass die mehr Views haben, und deshalb für die Sucher interessanter sind.)
Zig