Wer arbeitet aktuell mit einer .net sprache und dem netframework und wird es in
-
Bin auf Grund von Projekttechnischer Änderung in ein "gemischtes" Projekt verschoben wurden, nach 15 Jahren C/C++ ....
Mein Anteil ist reines C# + .Net 3.5 auf Library / ConsolenApp - Basis (Plugins).
GUI geht komplett ueber web und da über Java (JSF, JavaFX).
Kommunikation via Soap / WSDL über mehrere Server /Serverarten hinweg.Mein Zuständiger Server ist nen IIS (Ohne User GUI)
Warum man das so macht, keine Ahnung, sind wohl zu viele Leute / Firmen beteiligt die unterschiedliche Schwerpunkte haben.
Ich leide ... ich leide sowas von
Ich werd wohl noch ganz paar Jahre brauchen, um meine natürliche C/C++ Paranoia im C# Code zu verlieren
Ich musste feststellen, das die glückliche .... alles oder nichts Philosophie, also entweder richtig, mit Performance und so im Messbereich, dann natürlich in C++ ... oder total auf Sparflamme, dann meist als Automatiesierung in Python, javascript, oder Visual Basic, oft in verbindung mit Office / Excel als GUI ersatz ... schon lange nimmer im Grossen Umfeld gelebt werden.
Wir haben mittlerweile verdammt viele Java und reines C# Projekte. Wobei wir zu 99,9999999999999999999999999999999999 % an Microsoft gefesselt werden ^^
Ciao ...
-
RHBaum schrieb:
Ich musste feststellen, das die glückliche .... alles oder nichts Philosophie, also entweder richtig, mit Performance und so im Messbereich, dann natürlich in C++ ... oder total auf Sparflamme, dann meist als Automatiesierung in Python, javascript, oder Visual Basic, oft in verbindung mit Office / Excel als GUI ersatz ... schon lange nimmer im Grossen Umfeld gelebt werden.
Nach meiner Erfahrung sind die Extreme in beiden Richtungen Seltenheit. Häufig ist der Mittelweg viel verbreiteter (Mittelweg in reiner Form ist imho etwas wie reines C#/Java; oder Mischung aus teilweise nativ mit langsameren Sprachen).
RHBaum schrieb:
Wir haben mittlerweile verdammt viele Java und reines C# Projekte. Wobei wir zu 99,9999999999999999999999999999999999 % an Microsoft gefesselt werden ^^
Also bei reiner Konsole und Webentwicklung fällt wohl in Zukunft die MS-Abhängigkeit zum Großteil bei C# weg (Wenn man nicht gerade Systemabhängige Teile benötigt). Ebenso kann man auch schon heute andere Systeme mit C# ansteuern (z.B. IOS und Android), wenn gleich man dann wieder eine andere Abhängigkeit hat.
-
Nicht-Deterministische Speicherverwaltung mit deterministischen Algorithmen macht doch überhaupt keinen Sinn.
-
DetRed schrieb:
Nicht-Deterministische Speicherverwaltung mit deterministischen Algorithmen macht doch überhaupt keinen Sinn.
Warum nicht?
-
Weil Algorithmen Datenstrukturen im Speicher brauchen. Diese müssen verwaltet werden. Wenn diese Verwaltung durch Willkür einer externen Instanz wie einem GC unterworfen wird, geht das Deterministische-Verhalten eines Teil der Arbeit mit den Datenstrukturen verloren. Das Ziel ist doch zu jeder Zeit zu Wissen wo mein Programm gerade steht, auch für das Debugging. Dies erreicht man nur durch durchgängigen Determinismus.
-
Diesbezüglich gibt es kein Problem.
Der GC arbeitet - wie jedes andere Computerprogramm - zu 100% deterministisch.
-
hustbaer schrieb:
Diesbezüglich gibt es kein Problem.
Der GC arbeitet - wie jedes andere Computerprogramm - zu 100% deterministisch.Wie dieses deterministische Verhalten genau aussieht ist aber großteils nicht definiert und kann daher von Implementierung zu Implementierung und Version zu Version variieren, wodurch es in der Praxis (insbesondere in Anbetracht der Tatsache, dass ein moderner PC ein hochgradig chaotisches System ist) was das betrifft nicht wirklich besser ist, als nicht-deterministisches Verhalten...
-
Außerdem kann man den Speicher schon vorher beschaffen, also häufig.
Ich finde Spieleentwicklung unter Android interessant, da ist der GC Performancemäßig so ein Problem dass man lernt Java ohne viel new zu schreiben.
-
Der GC arbeitet - wie jedes andere Computerprogramm - zu 100% deterministisch.
Meine Erfahrung gerade:
Ich bin ja quasi nu der Neuling, aber keiner der "Alten Hasen" kann mir genau sagen wie der GC denn genau funktioniert. Der GC scheint was Gottgegebenes zu sein ... das ist einfach da und funktioniert irgendwie
Und wenn ich da doofe fragen stelle ... naja, ich kann dann im Inet suchen.90% unserer Programmierer arbeiten eh auf ner ebene drüber.
Serialisierung, Dependency Injection, das sind so die Themen wo sie sich auskennen.Typisches Verhalten bei out of memory Problem:
Hint 1: Gib der runtime mehr speicher (der C# weg: kaufe 2 weitere Speicherriegel)
Hint 2: werfen wir doch den GC mal manuell an
Hint 3: schreib nen cron/at der den GC aller 5 min erzwingt
Hint 4: Tausche Bibliothek Versionen/Implementationen aus.Erst dann wird versucht dem Problem aufn Grund zu gehen ... und java z.b. hat da ja schon gute tools für. da träumt man als c/c++ entwickler nur von ^^
Ergo: Deterministic hilft ned viel, wenn man die Funktionsweise ned kennt, bzw nix mit zu tun haben will
Also bei reiner Konsole und Webentwicklung fällt wohl in Zukunft die MS-Abhängigkeit zum Großteil bei C# weg
Ja mag seien, aber bei uns ist genau so gottgegeben, das der PC wo man mit der Tastatur vor sitzt, nen M$ Betriebssystem hat. Und Webdienste/Intranet kommen ausm LAN Kabel / WLAN, wo am Ende irgendwie ne andere Firma verantwortlich für ist.
Also: wen intressierts ? (naja mich schon, ich bin aber nu hier die Ausnahme ^^)
Ciao ...
-
hustbaer schrieb:
Diesbezüglich gibt es kein Problem.
Der GC arbeitet - wie jedes andere Computerprogramm - zu 100% deterministisch.Für sich genommen ja, auf das gerade laufende Programm bezogen nein. Denn nur RAII bietet bis jetzt deterministische Ressourcenverwaltung für das laufende Programm.
-
Der Terminus Non-Deterministisch wird sogar bei Wikipedia verwandt:https://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29
Non-deterministic GC is incompatible with RAII based management of non-GCed resources. As a result, the need for explicit manual resource management (release/close) for non-GCed resources becomes transitive to composition. That is: in a non-deterministic GC system, if a resource or a resource-like object requires manual resource management (release/close), and this object is used as 'part of' another object, then the composed object will also become a resource-like object that itself requires manual resource management (release/close).
-
Das fehlen von automatischer, deterministischer Finalisierung hat mit dem GC nicht direkt viel zu tun.
Es gibt ne da gute Korrelation zwischen "verwendet das Systen nen GC" und "unterstützt das System automatische, deterministische Finalisierung" (wobei hier "ja" auf die 1. Frage stark mit "nein" auf die 2. korreliert), klar.
Deswegen ist das aber noch lange nicht das selbe.
Siehe z.B. Python.Bzw. auch in C# und sogar Java gibt es mehr-oder-weniger-automatische deterministische Finalisierung. Mittels "using" bzw. "try-with-resources". Ist nicht so angenehm zu verwenden wie in C++ und leider überhaupt nicht deppensicher, aber es ist da.
@RHBaum
Wie so ein GC funktioniert kannst du an vielen Stellen im Netz nachlesen. Wenn man es in 1-2 Sätzen zusammenfasst wird es zu ungenau, und es genau zu erklären würde viel zu lange dauern. Und davon abgesehen ist natürlich auch nicht jeder GC gleich.Mir ging es aber letztendlich nur darum dass GC nicht gleichbedeutend ist mit "wir können nix mehr deterministisch freigeben". Viele Programmierer programmieren zwar so, aber viele Programmierer sind halt auch einfach nur schlecht.
-
Rustiger schrieb:
Weil Algorithmen Datenstrukturen im Speicher brauchen. Diese müssen verwaltet werden. Wenn diese Verwaltung durch Willkür einer externen Instanz wie einem GC unterworfen wird, geht das Deterministische-Verhalten eines Teil der Arbeit mit den Datenstrukturen verloren.
Nein, warum sollte das so sein? Deinen Datenstrukturen ist die Arbeit des GC egal.
Rustiger schrieb:
Das Ziel ist doch zu jeder Zeit zu Wissen wo mein Programm gerade steht, auch für das Debugging.
Meinetwegen.
Rustiger schrieb:
Dies erreicht man nur durch durchgängigen Determinismus.
Wenn deine Algorithmen von deterministischer Ressourcenverwaltung abhängen, mußt du die Ressourcen explizit verwalten und freigeben (z.B. IDisposable oder Events). Dann spielt der GC sowieso nicht rein. Aber solange es nur um Arbeitsspeicher als Ressource geht, besteht eine solche Abhängigkeit meistens nicht.
Kurzum, von der Anwesenheit eines GC irgendwelche Schlüsse auf die allgemeine Vorhersagbarkeit von Algorithmen zu ziehen, ist sehr fragwürdig (man könnte auch sagen: Trollversuch). Es stimmt, daß der GC das Laufzeitverhalten in schwer absehbarer Weise beeinflußt, was bei zeitkritischen Anwendungen eine Rolle spielen kann (cf. Ethons Kommentar zu Spielen unter Android). Aber die Vorhersagbarkeit der Rechenergebnisse deiner Algorithmen sollte durch den GC nicht beeinträchtigt werden.
-
Alibikommentar zum Thema:
Zurzeit arbeite ich beruflich an verschiedenen Projekten in C#/WinForms. Das Berufliche wird sich in der nächsten Zeit noch ein paar Mal ändern, aber ich finde die Plattform sehr attraktiv und arbeite gern damit (nur WinForms nervt, da verwende ich lieber die VCL).
Von meinen privaten Projekten (die im Idealfall mal zu beruflichen Projekten werden) haben die meisten einen größeren C++-Anteil, aber ich setze auch dort zunehmend C# ein (mit .NET unter Windows und Mono unter Linux).
-
hustbaer schrieb:
Bzw. auch in C# und sogar Java gibt es mehr-oder-weniger-automatische deterministische Finalisierung. Mittels "using" bzw. "try-with-resources". Ist nicht so angenehm zu verwenden wie in C++ und leider überhaupt nicht deppensicher, aber es ist da.
Es ist vor allem deshalb nicht Deppensicher, weil selbst die MSDN-Beispiele häufig kein using enthalten, wo es eigentlich hingehört - und dann muss es auch nicht verwundern das viele andere Beispiele im Netz es nicht besser tun.
Und ich kann dir aus eigener Erfahrung sagen: In C++ mag man zwar erwarten das mit RAII-Objekten "deppensicher" Programmiert werden kann, wenn diese im Team dann aber doch nicht oder gar dynamisch alloziert verwendet werden, nützt dies nichts
-
audacia|off schrieb:
Aber die Vorhersagbarkeit der Rechenergebnisse deiner Algorithmen sollte durch den GC nicht beeinträchtigt werden.
Um die Ergebnisse des Algos geht es auch nicht, sondern es geht darum dass ich die Implementierung Schritt für Schritt verfolgen will um Engpässen oder Fehler zu finden. Der Determinismus ist mir beim Debuggen meiner Implementierung nicht gegeben, wenn ich einen GC nutze.
-
Rustiger schrieb:
Um die Ergebnisse des Algos geht es auch nicht
Aha. Die Anfangsbehauptung war "Nicht-Deterministische Speicherverwaltung mit deterministischen Algorithmen macht doch überhaupt keinen Sinn". Wenn wir uns einig sind, daß die Ergebnisse vom GC unbeeinträchtigt bleiben, sind wir von "überhaupt kein Sinn" schon weit entfernt. Wenn der GC nur dein Debugging-Erlebnis beeinträchtigte, wäre das höchstens noch "im Alltag lästig".
Rustiger schrieb:
sondern es geht darum dass ich die Implementierung Schritt für Schritt verfolgen will um Engpässen oder Fehler zu finden. Der Determinismus ist mir beim Debuggen meiner Implementierung nicht gegeben, wenn ich einen GC nutze.
Immer diese unbelegten Behauptungen über schwammige Begriffe. Du wirst dich wohl kaum von einem Abstraktum wie "Determinismus nicht gegeben" beim Debuggen gehindert fühlen.
Sag doch mal, was sich konkret beim Debuggen verändert, wenn es einen GC gibt. Ein konkretes Beispiel?
-
@RHBaum
Wie so ein GC funktioniert kannst du an vielen Stellen im Netz nachlesen. Wenn man es in 1-2 Sätzen zusammenfasst wird es zu ungenau, und es genau zu erklären würde viel zu lange dauern. Und davon abgesehen ist natürlich auch nicht jeder GC gleich.Das war nurn Besipiel, ich weiß wien GC grob funktioniert, und das es unterschiede im Detail gibt.
Eher erschreckt mich, wie wenig Sorgen man sich um Speicherverbrauch, Laufzeitverhalten und so macht ... ^^
Ciao ...
-
audacia|off schrieb:
Ein konkretes Beispiel?
Bei jeglicher Optimierung eines Algos. Du weist schon das RAM-Zugriffe zu meiden sind wo es nur geht? Nur was im Cache bearbeitet werden kann ist wirklich schnell, bei allem anderen dreht die CPU Däumchen.
Ich habe aber hier keine Lust dir das Programmieren zu erklären, da gibt es zig Videos auf Youtube die das besser können. Bei einem GC hast du nicht die Kontrolle über den Programmfuß, zu dem auch immer Speicheranforderung und Freigabe gehört. Aus ganz vielen Threads hier kannst du raus lesen, wie gefährlich es ist sich NICHT um die Speicherverwaltung selbst zu kümmern. Da wird auch erklärt warum und dass es eigentlich so gut wie unmöglich ist ein Projekt was sich nie um Speicher gekümmert hat und dann versagt im Nachhinein noch zu kitten. Du kannst eben nicht immer nachvollziehen wie und wann der GC zuschlägt.
Hier hat Xin mal was darüber geschrieben : https://www.proggen.org/doku.php?id=start:cppjava
-
Rustiger schrieb:
Ich habe aber hier keine Lust dir das Programmieren zu erklären
Ich habe um ein Beispiel gebeten. Daß du darauf enerviert und mit einer Herablassung antwortest, deute ich mal so, daß dir keines einfällt
Rustiger schrieb:
Bei einem GC hast du nicht die Kontrolle über den Programmfuß
Schon wieder so eine allgemeine Behauptung. Klar hast du das.
Rustiger schrieb:
Aus ganz vielen Threads hier kannst du raus lesen, wie gefährlich es ist sich NICHT um die Speicherverwaltung selbst zu kümmern.
Das gilt mit GC genau wie ohne. Ein GC bedeutet keineswegs, daß man sich überhaupt keine Gedanken über die Speicherverwaltung machen müßte. Aber die Probleme sind halt andere als ohne GC.
Rustiger schrieb:
Da wird auch erklärt warum und dass es eigentlich so gut wie unmöglich ist ein Projekt was sich nie um Speicher gekümmert hat und dann versagt im Nachhinein noch zu kitten.
Gilt auch ohne GC.
Rustiger schrieb:
Hier hat Xin mal was darüber geschrieben : https://www.proggen.org/doku.php?id=start:cppjava
Xin hat einen guten Ansatz geliefert, aber scheitert an der Realität. Kann ich leider nur bedingt ernstnehmen. Außerdem kann ich mir Pamphlete zu beliebigen Themen auch selber googlen. Ich hab dich (!) nach einem (!) konkreten (!) Beispiel gefragt.
