堕天使の煉獄

Gallery
Comic
Story
Production
Work
Link

2014-09

24

06:51:26

スクラップアンドビルド

本来の用法とは違うのだろうけど
プロジェクトをスクラップアンドビルド~

タイミング的に一度整理した方が
後々楽になるので、いったんプロジェクトの中身を空っぽにして
依存関係をチェックしながらソースを追加して行きつつ
その都度ソースコードの修正も……

とか良くやるのですが。

こんな記事が。
ttp://d.hatena.ne.jp/melpon/20101022/1287705842


そうだよなー。
いっぺんC#とか触ったり、テンプレートを常用しだすと
.cppって要らなくね? ってなるよなぁ。

そういう意味では、おいらもすでに普通の C++ プログラマw

今のまでのところは、特に深く考えず、

単純にどうやっても代替案のない
特定ケースでの長大なcase文だとか
その場限定で使い回すこともない
長めの関数、
(個人的な基準では20~30行以上?
だいたい感覚的に長くなったなと思ったら分ける程度)

とかだけcppに書いて
あとはみんなヘッダに書く感じだったり。

全部ヘッダにあるのに
staticな変数の実体書くために
一行だけのcpp(include足せば二行だけど)
とか、あほらしいなーとかは思ってはいて。

__declspec(selectany)
を使うのも一般的なのかなー
vc++独自拡張だしなーコレ。

と、腑に落ちない物の、c++ってこういうもんだよなーと
cppもそれなりに使ってたりしてたりしたんだけど
上の記事を読んで、

なんだ、そこまでやっちゃっていいんだ。

というか、c#とかの最近の言語風に書いちゃっても
別にいい、というか、もはや周りの環境がそういう感じになってるのかな?
とか感じたり。

最近じゃもう、最初に触った言語、習得した言語がc++です。
なんて人、ほとんどいないだろうしね。

そもそも、ヘッダとcpp分けるのって
大昔のc++以前のc言語の時代、
まだメモリもcpuも貧弱な時代に
コンパイルの負荷を分散させて、貧弱なハードウェア上でも
大きなプロジェクトをビルド出来る様にする仕組み
からの仕組みなわけで。

最近では分割コンパイルといえば、マルチコアやネットワークつかった
並列ビルドの方の意味合いにかわっちゃってるですよね。


なので、ビルドに何時間もかかるような規模のもので無ければ
むしろ分割コンパイルはしない方がマシ。(と書くと語弊があるな)

旧来の方式だと、
依存関係をまず調べて、依存関係内のものを一つのグループとして
そのグループをコンパイル。

共通して複数のグループに属しているヘッダなんかがあると
そのヘッダの中身を変更するだけで
依存関係のあるグループすべてがリコンパイル対象となってしまう。

なので、共通ヘッダみたいな、常にインクルードされるヘッダとか
ヘッダをまとめた共通ヘッダヘッダ、みたいなのを作ってると
とあるヘッダの改行一個の変更で、ほぼプロジェクト全部リビルド……
なんて憂き目にあう羽目になるんですよねw

さらにはその依存関係の順番によって
やっかいな循環参照だとかになったりもする。


いったんすべての宣言部分を読み込んで
そこで依存関係とか勝手にコンパイラの側で
整理してからコンパイルする方式のが
最近の状況的には現実的なのですよね。
(後発の最近の言語はそんな感じになってるっぽい)
メモリもcpuパワーも有り余ってるわけだし。



それに似た感じのが上の記事の
cppを一つにする。
という方法論なのでしょうね。

んまあ、ヘッダの循環参照問題は依然として残りますが。
ほんとヘッダの循環参照ってやっかいなんですよね……

しかしヘッダオンリーで考えると
モジュール化(依存関係が切り離されて独立したグループ)を考えた
設計がやりやすくなるので、循環参照を起こりにくくすることが
できたりもする。


なので、なるほど、徹底してcppを使わないと言う方法も
良い方法なのだなぁと。



とはいえ。

スタティックライブラリ(LIB)化目的の物だと
ヘッダに全部書いちゃうのは問題アリアリだったりもするw

この記事のリンクもとだったか、どこかのコメントにあったけど
作成中は全部ヘッダに書いて、
完成したあとで、ヘッダとcppに分けた物を最終的なライブラリとして完成。

みたいなやり方をしているというのがあって
なるほど-とかおもたり。

cppを一つにする方法、たしかに
格段にビルド時間短縮出来るんですよね。

開発中の、頻繁に修正はいる時には
そのたびにビルドに30秒とか1分とか掛かってると
ストレスでしかないですよね。


そんで気がつくと、半日ぐらい一切ビルドしないで
ひたすらコーディングして。

そんで半日分のコードをビルドして、一個もエラーでないと

「んひぃぃぃぃっ、ぎんもぢいひぃぃぃっっ」

とかなったりするのですが(ぉ
でもやっぱり、所詮人の手。
ビルドは通ってもコンパイルエラーじゃないバグはいくつも出てくるので
その後の検証とかも時間かかったりして。

やっぱ、少しずつトライアンドエラーしながら進めた方が
楽だったりもするし。
(ケースバイケースだけど)

そのときにビルドが毎回、数秒程度ならどれだけストレス減ることか。

ビルドするたびに飲み物おかわりとかしてると
しっこが止まらなくなります(ぉ

なので、制作中だけは、ほぼヘッダのみで記述して
最終的にはきっちりとcppとにわける。
と言う方法論は確かにいいやり方だな、とおもたり。


そんな感じで、ソースコードを全面修正中。

とはいえ、極端にcpp排斥するのも微妙かなーというところもあったり。

モジュール単位という考えをしっかりしていれば
というよりモジュール単位でのコンパイル単位? みたいなのを
意識したコーディングに自然となるので、その中でならcppを使うのも
ありかなーと言う感じですね。

どういう意図でヘッダをリンクしてるのか、とか考えるようになるぽ。


ふむう。
Sun
Mon
Tue
Wed
Thu
Fri
Sat
01
02
03
04
05
雨~
06
07
08
うぉいっ、君ぃ!?
09
10
11
12
13
14
15
やっぱりか……
[敬老の日]
16
17
18
糖分
19
20
21
22
23
不毛……?
[秋分の日]
24
スクラップアンドビルド
25
26
27
28
29
30
total:2076310 t:218 y:119
■記事タイトル■

■年度別リスト■
2024年 2024年12月(0)
2024年11月(0)
2024年10月(1)
2024年09月(2)
2024年08月(1)
2024年07月(1)
2024年06月(5)
2024年05月(2)
2024年04月(1)
2024年03月(6)
2024年02月(4)
2024年01月(3)
2023年 2023年12月(3)
2023年11月(1)
2023年10月(2)
2023年09月(3)
2023年08月(3)
2023年07月(3)
2023年06月(7)
2023年05月(8)
2023年04月(2)
2023年03月(1)
2023年02月(2)
2023年01月(3)
2022年 2022年12月(4)
2022年11月(3)
2022年10月(1)
2022年09月(3)
2022年08月(3)
2022年07月(2)
2022年06月(1)
2022年05月(3)
2022年04月(2)
2022年03月(2)
2022年02月(1)
2022年01月(6)
2021年 2021年12月(8)
2021年11月(3)
2021年10月(4)
2021年09月(6)
2021年08月(2)
2021年07月(1)
2021年06月(3)
2021年05月(2)
2021年04月(2)
2021年03月(3)
2021年02月(1)
2021年01月(4)
2020年 2020年12月(3)
2020年11月(7)
2020年10月(2)
2020年09月(3)
2020年08月(1)
2020年07月(3)
2020年06月(7)
2020年05月(5)
2020年04月(8)
2020年03月(4)
2020年02月(2)
2020年01月(4)
2019年 2019年12月(1)
2019年11月(1)
2019年10月(2)
2019年09月(1)
2019年08月(3)
2019年07月(2)
2019年06月(2)
2019年05月(2)
2019年04月(4)
2019年03月(1)
2019年02月(7)
2019年01月(1)
2018年 2018年12月(1)
2018年11月(1)
2018年10月(5)
2018年09月(1)
2018年08月(5)
2018年07月(1)
2018年06月(1)
2018年05月(1)
2018年04月(2)
2018年03月(2)
2018年02月(1)
2018年01月(1)
2017年 2017年12月(2)
2017年11月(1)
2017年10月(2)
2017年09月(5)
2017年08月(8)
2017年07月(2)
2017年06月(1)
2017年05月(1)
2017年04月(3)
2017年03月(5)
2017年02月(7)
2017年01月(8)
2016年 2016年12月(7)
2016年11月(2)
2016年10月(3)
2016年09月(7)
2016年08月(8)
2016年07月(10)
2016年06月(17)
2016年05月(6)
2016年04月(8)
2016年03月(10)
2016年02月(5)
2016年01月(10)
2015年 2015年12月(7)
2015年11月(7)
2015年10月(13)
2015年09月(7)
2015年08月(7)
2015年07月(5)
2015年06月(4)
2015年05月(5)
2015年04月(2)
2015年03月(4)
2015年02月(1)
2015年01月(7)
2014年 2014年12月(12)
2014年11月(8)
2014年10月(4)
2014年09月(6)
2014年08月(7)
2014年07月(4)
2014年06月(2)
2014年05月(5)
2014年04月(4)
2014年03月(8)
2014年02月(4)
2014年01月(8)
2013年 2013年12月(15)
2013年11月(8)
2013年10月(3)
2013年09月(3)
2013年08月(8)
2013年07月(0)
2013年06月(0)
2013年05月(0)
2013年04月(0)
2013年03月(0)
2013年02月(0)
2013年01月(0)

■レス履歴■

2023-09-26 14:59:38 - 久慈光樹

2023-09-26 14:29:10 - 織田霧さくら

2023-09-26 13:10:45 - 久慈光樹

2023-03-20 05:30:16 - 織田霧さくら

2023-03-15 20:42:58 - まうる

2022-12-26 19:14:57 - 織田霧さくら

2022-12-25 02:28:36 - まうる@まるるん

2022-09-30 04:29:01 - 織田霧さくら

2022-09-23 19:01:29 - まるるん

2022-06-16 21:06:34 - 山本


■ファイル抽出■

■ワード検索■

堕天使の煉獄

https://rengoku.sakura.ne.jp
管理人

織田霧さくら(oda-x)

E-mail (■を@に)

oda-x■rengoku.sakura.ne.jp

堕天使の煉獄バナー 堕天使の煉獄バナー