Sebastian Biały <h...@p...onet.pl> napisał(a):

> On 2012-05-28 23:27, M.M. wrote:
> > Z powodu takich zmian lubię mieć "globalnego" includa w C++
>
> #include "all.hpp"
Tak, tyle że zwykle używam nazwy
#include "include.h"

> To *chyba* wpływa Ci zasadniczo na prędkość kompilacji o ile to nie jest
> hello world.
Hmmmmm
Jeśli zmieniam nagłówek który jest wcielony w wielu plikach to
i tak i tak kompilacja długo trwa. Jeśli używam nagłówków z jakiś dużych
bibliotek to i tak narzut na czas kompilacji głównie spowodowany
nagłówkami bibliotecznymi a nie moimi. Jeśli nagłówek nie jest często
wcielany, to bez większych oporów usuwam go z globalnych inkludów. Gdy
zmieniam tylko plik źródłowy, to kompilacja może być nawet szybsza,
bo kompilator nie męczy się z wielokrotnym wcielaniem i omijaniem tego
samego nagłówka. Jakby kompilacja trwała zbyt długo to bym nie używał
globalnego inkluda. Może taki problem pojawia się od projektów o
rozmiarze 50MB kodu?


> Widuje taki kfiatki w projektach opensource, autorzy jednak
> zazwyczaj maskują swoje lenistwo za pomocą bardziej śmiesznych argumentów.
Co to za argumenty? Moim nie jest lenistwo.

> No właśnie - jeśli nazwiesz go poprawnie, to istnieje wysoka szansa że
> ta "zamiana" to cut/paste w sposób 100% automatyczny na wszystkich
> plikach projektu. Nazwij pliki sensownie - a nie będzie bolało.
Niby tak, ale jeśli mam dużo małych klas i dość zawiłą strukturę
dziedziczenia/agregowania to jakoś wygodnie mi się patrzy gdy mam
w jednym pliku inkludowane w takiej kolejności w jakiej trzeba.

Ponadto taka wygoda jest potrzebna na początkowym etapie projektu. Gdy
projekt się rozrasta to nazwy są poprawiane rzadziej. Jakby kompilacja
okazała się zbyt długa, to można inkludować tylko tam gdzie potrzeba.
Jednak w moich projektach średnio po 0.5MB - 2.0MB kodu nie dotarłem
nigdy do takiego problemu.

Pozdrawiam


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/