Abo
  1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Sicherheit: Microsoft…

Java

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


  1. Java

    Autor: wire-less 23.07.19 - 07:15

    gehasst weil schlecht in Windows integriert aber als Basis von Android eine geniale Wahl. Wer mal C++ und Java programmiert hat und insbesondere mal nach einem Jahr wieder auf seinen Code guckt findet C++ einfach viel zu kompliziert. Auf C aufzusetzen war zwar nahelegend aber einfach keine gute Entscheidung. Schon der erste Stroustrup war viel zu dick. So ein GarbageCollector nimmt schon viel Fehlerquellen raus.
    Noch genialer wäre Smalltalk gewesen. Aber das konnte man einem C Programmierer nicht nahe bringen. Mit Java ist man da entgegengekommen und versucht in Richtung Smalltalk zu gehen.

  2. Re: Java

    Autor: Steffo 23.07.19 - 08:52

    Was hat Rust und Systemprogrammierung mit Java zu tun?

  3. Re: Java

    Autor: wire-less 23.07.19 - 09:09

    Steffo schrieb:
    --------------------------------------------------------------------------------
    > Was hat Rust und Systemprogrammierung mit Java zu tun?

    Der Wunsch von C++ wegzukommen hat was damit zu tun. Als MS diesen Weg beschritten hat gab's noch kein Rust. Wären die mit C++ glücklich würden die jetzt nicht suchen.

  4. Re: Java

    Autor: Steffo 23.07.19 - 10:23

    wire-less schrieb:
    --------------------------------------------------------------------------------
    > Steffo schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Was hat Rust und Systemprogrammierung mit Java zu tun?
    >
    > Der Wunsch von C++ wegzukommen hat was damit zu tun. Als MS diesen Weg
    > beschritten hat gab's noch kein Rust. Wären die mit C++ glücklich würden
    > die jetzt nicht suchen.

    Dass C und C++ solange noch so verbreitet sind, hat etwas damit zu tun, dass es bis vor kurzem noch keine Alternativen in der Systemprogrammierung und im High Performance Bereich gab. Rust ist hier die erste ernst zu nehmende Alternative.
    Ich finde daher, dass man GC-Sprachen mit GC-Sprachen vergleichen sollte. Vergleichst du bspw. Java mit C#, dann findest du Java gar nicht mehr so modern und gut leserlich. Mit .Net Core hat man ebenfalls Plattformunabhängigkeit.

  5. Re: Java

    Autor: Bonita.M 23.07.19 - 10:33

    > So ein GarbageCollector nimmt schon viel Fehlerquellen raus.

    Nicht freigegebener Speicher ist in C++ dank RAII eine extrem seltene Fehlerquelle.
    Ein GC ist aber dank der in Java nicht physisch schachtelbaren Objekte langsam.

    > Aber das konnte man einem C Programmierer nicht nahe bringen.

    Java find ich einerseits ganz angenehm, aber andererseits ist's nichts für Aufgaben wo Performance oder System-nähe gefragt sind.

  6. Re: Java

    Autor: apriori 23.07.19 - 11:42

    Ich finde die JVM und das Ökosystem um Java sehr gut (auf jeden Fall Welten besser als das von C++), aber die Sprache bleibt mir weiterhin ein Graus. Sie ist und bleibt zu verbos, auch die Streaming-API hat daran wenig geändert. Getter und Setter, generiert oder auch nicht, sind für mich zeremonieller Blödsinn. Die Annotations sind nett, aber ein Makrosystem wäre besser gewesen. Auf der JVM würde ich immer Scala Java vorziehen, auch wenn das extrem komplexe Typsystem "Ünterstützung" bei der Typinferenz braucht (ist ja in Rust oft nicht anders). Meine Präferenz kommt daher, dass ich "OOP um jeden Preis" ebenso für Quatsch halte. Hier erlaubt Scala deutlich flexiblere, zeitgemäßere Ansätze. Und Rust ist hier nicht anders.

    Dass C++ viel zu kompliziert ist, ist nur ein Problem. Das Tooling um C++ ist eine einzige Katastrophe. Es fühlt sich an, als müsste man ständig bei allem "Händchen halten" und "Babysitten".

    Angefangen bei dem archaischen Kompiliermodell, sind die Schwächen von C++ viel zu zahlreich.

    - Header mit Deklarationen, Cpp mit Implementierungen.
    Kein Doppelparsing, weil zu ineffizient, deshalb Forwarddeklarations nötig.
    - Präprozessor als stumpfer Textersetzer, kein echtes Makrosystem
    - Hacks um Teilfunktionen eines Makrosystems zu erfüllen (SFINAE)
    - Kein standardisiertes "Projektformat", VS sln/vcxproj höchstens, damit keine
    Chance für Tooling den Scope eines Projektes zu kennen.
    - stateful includes -> kein Modulsystem. Damit ist sowas wie Intellisense automatisch nur ultraineffizient umzusetzen.
    - libclang erst seit wenigen Jahren der erste freie Parser (deshalb hängt auch Refactoringtooling um über eine Dekade hinterher)
    - Customdeployments überall, null Konventionen/Standardisierung
    => damit ist auch der Entwurf eines Paketmanagers die Hölle auf Erden. Conan.io ist z.B. im wesentlichen der x-te Batchexecutor und Metadatenhasher. Vergleicht das mal mit einem Mavenprojekt oder cargo.
    - wirsche implizite Typkonvertierungen
    - silent undefined behavior
    - der Mindset der Community: Performanz über alles, wen kratzt schon Produktivität

    Ich könnte ewig so weiter machen. Ich nutze C++ seit mehr als 10 Jahren... und kein Techstack fühlt sich so dermaßen unproduktiv an (und ist es ganz nüchtern gemessen auch).

  7. Re: Java

    Autor: wire-less 23.07.19 - 12:04

    Bonita.M schrieb:
    --------------------------------------------------------------------------------
    > > So ein GarbageCollector nimmt schon viel Fehlerquellen raus.
    >
    > Nicht freigegebener Speicher ist in C++ dank RAII eine extrem seltene
    > Fehlerquelle.
    > Ein GC ist aber dank der in Java nicht physisch schachtelbaren Objekte
    > langsam.
    >
    > > Aber das konnte man einem C Programmierer nicht nahe bringen.
    >
    > Java find ich einerseits ganz angenehm, aber andererseits ist's nichts für
    > Aufgaben wo Performance oder System-nähe gefragt sind.

    Na ja. Wenn man mal sieht wie nah ans System Smalltalk 80 ging ... Die hatten auch schon performante Benutzeroberflächen auf 286/386 Systemen mit wenig Speicher. Der Trick waren die effizienten Datenstrukturen/Collections. (Ein paar optimierte Teile waren natürlich trotzdem native/in C integriert). Möchte nicht wissen wie viel Code auf meinem PC in wie viel Varianten eine Listeniteration/Hash/... (wie schlecht) implementiert.
    D.h. wenn Windows auf einer OO-Sprache basieren würde und der Code dafür auch für Apps wieder verwendbar wäre, könnte man super schlanke performante Systeme haben. Und wenn der Code immer wieder verwendet würde, hätte man auch einen Bruchteil der Bugs

  8. Re: Java

    Autor: Bonita.M 23.07.19 - 12:53

    Naja, wenn ich seh wie Smalltalk schon gg. Java ablost:
    https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/smalltalk.html
    ... dann möcht ich gar nicht erst wissen wie das ggü. C/C++ ist.

  9. Re: Java

    Autor: a user 23.07.19 - 13:04

    Bonita.M schrieb:
    --------------------------------------------------------------------------------
    > > So ein GarbageCollector nimmt schon viel Fehlerquellen raus.

    > Java find ich einerseits ganz angenehm, aber andererseits ist's nichts für
    > Aufgaben wo Performance
    Das gilt schon sehr sehr lange nicht mehr, wenn auch für alle Performance-Themen nicht gleich.

  10. Re: Java

    Autor: Bonita.M 23.07.19 - 13:07

    >> Java find ich einerseits ganz angenehm, aber andererseits ist's nichts
    >> für Aufgaben wo Performance

    > Das gilt schon sehr sehr lange nicht mehr, wenn auch für alle
    > Performance-Themen nicht gleich.

    Vergiss es, Java ist langsam!
    Mit gut optimietem C/C++ Code kannst Du es je nach Algorithmus ins Verhältnis 1:2 bis 1:5 setzen, seltener noch schlechter; entsprechende Zahlen liefert auch das Computer Languages Benchmark Game.
    Java ist schon recht komfortabel und wenn es ähnlich schnell wäre wie C/C++, dann hätte es längst andere Domänen wie State-of-the-Art Egoshooter oder HPC-Software erobert.

  11. Re: Java

    Autor: apriori 23.07.19 - 14:07

    Die Frage sollte doch hier sein, wie performant ist bereits idiomatischer Code (ohne irgendwelche Verrenkungen). Und hier ist selten Java wirklich schnell, das ist klar. Liegt aber nicht an der Sprache an sich (eine Sprache hat keine Performanz), sondern ihre Implementierung (wer braucht _wirklich_ ständige runtime reflection, einen forcierten, nicht optionalen GC etc.).

    Performanz ist aber nur ein Kriterium. Bedauerlicherweise hängt sich die C++ Community immer ausschließlich daran auf. Als würde es kratzen, ob ein Button in 5 ms oder in 50 ms reagiert. Es ist irrelevant. Überhaupt ist peak performance nur in Nischen relevant.

    Ich erachte Produktivität als deutlich wichtiger als peak performance. Und hier ist C++ einfach nur grottenschlecht und das wird von der C++ Community warum auch immer nie eingesehen. Ich frage mich ernsthaft, wie man ein Schunddesign wie CMake ernsthaft verteidigen kann. Es ist schrott. Ja, es ist wohl besser als autotools, aber verglichen mit jedem anderen Buildsystem(-generator) von anderen Sprachen einfach nur ein Witz.

    Was ist daran so verdammt schwer zu verstehen, dass sogar beides, bequeme Entwicklung, mit bequemen, produktiven Tools und peak runtime performance möglich ist? Nur halt nicht mit C++. C++ könnte dahin mal kommen, aber ausschließlich dann, wenn es seine alten Designfehler loswird und selbst dann sicher nicht in unter 10 Jahren Aufwand. Lohnt sich das? Ich würde sagen, nein.... andere Techstacks bieten das bereits heute schon.

  12. Re: Java

    Autor: Bonita.M 23.07.19 - 14:25

    > Die Frage sollte doch hier sein, wie performant ist bereits idiomatischer
    > Code (ohne irgendwelche Verrenkungen). Und hier ist selten Java wirklich
    > schnell, das ist klar.

    Nein, Java ist krass langsamer als C/C++ und somit nicht schnell.
    Siehe CLBG:
    https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/java.html
    https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/java-gpp.html


    > Liegt aber nicht an der Sprache an sich (eine Sprache hat keine Performanz), ...

    Doch, es gibt Sprach-Paradigmata die bestimmte Implementations-Spielräume vorgeben die eben die Performance beeinflussen. In Java liegt z.B. jedes Objekt einzeln auf dem Heap und ist nicht in-line in anderen Objekten allokierbar; dadurch brauchst Du sehr viel mehr Allokationen als in C/C++. Und das ist nur ein Detail unter vielen.
    Außerdem gibt es dynamisch getypte Sprachen die durch diese Typisierung viele Überprüfungen erst zur Laufzeit ermöglichen. Daher sind diese per-se langsamer und deine Theorie, dass eine Sprache per Definition nicht langsam sein kann hinfällig.

    > Ich erachte Produktivität als deutlich wichtiger als peak performance.
    > Und hier ist C++ einfach nur grottenschlecht ...

    Nö, je nachdem welche Classlibs Du hinzunimmst auch nicht schlechter als in Java.

    > Ich frage mich ernsthaft, wie man ein Schunddesign wie CMake ernsthaft
    > verteidigen kann.

    Das lastest Du C++ an? CMake ist nicht nach C++-Standard definiert.
    Ebenso hat Java kein inhärentes Build-System und ich könnte mir ein schlechtes raussuchen und sagen, dass Java deswegen schleht wäre.

    > Was ist daran so verdammt schwer zu verstehen, dass sogar beides, bequeme
    > Entwicklung, mit bequemen, produktiven Tools und peak runtime performance
    > möglich ist?

    Java Code ist langsam und frisst ohne Ende RAM. Außerdem ist es supernervig, dass die Anwendungen so langsam starten. Auf meinem 1800X dauert es ca. 40 Sekunden bis IntelliJ IDEA Ultimate gestartet ist. Und der MediathekView-TV-Browser braucht extrem viel Speicher. Das ist doch ätzend.



    2 mal bearbeitet, zuletzt am 23.07.19 14:34 durch Bonita.M.

  13. Re: Java

    Autor: apriori 23.07.19 - 15:08

    Du missverstehst mich. Das Argument "eine Sprache hat keine Performanz" hat weiter Gültigkeit.
    Es ist eine zwar gängige Interpretation, dass

    List<int> bla = new List<>();

    1. eine Allokation bedeutet
    2. diese auf dem Heap stattfindet

    aber absolut nichts in einer Sprachdefinition sagt genau das aus. Semantisch wird hier ein neues, initialisiertes Objekt erzeugt. Wie genau ist ein reines Implementierungsdetail der Codegenerierung und überhaupt nicht Eigenschaft der Sprache.

    Dass die Wahl des Typsystems Performanzimplikationen haben kann, ist klar. Muss es aber auch nicht. Solange wir noch keine brauchbaren dependent types Implementierungen haben, wird dem aber weiter so sein. Es ist aber ein krasser Äpfel- und Birnenvergleich, wenn man statisch typisierte mit dynamisch typisierten Sprachen vergleicht. Ohne dependant types sind dynamisch typisierte Sprachen fähig deutlich flexiblere Kontrollflüsse abzubilden (ein jeder Ausdruck kann den Typ verändern. Der analoge Boilerplate für eine statische Sprache dafür wäre unfassbar groß). Nur kann (und ich finde sollte) man argumentieren, dass diese Flexibilität eigentlich völlig überflüssig ist.

    Wenn du jedoch wolltest, könntest du ohne Probleme einen Java Compiler entwickeln, der am Ende gleiche Laufzeiteigenschaften des resultieren Programms erzeugt, wie das in C++ möglich ist. Dazu müsste die Implementierung der Sprache nur einiges anders machen, als es die JVM gegenwärtig macht und so z.B. runtime reflection vollständig verwerfen. Am Ende wäre es aber immer noch Java. Guck dir analog Scala-Native an. Die machen das Ganze für Scala. Am Ende ist und bleibt es immer noch syntaktisch Scala.

    Deswegen, sobald dynamische (Laufzeit-)Typisierung hinzu kommt, hast du recht, ansonsten aber nicht.

    Viele glauben fälschlicherweise, dass die Performanz der Sprach(-Implementierung) von C++ im Kern der Sprache zu finden ist - dem ist aber nicht so. Die Performanz kommt von Dekaden an Entwicklungen von Optimierungsheuristiken - und nicht mehr. Deswegen hat so ziemlich jede Sprache, die z.B. direkt LVVM-IR oder gar C erzeugt, direkt C-artige Performanz, solange die jeweilige Implementierungen alle Annotationen von LLVM-IR unterstützt.
    Genau deshalb ist die Performanzreligion um C++ kompletter Mumpitz. Man könnte jede beliebige statisch typisierte Sprache mit ähnlicher Performanz der jeweiligen Implementierungen versehen. Ob das am Ende schön zu lesen ist, sei mal dahingestellt. Bei Java müsste man dem Compiler viele Informationen über Annotations mitgeben, welche in C++ (in ihren Implementierungen) eine bestimmte, teils effiziente Interpretation haben.

    Zum Punkte CMake und allgemein Tooling um C++. Ich habe bereits eingängig beschrieben, woher die Probleme kommen, deswegen nur eine plakative Wiederholung mit "das schrottige Kompiliermodell ist schuld". Und, wenn ich natürlich in gleicher Konsequenz wie in diesem Posting weiter argumentiere: Die Sprache C++ ist daran nur teilweise Schuld (scheiss Grammatik, wenige alte freie Parser), sondern die grottige Implementierung, welche aber nunmal aus der Historie (Arbeitsspeicher war limitiert) gegeben wurde. Syntaktisch müsste "#include <iostream>" nicht bedeuten: "Klatsch den textuellen inhalt der Datei iostream hier hin" - das ist eine besonders schlechte Wahl der Implementierung.
    In Java war besonders Ant zum Kotzen. Quasi Scripting mit XML und kam aus der "absolut alles muss mit XML beschrieben werden"-Zeit.
    Was ich der C++ community schon ankreide ist im Vergleich zu Java das folgende:
    Es gibt kein standardisiertes Projektlayout. Guck dir das z.B. mal äquivalent für Java an. Alleine die primitive Konvention "src/$language/$packagepath/$sources" ist schon Gold wert. Die Buildtools wissen sofort mit welcher Sprache darin was zu übersetzen ist und wozu es gehört. Absolut lächerlich simpel.
    Bei CMake? Du darfst dich immer und immer wieder wiederholen und dem Generator Händchen halten. "Hier hast du übrigens diese Dateien, die sollen in diese Lib rein". Du willst das Refactorn? Bei Java schmeisst du die Datei einfach woanders hin (und die IDE wird motzen, dass der Paketpfad nicht dem FS-Pfad entspricht und es ändern wollen). Bei CMake? You're out luck. Da es keine Konventionen gibt, wo eine IDE diese dumme Dateiauflistung findet, darfst du sie wieder von Hand anpassen. Das ist lächerlich.

    Setz einfach mal von null an ein Projekt auf. In C++. Zwei libs, beide nutzen Boost, eine PCL, die andere OpenCV, eine Executable, welche gegen beide linkt. Zielsysteme: Linux, Mac, Windows, Android. Wie lange brauchst du? Du wirst ewig brauchen, weil es nichtmal einen plattformübergreifenden, brauchbaren Paketmanager gibt. Machst du etwas äquivalentes in Java (oder Rust), bist du in 2 min durch. Und das ist es, was zur Produktivität dazu zähle.
    In einem Ökosystem, in dem Codewiederverwendung (von 3rd party libs) derart umständlich und unbequem ist, wird auch genau das nicht passieren. Und ich habe es auch zu Genüge auf der Arbeit erlebt. Man stönt immer gleich, wenn es darum geht, eine externe lib auch nur in Betracht zu ziehen. Und das nicht nur, weil das Deployment zum Kotzen ist, sondern solche Libs mangels Concepts auch extrem intrusiv auf die Codebasis sind.

    Ich habe aber den verdacht, wir reden aneinander vorbei. Ich halte selbst Java (genauer die JVM) für langsam. Java als Sprache bedingt das jedoch überhaupt nicht. Und es ist klar, dass die Startgeschwindigkeit Mist ist, wenn die Anwendung dann erst durch den JIT gejagt wird. Diese Zeit wurde vorher auf C++-Seite schon vom Compiler verblasen (und damit jedem nachfolgenden Nutzer erspart). Ist aber wieder ein Äpfel- und Birnenvergleich.

  14. Re: Java

    Autor: 0110101111010001 23.07.19 - 15:20

    cmake ist doch quasi standard...

    und gegen implizite Konvertierungen gibts compiler warnings

  15. Re: Java

    Autor: Bonita.M 23.07.19 - 15:21

    > List bla = new List<>();
    > 1. eine Allokation bedeutet
    > 2. diese auf dem Heap stattfindet
    > aber absolut nichts in einer Sprachdefinition sagt genau das aus.

    Eine List wird wohl kauf auf dem Stack allokiert.
    Und das Objekt dazu kann nur per Escape-Analyse auf dem Stack gehalten werden, aber wenn die Referenz in ein anderes Objekt eingebettet ist, dann eben nicht mehr.

    > Wenn du jedoch wolltest, könntest du ohne Probleme einen Java Compiler
    > entwickeln, der am Ende gleiche Laufzeiteigenschaften des resultieren
    > Programms erzeugt, wie das in C++ möglich ist.

    Nö, das geht allein nicht bei dem Sprach-Paradigma das z.B. Speicher-inlining von Objekten in Objekte unmöglich macht aufgrund seiner Referenz-Semantik.

    > Dazu müsste die Implementierung der Sprache nur einiges anders machen,
    > als es die JVM gegenwärtig macht und so z.B. runtime reflection vollständig
    > verwerfen.

    Reflection ist garnichtmal das Thema. Die Methoden sind in Java üblicherweise implizit virtuell und daher hat jedes Objekt einen VMT-Pointer der auf eine Datenstruktur zeigt die eben die VMT beinhaltet aber auch die selbstbeschreibung der Datenstruktur für die Reflection. Das ist wirklich Pillepalle und kostet beim Initialisieren eines Objekts eine Store-Instruktion. Da gibt es ganz andere Probleme die Java nicht schnell implementierbar machen.

    > Viele glauben fälschlicherweise, dass die Performanz der Sprach
    > (-Implementierung) von C++ im Kern der Sprache zu finden ist - ..

    Das "glaubt" sogar Bjarne Stroustrup und dier anderen Experten die diese Sprache entworfen haben. C++ ist nach dem Paradigma entworfen: you don't pay for what you don't use (im Gegensatz zu obigem, dass in Java jede Klasse per se reflectable ist, auch wenn man sich das nicht ausgesucht hat) und die Sprachmittel sind bis auf RTTI und geworfene Exceptions auf Implementierbarkeit mit minimalen Overhead ausgelegt.

    > Deswegen hat so ziemlich jede Sprache, die z.B. direkt LVVM-IR oder gar C
    > erzeugt, direkt C-artige Performanz, ...

    Nein, denn eine Sprache höherer Ebene muss ja nicht viele Lowlevel-Möglichkeiten dieser (Zwischen)-Sprachen nutzbar machen und bietet auch oft nicht die Möglichkeit, auf implizite Highlevel-Funktionen zu verzichten.
    Oder anders gesagt: Du kannst auch sicher viele Scriptsprachen in C übersetzen; dadurch werdern die aber sicher nicht so schnell wie eine explizite Implementation in C.

    > Genau deshalb ist die Performanzreligion um C++ kompletter Mumpitz.

    Ja, alles nur Idioten beim Computer Languages Benchmark Game.

    > Zum Punkte CMake und allgemein Tooling um C++. Ich habe bereits eingängig
    > beschrieben, woher die Probleme kommen, deswegen nur eine plakative
    > Wiederholung mit "das schrottige Kompiliermodell ist schuld". Und, wenn ich
    > natürlich in gleicher Konsequenz wie in diesem Posting weiter argumentiere:
    > Die Sprache C++ ist daran nur teilweise Schuld (scheiss Grammatik, wenige
    > alte freie Parser), sondern die grottige Implementierung, welche aber
    > nunmal aus der Historie (Arbeitsspeicher war limitiert) gegeben wurde.
    > Syntaktisch müsste "#include " nicht bedeuten: "Klatsch den textuellen
    > inhalt der Datei iostream hier hin" - das ist eine besonders schlechte Wahl
    > der Implementierung.

    Macht nichts, kann man dennoch nicht C++ anlasten.
    Nen normaler Entwickler nutzt auch nicht solche Lowlevel-Projektverwaltungen, sondern die seiner IDE und bei portablen Code gibt es halt mehrere Projektfiles.



    1 mal bearbeitet, zuletzt am 23.07.19 15:28 durch Bonita.M.

  16. Re: Java

    Autor: apriori 23.07.19 - 15:30

    Die Verwendung des CMake-Generators ist also Standard....
    dann beschreibe mir doch bitte das standardisierte Projektlayout und wo dieses festgeschrieben ist, so dass z.B. weiteres Tooling damit arbeiten kann (z.B. statische Codeanalyse, oder Intellisense).
    Natürlich kann CMake das als Buildsystemgenerator nicht lösen, aber solange dies ungelöst ist, gibt es allerhöchstens Insellösungen. Es gibt hier seitens CMake nur die "compile_commands.json" (CMAKE_EXPORT_COMPILE_COMMANDS), welche eine stumpfe Aufzählung von Befehlen ohne jede Metainformation ist.

    Ich bezog mich z.B. auch bei den impliziten Konvertierungen auf integrale typen zu bool oder pointer zu bool.

  17. Re: Java

    Autor: Bonita.M 23.07.19 - 15:32

    > Die Verwendung des CMake-Generators ist also Standard....

    Nö.

    > dann beschreibe mir doch bitte das standardisierte Projektlayout und wo
    > dieses festgeschrieben ist, so dass z.B. weiteres Tooling damit arbeiten
    > kann (z.B. statische Codeanalyse, oder Intellisense).

    Ich verwende Visual Studio und CLion. Ersteres kennt kein CMake, letzeres nur optional.

  18. Re: Java

    Autor: 0110101111010001 23.07.19 - 15:34

    Visual Studio kennt CMake, und das schon eine ganze Weile.
    Und CLion erkennt CMake out of the box...

  19. Re: Java

    Autor: Bonita.M 23.07.19 - 15:35

    > Visual Studio kennt CMake, und das schon eine ganze Weile.

    Nutzt nur keiner!

    > Und CLion erkennt CMake out of the box...

    Ja, aber auch optional.

  20. Re: Java

    Autor: 0110101111010001 23.07.19 - 15:38

    quasi Standard - zumindest für open source libraries.

    > dann beschreibe mir doch bitte das standardisierte Projektlayout und wo dieses festgeschrieben ist, so dass z.B. weiteres Tooling damit arbeiten kann (z.B. statische Codeanalyse, oder Intellisense).

    Ist meines Wissens nicht notwendig.
    Dennoch findet man alle benötigten Infos dazu in CMakeLists.txt. Jedenfalls läuft mit CLion automatisch eine ganze Liste an static analysers im Hintergrund, beim commiten und beim Kompilieren darüber.

    EDIT: natürlich gibts trotzdem gewisse Konventionen für CMake Projekte...

    > Ich bezog mich z.B. auch bei den impliziten Konvertierungen auf integrale typen zu bool oder pointer zu bool.
    Ich kann nicht mit 100% Sicherheit sagen, dass integer -> bool erkannt wird, weil ich sowas vermeide, aber letztes mal ist er mir z.B. mit double -> float (oder umgekehrt) angesprungen.



    2 mal bearbeitet, zuletzt am 23.07.19 15:47 durch 0110101111010001.

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. OSRAM Opto Semiconductors Gesellschaft mit beschränkter Haftung, Regensburg
  2. Systemhaus Scheuschner GmbH, Hannover
  3. ENGAGEMENT GLOBAL gGmbH, Bonn
  4. CSB-SYSTEM AG, Geilenkirchen

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 116,13€
  2. 229,99€
  3. 44,53€ (Exklusiv!) @ ubi.com
  4. 25,00€ (Bestpreis!)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Disintegration angespielt: Fast wie ein Master Chief mit Privatarmee
Disintegration angespielt
Fast wie ein Master Chief mit Privatarmee

Gamescom 2019 Ein dick gepanzerter Held auf dem Schwebegleiter plus bis zu vier Fußsoldaten, denen man Befehle erteilen kann: Das ist die Idee hinter Disintegration. Golem.de hat das Actionspiel ausprobiert.
Von Peter Steinlechner

  1. Omen HP erweitert das Command Center um Spiele-Coaching
  2. Games Spielentwickler bangen weiter um Millionenförderung
  3. Gamescom Opening Night Hubschrauber, Historie plus Tag und Nacht für Anno 1800

Zephyrus G GA502 im Test: Das Gaming-Notebook, das auch zum Arbeiten taugt
Zephyrus G GA502 im Test
Das Gaming-Notebook, das auch zum Arbeiten taugt

Mit AMDs Ryzen 7 und Nvidia-GPU ist das Zephyrus G GA502 ein klares Gaming-Gerät. Überraschenderweise eignet es sich aber auch als mobiles Office-Notebook. Das liegt an der beeindruckenden Akkulaufzeit.
Ein Test von Oliver Nickel

  1. Vivobook (X403) Asus packt 72-Wh-Akku in günstigen 14-Zöller
  2. ROG Swift PG35VQ Asus' 35-Zoll-Display nutzt 200 Hz, HDR und G-Sync
  3. ROG Gaming Phone II Asus plant neue Version seines Gaming-Smartphones

Schienenverkehr: Die Bahn hat wieder eine Vision
Schienenverkehr
Die Bahn hat wieder eine Vision

Alle halbe Stunde von einer Stadt in die andere, keine langen Umsteigezeiten zur Regionalbahn mehr: Das verspricht der Deutschlandtakt der Deutschen Bahn. Zu schön, um wahr zu werden?
Eine Analyse von Caspar Schwietering

  1. DB Navigator Deutsche Bahn lädt iOS-Nutzer in Betaphase ein
  2. One Fiber EWE will Bahn mit bundesweitem Glasfasernetz ausstatten
  3. VVS S-Bahn-Netz der Region Stuttgart bietet vollständig WLAN

  1. UMTS: 3G-Abschaltung kein Thema für die Bundesregierung
    UMTS
    3G-Abschaltung kein Thema für die Bundesregierung

    Nutzer, die kein LTE in ihren Verträgen festgeschrieben haben, sollten wechseln, da 3G zunehmend abgeschaltet werde. Das erklärte das Bundesverkehrsministerium und sieht keinen Grund zum Eingreifen.

  2. P3 Group: Wo die Mobilfunkqualität in Deutschland am niedrigsten ist
    P3 Group
    Wo die Mobilfunkqualität in Deutschland am niedrigsten ist

    Die Qualität des Mobilfunks in Deutschland ist in den einzelnen Bundesländern sehr unterschiedlich. Dort, wo Funklöcher gerade ein wichtiges Thema sind, ist die Versorgung gar nicht so schlecht.

  3. Mecklenburg-Vorpommern: Funkmastenprogramm verzögert sich
    Mecklenburg-Vorpommern
    Funkmastenprogramm verzögert sich

    Wegen fehlender Zustimmung der EU ist das Geld für ein Mobilfunkprogramm in Mecklenburg-Vorpommern noch nicht verfügbar. Dabei hat das Bundesland laut einer P3-Messung große Probleme.


  1. 18:00

  2. 18:00

  3. 17:41

  4. 16:34

  5. 15:44

  6. 14:42

  7. 14:10

  8. 12:59