Diskussion C-Projekt in VSCode - Welche Einstellungen?

Mat

Aktives Mitglied
Ich wollte mal ein bisschen VSCode ausprobieren für die Arbeit mit C.

Eigentlich hatte ich ein Problem beim Kompilieren per VSCode-Task auf einem Netzlaufwerk.. das Programm wurde nie erzeugt und es kam immer Exit Code 1. Aber es hat sich herausgestellt, dass da nur ein Virenschutz dazwischengefunkt hat. Das hat sich erledigt.

Ich kann aber bei der Gelegenheit mal nachfragen, ob noch jemand anders C in Visual Studio Code schreibt und wie ihr das bei euch eingerichtet habt.

Ich wollte mir eine Projektvorlage fertigmachen, die ich dann für neue Projekte weiterverwenden kann. Gedacht war dabei kein zusammenhängendes großes Projekt, sondern eher eine Sammlung von einzeln ausführbaren C-Programmen (also ich brauche kein CMake).

Mein Aufbau (noch nicht fertig):

Code:
Projektordner
|___ .vscode
|        |___ projekt.code-workspace
|        |___ tasks.json
|        |___ launch.json
|___ src1
|        |___ main.h
|        |___ main.c
|        |___ main.exe
|___ src2
         |___ main.c
         |___ main.exe

projekt.code-workspace:
{
    "folders": [
        {
            "path": ".\\.."
        }
    ],
    "settings": {},
    "extensions": {
        "recommendations": []
    }
}

tasks.json:
{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "Build",
            "type": "shell",
            "command": "${env:USERPROFILE}\\scoop\\apps\\gcc\\current\\bin\\gcc.exe",
            "args": [
                "${file}",
                "-o",
                "${fileDirname}\\${fileBasenameNoExtension}.exe"
            ],
            "group": "build"
        },
        {
            "label": "Dump",
            "type": "shell",
            "command": "${env:USERPROFILE}\\scoop\\apps\\gcc\\current\\bin\\objdump.exe",
            "args": [
                "--disassemble",
                "${fileDirname}\\${fileBasenameNoExtension}.exe",
                "--line-numbers",
                "--wide",
                ">",
                "${fileDirname}\\${fileBasenameNoExtension}.dump"
            ],
            "dependsOn": "Build"
        }
    ]
}

Launch.json fürs Debuggen ist fast unverändert.. hab nur den GDB-Pfad eingetragen:
launch.json:
{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "gcc.exe - Aktive Datei erstellen und debuggen",
            "type": "cppdbg",
            "request": "launch",
            "program": "${fileDirname}\\${fileBasenameNoExtension}.exe",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "miDebuggerPath": "${env:USERPROFILE}\\scoop\\apps\\gdb\\current\\bin\\gdb.EXE",
            "setupCommands": [
                {
                    "description": "Automatische Strukturierung und Einrückung für \"gdb\" aktivieren",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ],
            "preLaunchTask": "C/C++: gcc.exe build active file"
        }
    ]
}
 
Warum benutzt du kein Buildsystem für die vielen Einzelprojekte? Es ist nicht aufwändig und macht vieles einfacher. CMake finde ich eher ungeil, aber in üblichen Linux/Unix Makes sind das vielleicht ein dutzend Zeilen, weit weniger seltsam als das ganze JSON. Man müsste ggf. auch mit CMake einfach Globbing nutzen können(auch wenns keine gute Idee ist), da hat man dann gleich noch Unterstützung für Konfigurationen und so mit drin.

ich würde definitiv sowohl gdb als auch GCC noch viel mehr Optionen mitgeben. Wenn du zum Beispiel GDB benutzen willst solltest du mit GCC alles mit -Og kompilieren, damit du mit dem Output möglichst viel anfangen kannst, ggf. willst du mit strip noch ein paar sections entfernen und so weiter.

Vielleicht etwas unrelated, aber es interessiert mich wirklich : warum zum Geier willst du diese komische Rendering-Engine mit furchtbarer Editorkomponente benutzen? Also was ist der Grund? Zwingt dich dein Arbeitgeber dazu? Warum nicht einen der wirklich guten Texteditoren die keinen Webbrowser brauchen die es gibt? Es interessiert mich wirklich, weil ich schlicht niemanden kenne, der diese Electron-Dinger für eine gute Idee hält oder nutzt xD
 
Zuletzt bearbeitet:
VSCode hab ich auf dem Tablet gerne als leichtgewichtigen IDE-Ersatz benutzt und dann auch immer häufiger mal auf dem PC. Es hat viele Plugins, der Arbeitsbereich lässt sich gut und portabel konfigurieren (die JSONs kann in einer UI oder per Hand mit Autovervollständigung bearbeiten), kleinere Build pipelines lassen sich damit auch ganz gut einrichten ohne dafür ein Skript schreiben zu müssen (inklusive ssh, wenn man möchte) und Remote Pair-Programming klappt auch ganz gut damit (LiveShare).

Du kennst niemanden, der Visual Studio Code benutzt? Verwechselst du das vielleicht mit Atom? Soll man stattdessen vi benutzen? Tastenkombinationen bis zum Abwinken lernen und Makros schreiben müssen, um grundlegende Funktionalität zu erhalten sagt mir nicht so sehr zu. Würde vielleicht infrage kommen, wenn ich täglich damit arbeiten würde.. aber tue ich nicht. Code-Snippets, Bearbeitung mehrere Codestellen gleichzeitig und Suchen&Ersetzen mit Regex klappt auch wunderbar bei VSCode.

Warum benutzt du kein Buildsystem für die vielen Einzelprojekte? Es ist nicht aufwändig und macht vieles einfacher. CMake finde ich eher ungeil, aber in üblichen Linux/Unix Makes sind das vielleicht ein dutzend Zeilen, weit weniger seltsam als das ganze JSON. Man müsste ggf. auch mit CMake einfach Globbing nutzen können(auch wenns keine gute Idee ist), da hat man dann gleich noch Unterstützung für Konfigurationen und so mit drin.
Werde ich mir nochmal anschauen, aber so wie ich das gesehen hatte, kann ich da auch nicht mehr machen als ich in den JSONs sowieso schon mache. Würde sich aber vermutlich anbieten, wenn ich das unabhängig vom Editor machen will.

ich würde definitiv sowohl gdb als auch GCC noch viel mehr Optionen mitgeben. Wenn du zum Beispiel GDB benutzen willst solltest du mit GCC alles mit -Og kompilieren, damit du mit dem Output möglichst viel anfangen kannst, ggf. willst du mit strip noch ein paar sections entfernen und so weiter.
Wird gemacht, danke
 
@Lowl3v3l VSCode: Es kommt da vielleicht ein bisschen auf die Sprache an, in der man primär unterwegs ist, aber VSCode ist grundsätzlich schon äußerst beliebt und verbreitet ‒ Microsoft war selbst vom Erfolg überrascht. Vor allem im Web-Bereich ist das gefühlte Editor-Ranking 49% VSCode, 49% IntelliJ und der Rest ist ein Gemisch aus Edelgasen. Unter den Electron-Editoren sollte man besonders VSCode nicht unterschätzen, da es wirklich performant ist: Viel schnellerer Start als IntelliJ, auch um einiges performanter als Atom. Und wird sehr schnell weiterentwickelt, was ich bei vielen anderen Editoren vermisse. (Quality of Life-Changes, Unterstützung neuer Sprachfeatures, Accessability-Updates...)

Die launch.json ist die Verknüpfung zwischen dem VSCode-Debugger und deinem Programm, damit es weiß, was der "debug"-Button überhaupt tun soll. IntelliJ regelt das z. B. über einen Dialog und die Einstellung dazu liegt dann... irgendwo. Der große Vorteil eines JSONs ist hier: du kannst es kopieren, sichern, anderen Leuten geben. Da man ein npm-Script debuggen kann, müsste das prinzipiell auch mit make, cmake usw. gehen. Man muss ggf. nur recherchieren, wie man das konfiguriert oder mit etwas Glück gibt es ein Plugin, das die Konfiguration erstellt.

@Mat Um etwas Feedback zur Ordnerstruktur zu geben: Es ist auch fast schon eine eigenständige Diskussion, aber IMO gehört die *.code-workspace nicht ins Projekt. Ich sammle die immer in meinem Projekte-Hauptordner (C:\projects). Darin befinden sich persönliche Einstellungen, die nur für dich Sinn ergeben. Im Projekteordner würde das sonst im Git-Repo landen, wo auch andere darauf Zugriff haben. Wenn andere auch ihre Config reinhauen, bekommst du eine ganze Sammlung an Projekt-Konfigurationen. Wenn du mal schnell das Repo löschen und neu clonen willst, würdest du die Datei und damit deine Projekt-Konfiguration verlieren (vorausgesetzt sie liegt im Projektordner, steht aber im .gitignore). Ggf. auch bei einem Branch-Wechsel unter bestimmten Voraussetzungen. Das möchte ich gerade aber nicht ausprobieren.

Neu seit der aktuellen Version (1.47) ist doch auch das Feature, eine einzelne Datei direkt zu debuggen. (https://code.visualstudio.com/updates/v1_47#_single-file-debugging) Vielleicht ist das auch was für dich.

Ob ich jetzt mehrere Programme in einen Projekt verwalten würde, weiß ich ehrlich gesagt nicht. Kommt wohl auf den Umfang und Einsatzzweck der Programme an und wie leicht es ist, zwischen den Programmen zu wechseln. Das musst du vielleicht für dich selbst herausfinden, ob du damit klarkommst.
 
Vielleicht etwas unrelated, aber es interessiert mich wirklich : warum zum Geier willst du diese komische Rendering-Engine mit furchtbarer Editorkomponente benutzen? Also was ist der Grund? Zwingt dich dein Arbeitgeber dazu? Warum nicht einen der wirklich guten Texteditoren die keinen Webbrowser brauchen die es gibt? Es interessiert mich wirklich, weil ich schlicht niemanden kenne, der diese Electron-Dinger für eine gute Idee hält oder nutzt xD
Dann mach doch mal Vorschläge für vergleichbare Editoren mit einem ähnlichen Funktionsumfang und Erweiterbarkeit.
Mag sein, dass VSCode unter Windows für C/C++ nicht das Mittel der Wahl ist, aber unter Linux (nativ oder via WSL) funktioniert das bestens.
 
Zuletzt bearbeitet:
IMO gehört die *.code-workspace nicht ins Projekt. Ich sammle die immer in meinem Projekte-Hauptordner (C:\projects). Darin befinden sich persönliche Einstellungen, die nur für dich Sinn ergeben. Im Projekteordner würde das sonst im Git-Repo landen, wo auch andere darauf Zugriff haben. Wenn andere auch ihre Config reinhauen, bekommst du eine ganze Sammlung an Projekt-Konfigurationen. Wenn du mal schnell das Repo löschen und neu clonen willst, würdest du die Datei und damit deine Projekt-Konfiguration verlieren (vorausgesetzt sie liegt im Projektordner, steht aber im .gitignore). Ggf. auch bei einem Branch-Wechsel unter bestimmten Voraussetzungen. Das möchte ich gerade aber nicht ausprobieren.

Bei Eclipse ist das mit den Workspaces von Haus aus so geregelt (also Einstellungen in einem übergeordnetem .metadata-Ordner oder so und dafür "saubere" Projektordner). Es hat mich immer ein bisschen gefreut wegen der klaren Struktur und ein bisschen gestört, weil alle Projekte im Workspace zu sehen sind. Auch wenn ich das eigentlich nur für private Projekte benutzen wollte, hast du da aber Recht. Bei VSCode kann man ja zum Glück pro User, pro Workspace und pro Ordner Einstellungen überschreiben. Das ist da also sehr flexibel.
 
Vielleicht etwas unrelated, aber es interessiert mich wirklich : warum zum Geier willst du diese komische Rendering-Engine mit furchtbarer Editorkomponente benutzen? Also was ist der Grund? Zwingt dich dein Arbeitgeber dazu? Warum nicht einen der wirklich guten Texteditoren die keinen Webbrowser brauchen die es gibt?

Man muss da schon differenzieren. Ich bin auch kein Fan von Webanwendungen, die blind in einen Electron-Container gesteckt werden, und Anwendungen wie Atom hatten und haben Performanceprobleme. VS Code ist aber aus meiner Sicht ein sehr gut durchdachtes Produkt.

Microsoft hat sich extra Erich Gamma ins Boot geholt, der zuvor an der Architektur von Eclipse gearbeitet hat und die dort gesammelten Erfahrungen in VS Code einbringen konnte. Dadurch wurden einige Dinge fundamental anders gelöst: Man hat erkannt, dass Code Completion und andere Features für eine Sprache am besten in der jeweiligen Sprache implementiert werden. Anstatt diese Features direkt in den Editor zu packen, hat man also das Language Server Protocol implementiert, was obendrein den Editor leichtgewichtig hält. Das Extension-System wurde ebenfalls überdacht, sodass die Anzahl der Extensions die Editor-Performance nicht beeinflusst. Auch als Prozesssicht sind Extensions nun entkoppelt und kommunizieren über RPC mit dem Editor, sodass ein Fehler in einer Extension nicht mehr die Funktionsfähigkeit des Editors beeinflusst.

Mir ist kein Editor am Markt bekannt, der diese Probleme bei gleichem Funktionsumfang besser löst.
 
Oha, da hab ich ja in ein Wespennest gestochen, ich hoffe ich vergesse nichts.

@Mat was ich oben vergessen habe: du willst unbedingt Warnings anschalten, das minimal vertretbare Warning-Set für gcc ist eigentlich "-Wall -Wextra -Wpedantic", da solltest du aber vmtl. noch deutlich mehr einzelne dazu packen, -Wshadow zum Beispiel ist, wenn ich mich recht entsinne, in den dreien überhaupt nicht erfasst.

Vielleicht als erstes mal zum Beliebtheitsargument: ich bin davon generell nicht überzeugt. Jede Menge Zeug, das technisch keine gute Idee ist ist verbreitet oder sogar beliebt, das sagt ziemlich wenig aus. Es ist zum Beispiel auch verbreitet, man könnte auch sagen beliebt, AES mit unsicheren Chaining-Verfahren wie CBC zu benutzen oder Passwörter nicht vernünftig zu hashen ;)

Bei den genannten Features(getrennte Formatter, Regex-Suche,"Performanter als Atom") fällt mir vor allem ein schockierender Trend auf: das sind alles Sachen, die das normalste der Welt sein sollten. Jeder bessere Texteditor seit den 80ern hat die. Wenn vim oder emacs, beide über 30 Jahre alt, sowas haben fällt es mir schwer, die irgendwie als Alleinstellungsmerkmal zu sehen, das sollte eigentlich ziemlich normal sein, vernünftige Regex-Suchen zu unterstützen.
Ich bin nun bei graphischen Texteditoren nicht besonders bewandert, aber ich wäre sehr schockiert, wenn das nicht zumindest im Linux-Umfeld ALLE verbreiteten Editoren könnten.

"Ich will mich nicht einarbeiten" ist natürlich etwas das ich nicht entkräften kann. Dazu kann ich nur sagen: mein Anspruch an mich, meine Kollegen etc. ist, dass sie Werkzeuge haben die sie auch beherrschen und mit denen sie sich in angemessener Weise befassen, statt dem, ersten zu verfallen, der sagt das sei gar nicht nötig, ist es im Regelfall nämlich doch.

Dass ich niemanden kenne der ihn benutzt habe ich nicht gesagt. Ich habe gesagt dass ich niemanden kenne, der ihn benutzt und das für eine gute Idee hält, ich hab durchaus Leute im Bekanntenkreis, die ihn wegen Firmenanweisungen nutzen müssen, zum Beispiel weil die Firma sich entschieden hat, man bräuchte ja kein vernünftiges portables Build-System, wenn man das auch in JSON machen kann, was schon wieder keine technisch gute Idee ist, es gibt einen guten Grund für Buildsysteme.

Ein besseres Produkt nennen fällt mir natürlich schwer, denn die Frage ist: Wofür? Wenn man einen HTML-Renderer und XSS-Vulnerabilities für ein essentielles Feature eines TEXTEDITORS hält kann ich das nicht tun, denn ich halte das schon konzeptuell für unrettbaren Unsinn, weil das Design an dem Punkt, an dem ich mich Frage, ob mein Texteditor eine Webbrowser-Engine und node.js braucht, schon mehrfach falsch abgebogen ist, denn es geht immerhin um einen Texteditor, nicht um einen Webbrowser.

Insbesondere bezog sich meine Frage auf die Nutzung als Texteditor. Und da warte ich immer noch, das ist der Hauptpunkt warum ich die Notwendigkeit dieses ganzen Dinges anzweifle, auf irgendein technisches Argument oder Feature, das mir das Warum begründet. Nach all dem was hier aufgezählt wurde kann ich nur schließen : "Cool, da hat jemand ein unnötiges Projekt gebaut, indem er einen Texteditor mit unnötigen Sicherheitslücken und Bloat geschrieben hat, der keine signifikanten Features bietet, die meine 30 Jahre alten Editoren nicht hätten, dafür aber das 10-fache an Hardwareleistung braucht, sinnvolle Tools wie Buildsysteme aushebelt und ein Vendor-Lock-In schafft, damit sich niemand mehr in seine Tools einarbeiten muss.". Okay, diese Abwägung kann man sicher treffen, ich würde sie nicht treffen und jedem davon abraten das zu tun versucht, denn was dabei herauskommt sieht man in der IT-Landschaft zur Genüge.

Darum stelle ich die Frage nach dem Use-Case, denn "ich will nicht lernen müssen, meinen Editor zu benutzen" ist mir dann doch etwas wenig ;)

MfG
 
Ihr könnt mich hier komplett ignorieren. Als jemand der seine Brötchen nicht damit verdienen muss, habe ich nicht allzu viel dazu beizutragen.
Ich nutze werder VS Code, noch EMACS. Grund ist einfach, ich brauche beide nicht notwendigerweise. Und für das Bisschen was ich an Code schreibe, ist es tatsächlich ein Argument, an was ich gewohnt bin und mit was ich zurecht komme.
Wenn nun VS Code irgendeine Browserfunktionalität mitbringt, dann mag des Scope Creep sein. Es ist aber ebenso Scope Creep, so was als Argument dagegen zu verwenden, nur weil ich ein Feature nicht nutzen will.
Für mich liegen Vor- und Nachteile bei viel simpleren Dingen. Vintage Editoren kommen aus einer Zeit wo Maus ausschließlich dieses in Löchern lebende graue Tierchen war. Und da wirds interessant. Ohne Maus zu arbeiten ist gnadenlos schnell. Bis du den Mauspointer irgendwohin gerührt hast, bist du mit Tastaturbefehlen schon das dritte Mal am Ziel. Natürlich gibt es Tastaturshortcuts auch in den IDEs und moderneren Editoren, iteressanterweise nutzt sie kaum jemand ernsthaft bzw. durchgängig. Während solche Shortcuts ein gewisses Wiedererkennungspotenzial bei anderen Programmen haben, nutzen EMACS und Co. ihren eigenen Befehlssatz. Das ist ein Argument dagegen, wohlgemerkt für mich als Hobbyist. Für jemand der den ganze Tag nichts anderes tut als Code zu schreiben, rückt das ggf. in den Hintergrund.
Und natürlich wäre es trotz Konzentration auf Tastatur einfach mal zeitgemäß, den einen oder anderen Mausinput so zu verarbeiten, wie man das auf einem halbwegs modernen Betriebssystem gewohnt ist und erwartet. Nehmen wir an, ich arbeite in einer IDE mit den Tastaturshortcuts und komme irgendwo an meine Grenzen weil mir nicht mehr einfällt was nun für irgendeine Aktion das richtige Kürzel ist, dann wähle ich das eben per Rechtsklick aus meinem Kontextmenü aus. Probier das mal bei EMACS.
Alles in Allem ist das also ähnlich einer Diskussion anzusehen, welche Programmiersprache denn nun die beste ist. Antwort ist immer: "Es kommt darauf an ..." Da wir also keinen Konsens finden werden, weil wir keine Chance haben einen finden zu können, bin ich dann auch mal wieder raus.
 
@german Ich weiß nicht was für nen Emacs du benutzt, aber ich hab ivy oder helm, wo ich ein Auswahlmenü zum durchscrollen habe wenn ich einen Befehl nicht kenne. Granted, ich hab das nicht auf irgendwelche Maustasten gebunden, weil ich das nicht so haben will, aber diese Funktionalität gibts. ;)

Aber ja, ich tu es dir dann wohl auch gleich.
 
Ah, VIM und Emacs, die einzig beiden Editoren die sich auch wirklich Editor nennen dürfen (abgesehen von ED, denn das ist sowieso der Standardeditor) :D

Wenn man einen HTML-Renderer und XSS-Vulnerabilities für ein essentielles Feature eines TEXTEDITORS hält kann ich das nicht tun
Hast du da mehr Informationen dazu? Habe jetzt auf Anhieb keine Meldungen zu XSS Lücken in VSCode gefunden (weder als CVE noch im Bugtracker). Oder pauschalisierst du hier, vergleichbar mit "Wenn man mit C oder C++ programmiert hat man Speicherfehler"?

Alles in allem kann ich deine Argumente nachvollziehen, habe selbst lange einen weiten Bogen um die HTML-Editoren gemacht (angefangen mit Brackets). Die Einschätzung "ist scheisse, weil html und nodejs" ist trotzdem sehr einfach gedacht. Zum Glück ist VSCode mit TypeScript programmiert, sonst wäre die fehlende Typisierung von JavaScript der letzte Sargnagel gewesen (deiner Argumentation nach) ;)

(BTW: Für (N)VIM gibt es mit COC das LSP von VSCode als Plugin, was auch in sehr vielen Installationen genutzt wird. So schlecht kann das alles dann doch nicht sein, oder? :D)
 
Zuletzt bearbeitet:
Nö ich sage nicht, dass es keine Editoren außer Vim und Emacs gibt, sind nur zum einen die mit denen ich mich am besten auskenne, und zum anderen schöne Extrembeispiele weil sie so alt sind ;) Gerade darum messe ich neuere Technologie gern daran^^
Ich hätte genauso basierend auf Kate argumentieren können, die hier gewünschten Features gibt es da auch alle, soweit ich das ersehen kann.

Der kleine Quib den du zitierst hat kam von mir, weil ich Electron-Apps im wesentlichen für nen HTML-Renderer mit Kollateralnutzen halte, sue me :p Und ja, ich halte auch TypeScript für Desktopanwendungen für nen Fehler (okay, eigentlich auch fast immer im Web), der aber natürlich nicht mit JavaScript vergleichbar ist(immerhin haben sich die TypeScript-Entwickler noch nicht öffentlich dafür entschuldigt, und es gibt kein Buch "TypeScript the good parts"). Ich verurteile da übrigens auch nur HTML so stark nicht weil ich speziell etwas dagegen hätte(okay doch, als Auszeichnungssprache ist es nicht gut, für beinahe alles will man lieber xhtml oder was ganz anderes benutzen), sondern weil ich das ganze Konzept, in Auszeichnungssprachen Programme zu schreiben für einen riesigen Fehler halte, der fundamental am Satz von Rice scheitert, wie man so oft und eindrucksvoll sieht ;)
Und nein, die Aufzeichnung was ich an Electron und den Electron-Editoren für konzeptuelle Schwächen sehe war bei weitem nicht vollständig, da könnte ich noch eine ganze Weile weiter ranten, nicht der letzte Punkt wäre die katastrophale Performance und dass es mit der Chromium-Engine einen gigantischen Haufen beinahe für niemanden zu durchblickenden Code als Single-Point-of-Failure gibt.

Und natürlich habe ich ein ganz konkretes Beispiel für XSS-Vulnerabilities in Electron, von den Electron Leuten selbst, siehe hier (auch wenn es etwas älter ist, es dient der Dramatik ganz gut) : https://www.cyberscoop.com/electron-remote-code-execution-xss-slack-skype/

MfG

P.S. : vorher war diese Vuln drin, die auch hart ist aber keine XSS, ich hab mich mit den Links vertan : https://www.electronjs.org/blog/webview-fix
 
Zurück
Oben Unten