Znajdź niezaimplementowane metody klasy

Question

W mojej aplikacji mam do czynienia z klasami o większych rozmiarach (ponad 50 metod), z których każda jest dość złożona. Nie martwię się złożonością, ponieważ są one nadal proste w zakresie izolowania elementów funkcjonalnych na mniejsze metody, a następnie wywoływania ich. W ten sposób liczba metod staje się duża (wiele z tych metod jest prywatna - szczególnie izolowanie elementów funkcjonalności).

Jednak kiedy dochodzę do etapu wdrożenia, stwierdzam, że tracę kontrolę nad tym, które metody zostały wdrożone, a które nie. Następnie na etapie łączenia otrzymuję błędy dla niezaimplementowanych metod. Byłoby to w porządku, ale między klasami istnieje wiele zależności i aby połączyć aplikację, muszę przygotować WSZYSTKO. Mimo to wolałbym zdobyć jedną klasę, zanim przejdziemy do następnej.

Z przyczyn niezależnych od mnie nie mogę używać IDE - tylko zwykły edytor tekstu i kompilator g ++. Czy istnieje sposób na znalezienie niezatwierdzonych metod w jednej klasie bez wykonywania pełnego łączenia? W tej chwili dosłownie wykonuję wyszukiwanie tekstowe na sygnaturach metod w pliku cpp implementacji dla każdej z metod, ale jest to bardzo czasochłonne.

Answer 1

Chociaż nie widzę prostego sposobu, aby to zrobić bez faktycznego próbowania połączenia, można odsunąć wyjściowy linker na "niezdefiniowane odniesienie do ClassInQuestion ::", co powinno dać ci tylko linie związane z tym błędem dla metod danej klasy.

Pozwala to przynajmniej uniknąć przeszukiwania wszystkich komunikatów o błędach z całego procesu łączenia, ale nie wyklucza konieczności korzystania z pełnego łącza.

Answer 2

Nie widzę łatwego sposobu na zrobienie tego. Posiadanie kilku klas bez implementacji łatwo doprowadzi do sytuacji, w której śledzenie w zespole z wieloma członkami będzie koszmarem.

Osobiście chciałbym przetestować każdą klasę, którą piszę, a rozwój oparty na testach jest moją rekomendacją. Jednak wiąże się to z łączeniem kodu za każdym razem, gdy chcesz sprawdzić status. Narzędzia do korzystania z TDD można znaleźć pod linkiem here.

Inną opcją jest napisanie fragmentu kodu, który może przeanalizować źródło i sprawdzić, czy funkcja ma zostać zaimplementowana. GCC_XML to dobry punkt wyjścia.

Answer 3

Można dodać zalążek dla każdej metody, którą zamierzasz realizować i zrobić:

void SomeClass::someMethod() { 
    #error Not implemented 
} 

z GCC, to wysyła plik, numer linii i komunikat błędu dla każdego z nich. Abyś mógł następnie skompilować dany moduł i grep dla "Nie zaimplementowany", bez konieczności uruchamiania łącznika.

Mimo to nadal musisz dodać te kody pośredniczące do plików implementacji, które mogą być częścią tego, co próbujesz omijać w pierwszej kolejności.

Answer 4

W przeszłości zbudowali wykonywalny dla każdej klasy:

#include "klass.h" 
int main() { 
    Klass object; 
    return 0;   
} 

Redukuje to czas budowy, może pozwolić skupić się na jednej klasy w czasie, przyspiesza pętlę sprzężenia zwrotnego.

Można go łatwo zautomatyzować.

Naprawdę chciałbym jednak ograniczyć rozmiar tej klasy!

edit

Jeżeli istnieją przeszkody, można iść brutalnej siły:

#include "klass.h" 

Klass createObject() { 
    return *reinterpret_cast<Klass>(0); 
}  

int main() { 
    Klass object = createObject(); 
    return 0;   
} 

Answer 5

To właśnie testy jednostkowe i narzędzia pokrycia testy są do: napisać minimalne testy dla wszystkich funkcji z góry. Testy na brakujące funkcje nie będą się łączyć. Raport pokrycia testu powie, czy wszystkie funkcje zostały odwiedzone.

Oczywiście, to tylko w pewnym stopniu pomaga, nie jest to dowód na 100% głupi. Twoja metodologia rozwoju brzmi dla mnie nieco niepewnie: tworzenie klas jeden po drugim w izolacji nie działa w praktyce: klasy, które są od siebie zależne (i pamiętaj: zmniejsz zależności!) Muszą być w pewnym stopniu rozwijane w lockstepie. Nie możesz wymyślić kompletnej implementacji dla jednej klasy i przejść do następnej, nigdy się nie oglądając.

Answer 6

Można napisać mały skrypt, który analizuje plik nagłówkowy dla implementacji metod (wyrazy regularne sprawią, że jest to bardzo proste), a następnie skanuje plik implementacji dla tych samych implementacji metod.

Na przykład w Ruby (dla C++ jednostki kompilacji):

className = "" # Either hard-code or Regex /class \w+/ 
allMethods = [] 

# Scan header file for methods 
File.open(<headerFile>, "r") do |file| 
    allLines = file.map { |line| line } 
    allLines.each do |line| 
     if (line =~ /(\);)$/) # Finds lines ending in ");" (end of method decl.) 
      allMethods << line.strip! 
     end 
    end 
end 

implementedMethods = [] 
yetToImplement = [] 

# Scan implementation file for same methods 
File.open(<implementationFile>, "r") do |file| 
    contents = file.read 
    allMethods.each do |method| 
     if (contents.include?(method)) # Or (className + "::" + method) 
      implementedMethods << method 
     else 
      yetToImplement << method 
     end 
    end 
end 

# Print the results (may need to scroll the code window) 
print "Yet to implement:\n" 
yetToImplement.each do |method| 
    print (method + "\n") 
end 

print "\nAlready implemented:\n" 
implementedMethods.each do |method 
    print (method + "\n") 
end 

Ktoś inny będzie w stanie powiedzieć, jak zautomatyzować ten do procesu kompilacji, ale to jest jeden sposób, aby szybko sprawdzić, które metody nie zostały jeszcze wdrożone.

Answer 7

delete kluczowe C++ 11 załatwia sprawę

struct S{ 
    void f()=delete; //unimplemented 
}; 

Jeśli C++ 11 nie jest dostarczony, można użyć prywatny jako obejście

struct S{ 
    private: //unimplemented 
    void f(); 
}; 

Z tych dwóch metod, możesz napisać kod testowy w pliku .cpp

//test_S.cpp 
#include "S.hpp" 
namespace{ 
    void test(){ 
    S* s; 
    s->f(); //will trigger a compilation error 
    } 
} 

Pamiętaj, że Twój kod testowy nigdy nie zostanie wykonany. Przestrzeń nazw {} mówi do linkera, że ​​ten kod nigdy nie jest używany poza bieżącą jednostką kompilacji (tj. Test_S.cpp) i dlatego zostanie usunięty zaraz po sprawdzeniu kompilacji.

Ponieważ ten kod nigdy nie jest wykonywany, nie trzeba tworzyć prawdziwego obiektu S w funkcji testu. Po prostu chcesz oszukać kompilatora, aby sprawdzić, czy obiekty S mają funkcję wywoływalną f().