Połączenie dwóch projektów - CLR Empty + MFC

0

Witam,

Napisałem projekt konsolowy na bazie CLR Empty Project. Znajduje się od w tym temacie: http://4programmers.net/Forum/C_i_C++/178773-funkcje_wirtualne_-_automatyczny_ich_wybor_nieprawidlowy

Obecnie jest on już gotowy, *death star fully operational *i te sprawy. Rzecz w tym, że docelowo muszę napisać obsługę tego w MFC, nie konsolowo. Wraz z rysowaniem figur na bieżąco.

Na początku po prostu wkopiowałem całą zawartość projektu konsolowego do projektu MFC. Jednakże okazuje się że sypie errorami, gdyż nie były poincludowane w każdym moim pliku pliki "stdafx.h"... Powiedziałem: "Nie ma mowy, nie będę wszędzie teraz tego dopisywał...". No i wyciągnąłem do osobnego projektu, w tym samym solution. Teraz zastanawiam się jak zrobić (i jednocześnie najłatwiej to zrobić), aby ten projekt MFC'owy korzystał z tamtego projektu. Jego klas, metod itp. W C# wystarczyło dopisać reference w odpowiednim miejscu, ale w C++ pierwszy raz robię coś takiego.

0

Twój projekt konsolowy praktycznie nie korzysta z .Net Frameworka. Wyłącz więc CLR, pozbądź się zależności (jedyne co to korzystasz z klasy Math, a tego da się uniknąć stosując funkcje ze standardowego C++), dodaj pliki do projektu MFC.
Wszelkie dalsze problemy z kompilacją będą łatwe do obejścia.

Nie ma mowy, nie będę wszędzie teraz tego dopisywał
Łatwiejsze niż kombinowanie tak jak chcesz to zrobić.

0

Ale kurczę. To jest nieelastyczne i nieładne. I co - gdybym chciał to zrobić pod MFC, albo pod SDI albo pod Window Forms, to za każdym razem muszę wkopiować ten kod do aplikacji? Nie mam jak rozdzielić warstwy modelu i widoku? To jest trochę do kitu... Ja chcę z mojego projektu z figurami zrobić coś w rodzaju biblioteki, z której potem wystarczyłoby tylko skorzystać i tyle.

Poza tym jak próbowałem ząłączać ten "stdafx.h" to dalej się o to czepiał, być może (nie jestem pewien) dlatego, że: mam to wszystko poukładane w tym projekcie ładnie po folderach, więc jak pisałem #include "stdafx.h" to nie potrafił znaleźć pliku, bo on był level albo dwa wyżej w katalogu, ale jak dałem #include "..\stdafx" to znowuż się czepiał, że unexpected eof while looking for precompiled header... czyli że nie znalazł linijki #include "stdafx.h", no i nic dziwnego, przecież jest, ale #include "..\stdafx". I to go chyba nie satysfakcjonuje - co ja mam teraz wywalać wszystko z folderów i robić jeden wielki śmietnik? Tylko dlatego że ktoś sobie wymyślił załączanie jakiegoś stdafx'a?... Sory, ale IMO to jest chore.

0

Chore jest to, że panikujesz, a nawet nie wpisałeś w google nazwy tego błędu. Wyłącz precompiled header w preferencjach projektu i nie krzycz.

0

Nie krzyczę. Nie przyszło mi do głowy szukać po googlu, jako że wydawało mi się że wiem o co chodzi w tym błędzie. Naprawdę nie ma żadnej opcji, aby to MFC po prostu, najzwyczajniej w świecie, po ludzku skorzystało z tych klas i cześć pieśni? Muszę je od siebie uzależniać?

0
Sushi271 napisał(a)

Ale kurczę. To jest nieelastyczne i nieładne. I co - gdybym chciał to zrobić pod MFC, albo pod SDI albo pod Window Forms, to za każdym razem muszę wkopiować ten kod do aplikacji? Nie mam jak rozdzielić warstwy modelu i widoku? To jest trochę do kitu... Ja chcę z mojego projektu z figurami zrobić coś w rodzaju biblioteki, z której potem wystarczyłoby tylko skorzystać i tyle.

nie o to chodzi.. chodzi o to, ze mieszasz technologie "native" z "managed", a to z definicji jest proste jesli managed ma uzywac native'a, a sporo truniejsze jesli to native ma korzystac z managed. W przypadku kiedy napiszesz GUI w MFC a obliczeniowke w C++/CLI, niestety dostaniesz wlsanie ten drugi przypadek!

ale nie ma rzeczy niemozliwych, ani jedno ani drugie nie jest jakos spcjalnie niesamowicie trudne, ot trzeba sie trzymac kilku dodatkowych rzeczy i pilnowac zeby interfejs bibliotek byl przyjazny. i tyle.

Sushi271 napisał(a)

Poza tym jak próbowałem ząłączać ten "stdafx.h" to dalej się o to czepiał, być może (nie jestem pewien) dlatego, że: mam to wszystko poukładane w tym projekcie ładnie po folderach, więc jak pisałem #include "stdafx.h" to nie potrafił znaleźć pliku, bo on był level albo dwa wyżej w katalogu, ale jak dałem #include "..\stdafx" to znowuż się czepiał, że unexpected eof while looking for precompiled header... czyli że nie znalazł linijki #include "stdafx.h", no i nic dziwnego, przecież jest, ale #include "..\stdafx". I to go chyba nie satysfakcjonuje - co ja mam teraz wywalać wszystko z folderów i robić jeden wielki śmietnik? Tylko dlatego że ktoś sobie wymyślił załączanie jakiegoś stdafx'a?... Sory, ale IMO to jest chore.

nie, to nie jest chore. to Ty tego nie rozumiesz i niedoczytales o co chodzi.
precompiled headers mozesz traktowac jako "przyspieszacz" kompilacji oraz "drugie serce" intellisense'a.
stdafx.h zostal "wymyslony" po to, abys czesto uzywane naglowki wlasnie w tym jednym pliku #include'owal, gdyz skoro sa czesto uzywane to sa uzywane wszedzie a zmienaja sie rzadko. dzieki temu kompilator moze sobie ten plik sparsowac raz, prekompilowac wyciagajac z niego maksimum informacji o nazwach i symbolach, a potem podczas kompilowania innych plikow korzystac z tgo przygotowanego wczesniej slownika nazw.
jesli to wylaczysz, kompilator dla każdego pliku .cpp bedzie musial jeszcze raz, od nowa, przeanalizowac całe drzewo sciezek #include, co w przypadku kilkuset a i czasami nawet przy kilkudziesieciu plikach cpp juz robi calkiem duza roznice w ilosci czasu jaki kompilacja zajmuje..

to tyle.

a teraz wylacz precompiled headers (gdzies w opcjach projektu jest przelacznik "user precompiled headers" - wybierz NO), albo napraw wszedzie sciezki do #include stdafx i sprobuj raz jeszcze

0

Zauważ, że to nie jest takie proste z prostej przyczyny. Chcesz połączyć ze sobą dwa różne języki: C++ i C++\CLI, jeden jest natywny, a drugi nie.

0

Jeśli chcesz mieć osobną bibliotekę, to proszę bardzo: wytnij z projektu konsolowego zależności od .Net-a. To wiele uprości. Skompiluj to jako bibliotekę statyczną (.lib) albo dynamiczną (.dll).
Potem bez problemu będziesz mógł jej używać zarówno pod MFC jak i pod WinForms.

Błąd stdafx masz od tego, że używasz prekompilowanych nagłówków. Albo prawidłowo dodaj include'a, albo wyłącz „precompiled header”. Ale wyłączenie tego wydłuży ci czas kompilacji, zwłaszcza w MFC.

nie o to chodzi.. chodzi o to, ze mieszasz technologie "native" z "managed", a to z definicji jest proste jesli managed ma uzywac native'a, a sporo truniejsze jesli to native ma korzystac z managed.
ale to „managed” u niego dotyczy tylko użycia klasy Math do funkcji trygonometrycznych i PI. Łatwo to przepisać na funkcje standardowe. Dlatego wyłączenie CLR proponuję jako najprostsze rozwiązanie.

0
Azarien napisał(a)

Jeśli chcesz mieć osobną bibliotekę, to proszę bardzo: wytnij z projektu konsolowego zależności od .Net-a. To wiele uprości. Skompiluj to jako bibliotekę statyczną (.lib) albo dynamiczną (.dll).
Potem bez problemu będziesz mógł jej używać zarówno pod MFC jak i pod WinForms.

nie o to chodzi.. chodzi o to, ze mieszasz technologie "native" z "managed", a to z definicji jest proste jesli managed ma uzywac native'a, a sporo truniejsze jesli to native ma korzystac z managed.
ale to „managed” u niego dotyczy tylko użycia klasy Math do funkcji trygonometrycznych i PI. Łatwo to przepisać na funkcje standardowe. Dlatego wyłączenie CLR proponuję jako najprostsze rozwiązanie.

=
Azarien, wybacz mi personalizację problemu, ale Twoje podejscie jest w tym momencie trochę irytujące. Już raz napisałeś te poradę, i autor zaprostestował, że on NIE chce w ten sposób robić i uważa to za niezrozumiałe "wymuszanie nieużywania FooBara ".

Człowiek spytał jak to zrobić, usłyszał jak to zrobic inaczej, ale on nadal chciałby mieć po swojemu, więc skoro po "jegowemu" jest wykonalne w nie aż tak skomplikowany sposob, proponuję przestać mu odradzać, bo po co człowieka załamywać?

Żeby stworzyć bibliotekę statyczną, czy dynamiczną, nie musi wycinać zależności od .net. Coż, ze statyczną zrobi sobie więcej problemów później, ale z tego co zrozumiałem on raczej celuje w dynamiczną, a tutaj CLR mu nie szkodzi. Zreszta, kurde, jaka gwarancja, że nie będzie mu się widziało w tej biblioteczce używać większych rzeczy z .Net niz System::Math?? Doradzałbyś komuś odcinac się od P/Invoke czy JNI i uzywania gotowych rzeczy, tylko dlatego że "bo w C# czy Java tez sie to da zrobic, bez brudzenia sie nativem"?

IMHO, im szybciej czlowiek się nauczy MIESZAĆ technologie, tym lepiej. Szybciej obiektywizmu nabierze i bedzie mial mniejsze sznse stac sie fantykiem-jednego-trademarku lub zwyklym ignorantem..

1 użytkowników online, w tym zalogowanych: 0, gości: 1