×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
現在エディタはVSCodeを使っている。
以前はAtomを使っていたのだが、数ヶ月前にVSCodeを使ってみるとかなり軽くて動作も安定していてすぐに乗り換えた。
ターミナル環境はなしで、C++コンパイラにはMinGW-w64を使い、BOOSTは自前でビルドしていた。
特にBOOSTのビルドが面倒くさかった・・・。
ところがこの数ヶ月でVSCodeとコンパイラ周りに色々問題が発生してしまい、1から環境構築を行うことになった。
1からVSCodeのターミナル内でビルド実行できるまで環境構築を行ったので、今度困らないようにメモしておく。
自分用メモではあるが、他人が見ても使えるように説明も入れておく。
といっても、コンパイラ環境構築はMSYS2を使ったら一瞬だった。
Linuxかよ。
ターミナル環境しゅごい・・・。
試しにClangも入れてみたが、Clangの方がエラーメッセージが見やすい気がするので乗り換えた。
gccに依存しているようなので、#include <bits/stdc++.h>も自分で作ることなく使える。
もちろんAtCoder等に提出の際はgccを選ぼう。
2019/11/11追記
VScode 3.task.json
"presentation": "panel"とコンパイルオプションと説明等を一部編集
コンパイル&実行を高速にする書き方の追加
終わり。
競技プログラミングの環境構築とは書いたものの、普通のC++コーディングも同じ環境で行っている。
そちらではC++17を使用している等、主にtask.jsonは変更しているが。
競技プログラミングでも早く構造化束縛使わせて。
これだけ書いておけば新しいパソコンを買っても大丈夫だ!
自分で好き勝手設定したあの膨大なUncrustifyの設定ファイルだけは無くすととても嫌な気持ちになるから気をつけよう・・・。
後この忍者ブログとかいうサイトわざわざ<br>入れても自動で消してくるのさすがに頭おかしい。
以前はAtomを使っていたのだが、数ヶ月前にVSCodeを使ってみるとかなり軽くて動作も安定していてすぐに乗り換えた。
ターミナル環境はなしで、C++コンパイラにはMinGW-w64を使い、BOOSTは自前でビルドしていた。
特にBOOSTのビルドが面倒くさかった・・・。
ところがこの数ヶ月でVSCodeとコンパイラ周りに色々問題が発生してしまい、1から環境構築を行うことになった。
1からVSCodeのターミナル内でビルド実行できるまで環境構築を行ったので、今度困らないようにメモしておく。
自分用メモではあるが、他人が見ても使えるように説明も入れておく。
といっても、コンパイラ環境構築はMSYS2を使ったら一瞬だった。
Linuxかよ。
ターミナル環境しゅごい・・・。
試しにClangも入れてみたが、Clangの方がエラーメッセージが見やすい気がするので乗り換えた。
gccに依存しているようなので、#include <bits/stdc++.h>も自分で作ることなく使える。
もちろんAtCoder等に提出の際はgccを選ぼう。
2019/11/11追記
VScode 3.task.json
"presentation": "panel"とコンパイルオプションと説明等を一部編集
コンパイル&実行を高速にする書き方の追加
コンパイラ関連
-
MSYS2(64bit)をインストール。
-
pacman(パッケージ管理システム)をアップデート
pacman -Syuu -
Clangをインストール
pacman -S mingw-w64-x86_64-clang
(pacman -Ss clangで名前が変わっていないか等パッケージ検索できる) -
BOOSTをインストール
pacman -S mingw-w64-x86_64-boost
(これだけ!ビルドいらない!) -
gdbをインストール(オプション デバッグするなら)
pacman -S mingw-w64-x86_64-gdb
VSCode
-
公式拡張機能C/C++をインストール
-
setting.jsonに以下を追加(GUIでも可)
"C_Cpp.default.compilerPath": "C:\\msys64\\mingw64\\bin\\clang++.exe", "C_Cpp.default.cppStandard": "c++14", "C_Cpp.default.cStandard": "c11", "C_Cpp.default.intelliSenseMode": "clang-x64",
-
tasks.json
{ // See https://go.microsoft.com/fwlink/?LinkId=733558 // for the documentation about the tasks.json format "version": "2.0.0", "tasks": [ { "label": "build c++", "type": "shell", "command": "clang++", "args": [ "${relativeFileDirname}\\${fileBasename}", "-std=gnu++14", "-DLOCAL", "-g", "-O2", "-o", "${relativeFileDirname}\\${fileBasenameNoExtension}.exe", ] }, { "label": "build & run C++", "type": "shell", "command": "chcp.com 65001; ${relativeFileDirname}\\${fileBasenameNoExtension}.exe", "dependsOn": [ "build c++", ], "group": { "kind": "build", "isDefault": true }, "presentation": { "panel": "shared" } }, { "label": "run C++", "type": "shell", "command": "chcp.com 65001; ${relativeFileDirname}\\${fileBasenameNoExtension}.exe", "group": { "kind": "test", "isDefault": true }, "presentation": { "panel": "shared" } } ] }
文字コードがUTF-8を前提とすると、ターミナルで実行すると文字化けする(と思う)。
これを解決するには"chcp.com 65001"等でターミナルの文字コードを変更する必要があるが、最初に一度実行しただけではダメ。
パネルは一緒でも内部的にはおそらく新しいターミナルで実行されているので、毎回実行の前に毎回文字コードを変更する必要がある。
現状他の手段は知らないが、こう書くと"Active code page: 65001"がプログラムの切れ目の判別にも使えて良いかも。
VSCodeのターミナルで実行するかどうかは個人差があると思うが、この方が楽だと思う。
特にWindowsは自動でサンプルケースを実行してくれるツール等の導入が面倒なので、手動でやるならせめて少しでも楽したい。
なお、コンパイルオプションの-DLOCALは、LOCALを定義することでローカル環境のみで機能するマクロを実現するために入れている。
2019/11/11追記
この書き方だとコンパイル&実行がかなり遅い。
まずdependsOnでタスクを呼び出すのが遅いのと、文字コードの変更を途中に挟むと一度クリアが挟むからなのか遅くなる。
ということで頭悪そうだが以下のようにベタ書きするとかなり早くなる。
ターミナルから直接コンパイル&実行した時と比べて明らかに遅いのは、VSCode内部で処理が入っているからだと思っていたが、このように書けば遜色ない速度になる。
プログラムもタスクの設定もベタ書きが最速だぜ!
{ "label": "debug build c++", "type": "shell", "command": "clang++", "args": [ "${relativeFileDirname}\\${fileBasename}", "-std=gnu++14", "-W", "-DLOCAL", "-o", "${relativeFileDirname}\\${fileBasenameNoExtension}.exe", ] },
-
ビルド用のショートカットキーを編集
デフォルトでは"Shift+Ctrl+B"でビルドタスクの実行になっており、上記の設定ではコンパイルと実行がこれで行える。
2回目以降の実行でもコンパイルをするのは無駄なので、テストタスクの実行をショートカットキーにすると時間の節約になる。
自分は"Ctrl+Alt+B"に設定している。
おそらくmakefileを使えば1つのコマンドで無駄なコンパイルも無くせるが、フォルダごとにmakefileを作るのは面倒なのでこの形式にしている。
ファイル名を取得してmakefile1つだけでうまくやる方法もありそうだが、makefileはあまり詳しくないので知っている人がいたら教えて欲しい。
VSCode オプション
-
コードフォーマッタ
Atomを使っていた頃はAtom-beautifyでUncrustifyを使っていたが、VSCodeではデフォルトでclang-formatが入っているためこれを使っていた。
Uncrustifyより設定が楽で、なおかつプロファイル毎に結構良い感じにフォーマットしてくれるのだが、どうしても納得いかない部分がいくつか出てきてしまった。
VSCodeにも拡張機能としてUncrustifyが提供されているので乗り換えた。
C++ではフォーマッタとしてUncrustifyが優先して使用する設定と、毎回フォルダに設定ファイルをコピーしなくてもデフォルトとして読み込む設定ファイルのパスを決める設定をしておく。
せっかくコードフォーマッタを活用するなら保存(Ctrl+S)の度に整形するようにしておこう。
ある程度書いて保存すればエディタが強制終了しても大丈夫だし、見やすくするために入れるスペースなんかも自動で入れてくれて結果的に早くなるかもならないかも。
"[cpp]": { "editor.defaultFormatter": "LaurentTreguier.uncrustify", }, "uncrustify.configPath.windows": "uncrustify.cfgのパス",
-
デバッグ
VSCodeのデバッグ機能は結構高機能らしいので、デバッグも設定すると良いかもしれない。
自分は昨日始めて設定したが、競技プログラミングに限ればあまりいらないかなぁという印象。
task.jsonと同じディレクトリにlaunch.jsonを作成する。
{ // IntelliSense を使用して利用可能な属性を学べます。 // 既存の属性の説明をホバーして表示します。 // 詳細情報は次を確認してください: https://go.microsoft.com/fwlink/?linkid=830387 "version": "0.2.0", "configurations": [ { "name": "clang++.exe build and debug active file", "type": "cppdbg", "request": "launch", "program": "${fileDirname}\\${fileBasenameNoExtension}.exe", "args": [], "stopAtEntry": false, "cwd": "${workspaceFolder}", "environment": [], "externalConsole": false, "MIMode": "gdb", "miDebuggerPath": "C:\\msys64\\mingw64\\bin\\gdb.exe", "setupCommands": [ { "description": "Enable pretty-printing for gdb", "text": "-enable-pretty-printing", "ignoreFailures": true } ], "preLaunchTask": "build c++" } ] }
終わり。
競技プログラミングの環境構築とは書いたものの、普通のC++コーディングも同じ環境で行っている。
そちらではC++17を使用している等、主にtask.jsonは変更しているが。
競技プログラミングでも早く構造化束縛使わせて。
これだけ書いておけば新しいパソコンを買っても大丈夫だ!
自分で好き勝手設定したあの膨大なUncrustifyの設定ファイルだけは無くすととても嫌な気持ちになるから気をつけよう・・・。
後この忍者ブログとかいうサイトわざわざ<br>入れても自動で消してくるのさすがに頭おかしい。
PR
コメント