[C++] Błędy w linkowaniu DLL, ale tylko w przypadku klas

[Wonski]

Witam znowu,
Miałem nadzieję coraz rzadziej zakładać tutaj tematy, no ale jednak..

Mam dziwny problem który dotyczy linkowania (albo i nie?) bibliotek DLL.
Podczas wywoływania funkcji z dll, program kompiluje się bez błędów i ostrzeżeń. Sam program po uruchomieniu również działa poprawnie.
Problem zaczyna się gdy chcę zadeklarować obiekt klasy znajdującej się w DLL. Podczas kompilacji wywala mi błąd konsolidatora 2019:
https://msdn.microsoft.com/pl-pl/library/799kze2z.aspx
a konkretniej:

Kod: [Zaznacz]

Error LNK2019 unresolved external symbol "__declspec(dllimport) public: __thiscall class_test::class_test(void)" (__imp_??0class_test@@QAE@XZ) referenced in function _WinMain@16 Framework C:\Users\Sztywny\Desktop\System_framework\System_FrameWork\Framework\test.obj
Co jest cholernie dziwne, bo bibliotekę dołączam poprawnie, tzn:

Kod: [Zaznacz]

Project -> Configuration Proporties -> C/C++ -> General -> Additional Include Directories -> (ścieżka do headera DLL)
Project -> Configuration Proporties -> Linker -> General -> Additional Library Directories -> (ścieżka do wygenerowanego pliku .lib oraz .dll)
Project -> Configuration Proporties -> Linker -> Input -> Additional Dependencies -> dll_library.lib
Oczywiście nie zapominam o #include "dll.hpp" w pliku używajacym biblioteki..
Tak więc linkowanie do projektu odpada (chyba).

W ostatnim akapicie tego artykułu
http://cpp0x.pl/kursy/Kurs-WinAPI-C++/Zaawansowane/DLL/198,
który został rozszerzony w tym wątku:
http://cpp0x.pl/forum/temat/?id=3486&p=2

jest napisane, że zamiana metod  klasy umieszczonej w dll, na metody wirtualne załatwia sprawę. Niestety nie u mnie.
Ciągle występuje błąd 2019

W innych tematach jest sugerowane, że może to być wina źle postawionych lub w ogóle braku header guards. Jednak i to można wykluczyć, ponieważ tutaj nie przewiduję błędu.

Dodam również, że podobne błąd występował gdy chciałem po prostu zalinkować headery z bliblioteki inih do mojego projektu:
https://github.com/benhoyt/inih

Jednak to są same pliki h/hpp a nie pliki .a/.lib/.dll
Myślę, że nie ma sensu dodawać kodu źródłowego, ponieważ schemat jest analogiczny jak w przypadku tematów, do których linkuję wyżej.

Serdecznie pozdrawiam i proszę o pomoc, bo siedzę nad tym już od kilku dobrych godzin i nic nie mogę poradzić w tej sprawie.


EDIT:
Zauważyłem, że co kilka prób kompilacji, nie wywala błedu 2019 tylko błąd LNK 1104, czyli, że nie może znaleźć pliku liba:

Kod: [Zaznacz]

https://msdn.microsoft.com/query/dev14.query?appId=Dev14IDEF1&l=EN-US&k=k%28LNK1104%29&rd=true
Dzieje się tak również kiedy dam Clean Solution a następnie build solution, albo połączenie obu tych opcji czyli Rebuild Solution.
Ehh.. już sam kurwa nie wiem co do czego...

[mgr Fartuess]

class_test pochodzi z biblioteki, czy z twojego kodu?

[Wonski]

Tak.
Pochodzi z napisanej przeze mnie biblioteki.
Jedno nie wyklucza drugiego

Co ważne problem występuje nie tylko w tej bibliotece.
class_test  to, jak sama nazwa wskazuje, przykładowa prosta klasa z konstruktorem, destruktorem, getterami i setterami. Wsadziłem ją również do biblioteki której szkielet jest wygenerowany przez visual studio (po prostu szablon projektu).

Próbowałem również z własnym szablonem. Po prostu empty project, dwa pliki cpp, hpp, następnie zmiana w properties na dll i tyle.

Za każdym razem ten sam błąd.

Nawet, jak już zostało przeze mnie wspomniane, tyczy się to zewnętrznych bibliotek.
Wg mnie winę można zwalić na linkowanie do projektu, które zresztą opisałem wyżej.

[mgr Fartuess]

Głupie pytanie, ale muszę się zapytać. Jesteś pewien, że oprócz deklaracji tej metody masz jej implementację?

Bo ten błąd linkera znam z występowania w dwóch case'ach. Albo coś źle z libką, albo w twoim kodzie brakuje definicji czegoś co zadeklarowałeś.

[Wonski]

No oczywiście, że mam implementację .
Tylko dla uproszczenia sprawy, implementacja znajduje się już w ciele klasy a nie poza klamrami class lub w osobnym pliku cpp.

Visual studio podkreśla na kolor zielony nazwy metod, które nie maja swojej implementacji.
(metody, które nie mają swoich implementacji nazywają się prototypami, tak?)
Post połączony: 2016-03-17, 20:00

albo w twoim kodzie

Problem nie dotyczy tylko mojego kodu 

[mgr Fartuess]

Ja mam 2013 i mi nie podkreśla

Dunno podrzuć może projekt, bo to strasznie dziwne mi się wydaje.

[inż. Avallach]

metody, które nie mają swoich implementacji nazywają się prototypami, tak?

Jest kilka rodzajów metod o których można powiedzieć że nie mają implementacji.
Jeśli mają dopisane "= 0" to są "czysto wirtualnymi" ("pure virtual") - używa się ich w interfejsach i klasach abstrakcyjnych.
Jeśli mają dopisane "= delete" to są "usunięte".
Jeśli mają dopisane "= default" to właściwie mają implementację - tylko że generowaną przez kompilator i niewidoczną.
Jeśli nie mają ani "=", ani definicji, to jedyna nazwa która przychodzi mi do głowy to że są "błędami linkowania"

Możesz też zapisać sam typ ("sygnaturę") metody, ale to nie to samo co metoda bez implementacji. Przykładowo:

Kod: [Zaznacz]

typedef void MojTypMetody(int) const;To typedef o nazwie MojTypMetody oznaczający typ metody constowej która przyjmuje inta i nic nie zwraca.

[Wonski]

@Fartuess  spójrz:
http://zapodaj.net/43a34f6aa4aa2.bmp.html
metody które nie posiadają implementacji są podkreślone na zielono (konstruktor i destruktor), natomiast metody które posiadają implementację/definicję (get i set) nie są podkreślone.
Kompilator nie wypluwa żadnych ostrzeżeń.

Co do projektu to za chwilę wrzucę całą solucję na dropboxa.
Naprawdę Panowie nie wiedzieliście, że metody/funkcje bez definicji/implementacji to są prototypy?
Swego czasu czytałem, że tak się robi szkic projektu, tzn. od razu z miejsca ustalam sobie, deklaracje metod/funkcji a potem w miarę rozrostu aplikacji dodaję definicje powyższych..

Ehh... sporo nauki przede mną
Post połączony: 2016-03-17, 21:23Proszę, oto cała solucja (oba projekty dll i exe wraz ze wszystkimi plikami źródłowymi):
https://www.dropbox.com/s/cqzlqksq7o4v3eg/test_dll.zip?dl=0

@inż. Avallach
Tak, żeby mieć pewność..
Dodanie const na końcu deklaracji metody to jakby zapewnienie, ze ta metoda nie modyfikuje obiektu, tak?

[mgr Fartuess]

No czyli jest tak jak mówiłem. Nie ma implementacji konstruktora i destruktora. Kompilacja do biblioteki to przepuszcza, bo tak jak mówisz - to może być prototyp który dopiero wewnątrz aplikacji używającej bibliotekę będzie zaimplementowany do końca.

zrób

Kod: [Zaznacz]

test_class() {}
~test_class() {}

albo wypierdol te deklaracje kompletnie, to kompilator ogarnie, że ma wygenerować automatycznie.

[Wonski]

Ehh...
Akurat teraz specjalnie usunąłem ciała konstruktora i destruktora by Ci pokazać, że faktycznie podkreśla.
Jeżeli pobierzesz zipa to zobaczysz, że są ciała WSZYSTKICH metod i to dokładnie w ten sposób w jaki przedstawiłeś

Wg mnie to coś z IDE albo z linkowaniem, no bo jak wytłumaczysz, że dzieje sie to również z innymi nie moimi bibliotekami?

[mgr Fartuess]

U mnie się builduje... Jedyne co zmieniłem to Platform Toolset na vs120 oraz ścieżki do headerów i libów na takie, żeby mi działały. Tj takie które u każdego powinny działać

$(SolutionDir)\dll
$(SolutionDir)\Debug

[Wonski]

 
Jak to?
To w takim razie robię reinstal tego programu...
Nic innego nie przychodzi mi do głowy.

[inż. Avallach]

@inż. Avallach
Tak, żeby mieć pewność..
Dodanie const na końcu deklaracji metody to jakby zapewnienie, ze ta metoda nie modyfikuje obiektu, tak?

Nawet bez "jakby" ;)
Jeśli użyjesz tego słowa kluczowego, próba dokonania w implementacji bezpośredniej modyfikacji któregoś z pól lub wywołania innej metody nie-constowej zostanie zgłoszona jako błąd kompilacji.

[mgr Fartuess]

Zawsze jest możliwość, że gdzieś w ścieżce zrobiłeś literówkę a ja to u siebie niechcący poprawiłem

[Wonski]

To by wtedy wywaliło: no such file directory, albo coś w ten deseń.
A poza tym robiłem copy-pasta ścieżek, no i wgl powtarzałem tą operacje dziesiątki razy by upewnić się, że wszystko robię ok.
Na noc zostawię pobieranie tego gówna i jutro dam znać co i jak.