[piotrdz]

Jak pisałem już w moim poprzednim wątku, zobaczyłem jak wygląda sprawa z kompilacją kodu pod GCC. Znalazłem przy tym wiele dziwnych konstrukcji, potencjalnych bugów i przykładów nieprzenośnego kodu.

Piszę o tym tutaj, żeby potem to gdzieś nie zaginęło, bo warto z tym rozprawić się już na początku, niż żeby kiedyś potem wyszło to jeszcze raz.

Są to głównie rzeczy na których wykrzacza się GCC, ale też kilka rzeczy, które ogólnie rzuciły mi się w oczy.

#0 Brakujące #include'y, wielkość liter w nazwach plików - tym już się zająłem.

#1 Klasy dziedziczące po CAuto mają podwójnie wywoływane konstruktory. Przykład:

Kod:

CAutoBase::CAutoBase(CInstanceManager* iMan, CObject* object)                                          : CAuto(iMan, object) {         CAuto::CAuto(iMan, object);

Nie wiem, czy to celowe działanie, czy błąd.

#2 Klasy pochodne mają w destruktorze jawnie wywoływany destruktor klasy bazowej (być może też powoduje to podwójne wywołanie jak konstruktorów).

Kod:

CAutoBase::~CAutoBase() {         CAuto::~CAuto(); }

Na tym w ogóle wywala się GCC, bo nie pozwala na taką składnię. Trzeba by wszystkie destruktory zamienić na wirtualne i pozbyć się tego.

#3 W robotmain.cpp: #include "classfile.cpp" Hmmm...

#4 Są dwa moduły z funkcją WinMain(): d3dapp.cpp i winmain.cpp. Chyba tylko ten pierwszy jest linkowany? Do czego jest ten drugi?

#5 Copie de taskgoto.cpp, restext-old.cpp - zgaduję, że można się tego pozbyć?

#6 object.cpp, kilka innych miejsc - niestandardowe użycie struktur DirectX np. operator * na najzwyklejszej strukturze D3DMATRIX. Nie ma tego w nagłówkach libwine, MSDN o nich też nic nie wspomina, nie mam pojęcia skąd to wytrzasnęli.

#7 math3d.h i math3d.cpp - funkcje są typu extern inline - nie ma czegoś takiego w standardzie C++ (chociaż jest w niektórych odmianach C). Na tym wywala błąd linker GCC.

#8 sound.cpp funkcja GetCurrentDir() i prawdopodobnie inne miejsca - bezpośrednie operacje na ścieżkach (parsowanie po backslashach), użycie niestandardowego _prgname - do poprawienia od razu.

Jeszcze pewnie parę mi się przypomni.

Od strony organizacyjnej można by pomyśleć o postawieniu np. Bugzilli czy czegoś podobnego, ewentualnie wykorzystać sam system issues Githuba.

[Raptor]

Co do bugów, rzeczywiście. Mogę dodać co najwyżej jeszcze jeden, bardzo niepokojący:

#9 Po kompilacji i uruchomieniu gra działa na gołe oko sprawnie, jednak każda próba zapisania stanu gry (np. w swobodnej) kończy się kompletnym crash'em całej gry. Niedobrze...

Widocznie modyfikacje, mające na celu zbudowanie CeeBot'ów na podstawie CoLoBoT'a spowodowały, że obecny kod jest bardzo niespójny. Bardzo niedobrze...

[krzys_h]

[piotrdz]

[krzys_h]

Skończone:
https://github.com/adiblol/colobot/issues
Kolejne błędy proszę zgłaszać w issues.

[piotrdz]

[krzys_h]

Wiem. Nie jestem najlepszy z angielskiego

[piotrdz]

[Malcolm]

piotrdz:

ad. 0
Na starszych msvc nie było różnicy, ponieważ na windows i tak nie możesz mieć plików o tej samej nazwie ale różniących się wielkością liter.

ad. 1 oraz 2
Długo się zastanawiałem co autorzy mieli na myśli pisząc to, ale za każdym razem dochodzę do tego samego wniosku.
Brak dostatecznej znajomości c++
Tak jak pisałeś, w klasie bazowej destruktor nie jest virtualny a powinien być, bo inaczej nie zostanie wywołany.
Wygląda mi na to, że gościom po prostu się nie odpalał to dopisali ręcznie (lol),
powiem więcej, wygląda na to, że z rozpędu dodali także ręczne odpalanie konstruktorów.

Ogólnie taki kod aż prosi się o to żeby nie działać.

Ręczne odpalanie konstruktorów stanowczo trzeba wywalić i dodać virtualny destruktor w klasie bazowej.

P.S. Nie zmieniaj wszystkich destruktorów na virtualne!
Trzeba dodać virtualne destruktory wszędzie tam, gdzie są używane virtualne metody. Znając życie to po takich zmianach i przy takiej wielkości projektu pewnie ujawnią się jakieś bugi.

ad. 3
WTF?

ad. 4
Wygląda na to, że pierwszą wersją było winmain.cpp, po zmianach zapomnieli wywalić.

ad. 5
Wywal

ad. 6
W którym miejscu masz tam operator? Tego nie rozumiem, chodzi ci o wskaźniki na strukturę?

ad. 7
Racja, ktoś się uczył C i zabrał się za C++
Z drugiej strony mają dodane to http://msdn.microsoft.com...1(v=vs.85).aspx aby pozbyć się błędów kompilacji. Makabra.

ad. 8
Mistrz. Kolejny dowód na brak doświadczenia i znajomości api.

ad. 9
Debugger i jazda

[krzys_h]

Jakby ktoś nie zauważył to niepotrzebnych plików już się pozbyłem.

[piotrdz]

[lukas_j]

Coś czuje ze będziemy musieli się nieźle namęczyć z tym kodem zeby skompilować to pod gcc...

[piotrdz]

[adiblol]

[piotrdz]

Jak pisałem wcześniej, z libwine są problemy. Na razie jako pierwszy cel proponuję właśnie udaną kompilację pod windowsem z cmake i mingw.