Likwidacja zależności projektu Visual C++ od starej wersji środowiska.

Czołem wszystkim.

Na pewnej uczelni technicznej, na magisterce z infy wymyślono taki przedmiot, którego głównym projektem zaliczeniowym SPA - statyczny analizatora wydumanego języka przetwarzający zapytania dotyczące programu napisane w drugim, w SLQ-podobnym, wydumanym języku. Całość ma być napisana w C++. Jedyny szkopuł w tym, że narzucony został system testujący - mianowicie jest wzięty diabli wiedzą skąd i nieistniejący od chyba 2007 roku "Autotester". Sprawa wygląda następująco:

Załóżmy, że napisałem ("załóżmy", bo na razie mam podstawy tego, ale nie ważne) projekt nazwany MySPA, używając dobrodziejstw C++11 i być może 14, pilnując by kompilował się na Linuksie pod clangiem i g++ (bo na tym stosie technologii mi się lepiej pracuje). Przerzuciłem go teraz do projektu Visual Studio 2015, poprawiłem błędy - kod kompiluje się pod visualowym toolsetem v140.

Jednocześnie mam dostarczoną przez prowadzących solucję z Visual Studio 2010, która zawiera projekt Autotester (zależny od zamkniętej biblioteki AutotesterLib.lib) będący narzędziem testującym, który wymaga biblioteki SPA.lib oraz przykładowy projekt SPA, który dostarcza tę wymaganą bibliotekę SPA.lib - oba kompilują się pod toolsetem v100.

Chciałbym w tym momencie podmienić SPA na MySPA. Ale...

• Nie mogę zmienić toolsetu obu projektów na v140 bo dostaję błędy linkera związane z tym, że AutotesterLib było kompilowane kiedyś przez inną wersję toolsetu.

AutoTesterLib.lib(QueryManager.obj) : error LNK2001: unresolved external symbol

• Nie mogę ustawić toolsetu MySPA na v100 - ponieważ wtedy będę zmuszony pisać wszystko jak zwierzę w jakimś C++03 czy innym 98 - a nie chcę pozbawiać się tych najprostszych ficzerów jak auto, foreach, lambdy - bo już musiałbym przepisywać część kodu.

Pytanie brzmi - czy mogę w jakiś sposób obejść niezgodność wersji i zgrać te dwa projekty?

Pytanie drugie - szukam pomysłu by "na chama" obejść to wszystko.
Autotester oczekuje, że dostarczę implementację dwóch metod:

void TestWrapper::parse(std::string filename)
void TestWrapper::evaluate(std::string query, std::list<std::string>& results)

filename i** query** to wejście, zaś stringi będące odpowiedzią mam umieścić w liście results.

Myślałem o tym, by skompilować mój projekt do appki wykonywalnej i odpalić ją w tych metodach jako proces z poziomu WinAPI, bądź coś w ten deseń - ale pachnie to koszmarnym overkillem.

Będę wdzięczny za wszelkie sugestie.

J.

Załóżmy, że napisałem [...] projekt nazwany MySPA [...] kompiluje się pod visualowym toolsetem v140.
No OK...

Nie mogę ustawić toolsetu MySPA na v100 - ponieważ wtedy będę zmuszony pisać wszystko jak zwierzę w jakimś C++03 czy innym 98 - a nie chcę pozbawiać się tych najprostszych ficzerów jak auto, foreach, lambdy - bo już musiałbym przepisywać część kodu.

Akurat VS2010 obsługuje auto, prawie obsługuje lambdy, i obsługuje foreach w niestandardowej składni for each i in w czy jakoś tak.

Jeśli VS2010 masz narzucony z góry, to to byłoby najłatwiejsze rozwiązanie. Niektóre braki uzupełni ci Boost.

Ale jeśli chcesz się uprzeć na VS2015, to możesz napisać libkę w 2010 która ładuje dynamicznie DLLkę napisaną w 2015 i odpala jej funkcje. Ale interfejs tej DLLki musiałby opierać się na funkcjach globalnych i typach prostych, żadnych list czy string.
Albo na klasach dotnetowych, czyli C++/CLI.
Albo na klasach COM.

EDIT:

	vector<int> w;
	w.push_back(42);
	for each (auto i in w) cout << i;

kompiluje się pod 2010.