Po moim ostatnim wpisie spotkałem się z konstruktywną krytyką ze strony czytających. Jednym z zarzutów było to, że propaguję używanie GLOB’a, który to powoduje sporo problemów. Ponieważ nie mam na celu propagować tego co złe, dzisiaj omówię ten temat nieco szerzej.

GLOB lekiem na całe zło

Ja do GLOB podszedłem w bardzo entuzjastyczny sposób. Pracuję przy projekcie, który liczy około dwustu plików. Uciążliwym dla mnie było to, że każdy dodany przeze mnie plik był dodawany do pliku CMakeLists.txt, przez co on puchł. Drobnym szczęściem w nieszczęściu było to, że samo dodawanie robiło za mnie IDE. Jednakże, pliki CMakeLists.txt puchły. Odkrycie GLOB’a było dla mnie zbawieniem, dopóki nie opublikowałem wspomnianego wpisu.

U mnie działa

Omnibusem nie jestem, i tego nigdy nie ukrywam. C++ to dla mnie… hobby. Sporo doświadczeń mnie omija, ponieważ dłubię sam. Nie wiem, które rozwiązanie niesie za sobą więcej złego niż dobrego.

Kiedy robię coś dla siebie, mój plan działania zazwyczaj wygląda tak:

Działa? Działa. Jeżeli działa, ale problemem jest utrzymywanie rozwiązania, to wtedy jest źle. Jeżeli działa, i utrzymywanie rozwiązania nie jest dla mnie kosztowne - to super.

W przypadku GLOB problemu nie dostrzegałem, ponieważ nie dotykał mnie on. To nie znaczy, że problemu nie ma, a GLOB jest super. Na szczęście, moje treści czytają bogatsi ode mnie w doświadczenie ludzie, od których się uczę.

Konstruktywna krytyka zawsze na propsie

W przygotowanych przeze mnie treściach mogą zdarzyć się błędy, od literówek - przez błędy składniowe - do błędów merytorycznych. Razem z Wojtkiem staramy się jak możemy aby nasze treści były zawsze zgodne z rzeczywistością, ale każdy zawsze może coś pominąć. W sytuacji, kiedy coś jednak jest nie tak jak być powinno - bardzo liczymy na Was. O ile zwykły hejt odstawiamy na bok, to merytorycznych wypowiedzi nigdy nie pomijamy. Bo słowo jakoś ma jeszcze na końcu ć. Poniżej zostawiam ziarnko, które zasiał jeden z czytelników, a które spowodowało że zacząłem szukać :)

Piona Dawid!

Wracając do GLOB’a…

Co takiego złego jest w GLOB’ie? Problemy rozpoczynają się dopiero przy pracy grupowej. Wyobraźmy sobie, że przy projekcie pracują dwie osoby (Programista A, Programista B), które używają dowolnego systemu do wersjonowania kodu źródłowego. W projekcie używamy GLOB.

Przeanalizujmy poniższy scenariusz:

1. Programista A dodaje do repozytorium plik źródłowy. Niech będzie to x.cpp
2. Programista A wrzuca swoje zmiany na serwer.
3. Programista B pobiera nowe zmiany z repozytorium.
4. Ponieważ programista B zauważył, że plik CMakeLists.txt nie został zmieniony, nie przebudowywuje plików projektu.
5. Programista B kompiluje kod.
6. Programista B otrzymuje błędy linkowania.

Dlaczego tak się stało?

Plik x.cpp po pobraniu zmian przez Programistę B nie został dodany do listy plików źródłowych przez GLOB, ponieważ Programista B nie widział potrzeby przebudowania projektu (w końcu CMakeLists.txt nie został zmieniony). W konsekwencji, pliki które używały funkcji znajdujących się wewnątrz x.cpp zostały re-kompilowane, a sam plik x.cpp kompilacji uniknął. Dalszym skutkiem jest błąd linkera.

Jaka jest alternatywa dla GLOB’a? Póki co, jedynym co przychodzi mi na myśl, jest dokładanie ścieżek do utworzonych plików do zmiennych wewnątrz plików CMakeLists.txt. Czyli dokładnie to, czego starałem się uniknąć.

Podsumowanie

Dzisiaj dowiedzieliśmy się, jakie zalety oraz wady niesie ze sobą używanie GLOB’a w projekcie, oraz dlaczego w większości przypadków użycie go nie będzie idealnym rozwiązaniem.

Jeżeli znasz jakieś rozwiązanie problemu zarządzania plikami wewnątrz projektu, wspomnij o nim na grupie Cpp Polska :)

PS. Dzisiejszą mądrość zaczerpałem z tego źródełka.