Jaki jest najbezpieczniejszy sposób na zdefiniowanie aliasów nazw krótkich funkcji w C++?

Question

Załóżmy, że mam klasę Utility w pliku utility.h:

class Utility { 
public: 
    static double longDescriptiveName(double x) { return x + 42; } 
}; 

I wtedy okaże się, że mogę korzystać z funkcji longDescriptiveName(...) dużo. Tak jak nieodpowiedzialny programista C++, że jestem kiedy miałem zbyt dużo kawy, tworzę nowy plik utilitymacros.h i dodać następujące tam:

#define ldn Utility::longDescriptiveName 

Teraz to "utilitymacros.h" w dowolnym *.cpp gdzie używam ldn(...) i My serce napełnia się radością nad tym, jak wiele bardziej wygodnym to jest typ 3 litery vs 28.

Pytanie: Czy jest bezpieczniejsze (bardziej właściwe) sposób to zrobić niż z #define?

Zauważyłem, że muszę dołączyć "utilitymacros.h" po dodaniu nagłówków doładowania, których oczywiście nie lubię, ponieważ jest to oznaka starć (chociaż otrzymane błędy Boost nie są zbyt jasne co do tego, zderzenie jest).

Wyjaśnienie 1: Na czytelności kodu

W przypadku można powiedzieć, że ta negatywnie wpływa na czytelność kodu, zapewniam cię, że nie, bo to mały zestaw funkcji, które są wykorzystywane dużo. Przykładem, który jest powszechnie znany, jest stoi dla stringToInteger. Innym jest pdf dla probabilityDensityFunction itp Więc jeśli chcę wykonać następujące czynności, stoi jest bardziej czytelny moim zdaniem:

int x = stoi(a) + stoi(b) + stoi(c) + stoi(d); 

niż:

int x = Utility::stringToInteger(a) + Utility::stringToInteger(b) 
     + Utility::stringToInteger(c) + Utility::stringToInteger(d); 

czyli

int x = Utility::stringToInteger(a); 
x += Utility::stringToInteger(b); 
x += Utility::stringToInteger(c); 
x += Utility::stringToInteger(d); 

Klasyfikacja 2: Makro edytora

Używam Emacsa jako mojego IDE i klawiatury Kinesis, dzięki czemu wiesz, że używam mnóstwa makr na klawiaturze, niestandardowych skrótów klawiaturowych, a także faktycznie modyfikuję to, co widzę w edytorze, a co faktycznie jest przechowywane w pliku h/cpp . Ale wciąż mam wrażenie, że prostota i czytelność wizualna (jak argumentowano powyżej) użycia skrótu funkcji w kilku wybranych przypadkach jest tak naprawdę wynikiem, którego szukam (jest to z pewnością zależne od stopnia).

Answer 1

Zamiast makro, można napisać inline funkcję, która przekierowuje połączenie do rzeczywistej funkcji:

inline double ldn(double x) 
{ 
    return Utility::longDescriptiveName(x); 
} 

To z pewnością bezpieczniejsze niż makro.

Answer 2

Co powiesz na skonfigurowanie snippitu/makra/podobnej rzeczy w edytorze tekstu? W ten sposób wystarczy wpisać ldn lub coś w tym stylu, a kod nie musi przebiegać przez preprocesor, ryzykując, że później trudno będzie znaleźć błędy.

Answer 3

Można użyć odniesienie funkcję:

double (&ldn)(double) = Utility::longDescriptiveName; 

Answer 4

ja nie wiem, czy to pomoże, ale myślę, że częścią problemu może być użycie zbyt ogólnych nazw (lub nazw klas, w tym przypadku), na przykład Utility.

Jeśli zamiast Utility::stringToInteger, mieliśmy

namespace utility { 
    namespace type_conversion { 
    namespace string { 
     int to_int(const std::string &s); 
    } 
    } 
} 

Następnie funkcja mogła lokalnie być używane tak:

void local_function() 
{ 
    using namespace utility::type_conversion::string; 

    int sum = to_int(a) + to_int(b) + to_int(c) + to_int(d); 
} 

Analogicznie, jeśli stosowane są ćwiczenia/kodowanym i funkcje statyczne (i nie może być tego powodem), mamy coś w rodzaju:

strut utility { 
    struct type_conversion { 
    struct string { 
     static int to_int(const std::string &s); 
    }; 
    }; 
}; 

lokalna funkcja wyglądałaby tak:

void local_function() 
{ 
    typedef utility::type_conversion::string str; 

    int sum = str::to_int(a) + str::to_int(b) 
       + str::to_int(c) + str::to_int(d); 
} 

Zdaję sobie sprawę, że nic ci nie mówię o składni, której już nie znałeś; przypomina to raczej o tym, że sama organizacja i struktura przestrzeni nazw i klas odgrywa ważną rolę w zwiększaniu czytelności kodu (i zapisywalności).

Answer 5

Jedną z alternatyw jest zmiana nazwy funkcji i umieszczenie jej w przestrzeni nazw zamiast w klasie, ponieważ i tak jest statyczna. utility.h staje

namespace Utility { 
    // long descriptive comment 
    inline double ldn(double x) { return x + 42; } 
} 

Następnie można umieścić using namespace Utility; w kodzie klienta.

Wiem, że istnieje wiele przewodników po stylach mówiących, że krótkie imiona są złe, ale nie widzę sensu słuchania jakiegoś stylu, a następnie obchodzenia go.