Jakie są Twoje ulubione idiomy stylu kodowania C++ [zamknięte]

RAII: Resource Acquisition Is Initialization

RAII może być najważniejszym idiomem. Chodzi o to, że zasoby powinny być mapowane do obiektów, tak aby ich żywotność była zarządzana automatycznie zgodnie z zakresem, w którym obiekty te są deklarowane.

Na przykład, jeśli na stosie został zadeklarowany uchwyt pliku, powinien on być niejawnie zamknięty po powrocie z funkcji(lub pętli, lub dowolnego zakresu, w którym został zadeklarowany). Jeśli dynamiczna alokacja pamięci była przydzielany jako członek klasy, powinien być niejawnie uwolniony, gdy ta instancja klasy zostanie zniszczona. I tak dalej. Każdy rodzaj zasobu-alokacje pamięci, uchwyty plików, połączenia z bazą danych, gniazda i każdy inny rodzaj zasobu, który ma zostać pozyskany i zwolniony-powinien być zawinięty w taką klasę RAII, której żywotność zależy od zakresu, w którym został zadeklarowany.

Jedną z głównych zalet tego jest to, że C++ gwarantuje wywoływanie destruktorów, gdy obiekt wychodzi z scope, niezależnie od tego, jak kontrola opuszcza ten scope . Nawet jeśli zostanie wyrzucony wyjątek, wszystkie lokalne obiekty wyjdą poza zakres, a więc ich powiązane zasoby zostaną wyczyszczone.

void foo() {
  std::fstream file("bar.txt"); // open a file "bar.txt"
  if (rand() % 2) {
    // if this exception is thrown, we leave the function, and so
    // file's destructor is called, which closes the file handle.
    throw std::exception();
  }
  // if the exception is not called, we leave the function normally, and so
  // again, file's destructor is called, which closes the file handle.
}

Niezależnie od tego, jak opuścimy funkcję i co się stanie po otwarciu pliku, nie musimy jawnie zamykać Pliku ani obsługiwać WYJĄTKÓW (np. try-finally) wewnątrz tej funkcji. Zamiast tego plik zostanie wyczyszczony, ponieważ jest powiązany z lokalnym obiektem, który zostanie zniszczony kiedy wyjdzie poza zasięg.

Zobacz też:

• ScopeGuard pozwala kodowi "automatycznie wywoływać operację cofania".. w przypadku wyrzucenia wyjątku."

Copy-swap

Idiom copy-swap zapewnia bezpieczne kopiowanie WYJĄTKÓW. Wymaga to zaimplementowania poprawnej kopii ctor i swap.

struct String {
  String(String const& other);

  String& operator=(String copy) { // passed by value
    copy.swap(*this); // nothrow swap
    return *this; // old resources now in copy, released in its dtor
  }

  void swap(String& other) throw() {
    using std::swap; // enable ADL, defaulting to std::swap
    swap(data_members, other.data_members);
  }

private:
  Various data_members;
};
void swap(String& a, String& b) { // provide non-member for ADL
  a.swap(b);
}

Można również zaimplementować metodę swap za pomocą ADL (Argument Dependent Lookup) bezpośrednio .

Ten idiom jest ważny, ponieważ zajmuje się samo-przypisywaniem^[1], daje gwarancję silnego wyjątku^[2], i często jest bardzo łatwy do napisania.

^[1] nawet jeśli samo zadanie nie jest obchodzić się tak sprawnie, jak to tylko możliwe, to powinno być rzadkie , więc jeśli to się nigdy nie stanie, to tak naprawdę jest szybciej.

^[2] jeśli jakikolwiek wyjątek zostanie wyrzucony, stan obiektu (*this) nie zostanie zmodyfikowany.

CRTP: ciekawie powtarzający się wzór szablonu

CRTP dzieje się, gdy przekazujesz klasę jako parametr szablonu do jej klasy bazowej:

template<class Derived>
struct BaseCRTP {};

struct Example : BaseCRTP<Example> {};

W obrębie klasy bazowej, może uzyskać pochodną instancję, wraz z typem pochodnym , po prostu przez odlewanie (albo static_cast lub dynamic_cast ):

template<class Derived>
struct BaseCRTP {
  void call_foo() {
    Derived& self = *static_cast<Derived*>(this);
    self.foo();
  }
};

struct Example : BaseCRTP<Example> {
  void foo() { cout << "foo()\n"; }
};

W efekcie, call_foo zostało wstrzyknięte do klasy pochodnej z pełnym dostępem do klasy pochodnej członków.

Zapraszam do edycji i dodawania konkretnych przykładów użycia, ewentualnie do innych postów SO .

PImpl: Pointer-to-Implementation

Idiom pImpl jest bardzo przydatnym sposobem oddzielenia interfejsu klasy od jej implementacji.

Zazwyczaj definicja klasy musi zawierać zmienne członkowskie, jak również metody, które mogą ujawniać zbyt wiele informacji. Na przykład zmienna członkowska może być typu zdefiniowanego w nagłówku, którego nie chcemy wszędzie umieszczać.

Nagłówek windows.h jest tutaj najlepszym przykładem. Możemy chcieć zawinąć HANDLE lub inny typ Win32 wewnątrz klasy, ale nie możemy umieścić HANDLE w definicji klasy bez konieczności włączania windows.h wszędzie, gdzie klasa jest używana.

Rozwiązaniem jest utworzenie P rivateIMPL ementation lubPointer-to-IMPL ementation klasy, i niech publiczna implementacja przechowuje tylko wskaźnik do prywatnej i przekazuje wszystkie metody członkowskie.

Na przykład:

class private_foo; // a forward declaration a pointer may be used

// foo.h
class foo {
public:
  foo();
  ~foo();
  void bar();
private:
  private_foo* pImpl;
};

// foo.cpp
#include whichever header defines the types T and U

// define the private implementation class
class private_foo {
public:
  void bar() { /*...*/ }

private:
  T member1;
  U member2;
};

// fill in the public interface function definitions:
foo::foo() : pImpl(new private_foo()) {}
foo::~foo() { delete pImpl; }
void foo::bar() { pImpl->bar(); }

Wdrożenie foo jest teraz oddzielone od jego publicznego interfejs, tak że

• może używać elementów składowych i typów z innych nagłówków, nie wymagając, aby te zależności były obecne, gdy klasa jest używana, oraz
• implementacja może być modyfikowana bez wymuszania rekompilacji kodu używającego klasy.

Użytkownicy klasy po prostu dołączają nagłówek, który nie zawiera nic konkretnego na temat implementacji klasy. Wszystkie szczegóły implementacji zawarte są w foo.cpp.

Lubię ustawiać kod/inicjalizację w 'kolumnach'... Okazuje się bardzo przydatny przy edycji z edytorem zdolnym do trybu "kolumnowego", a także wydaje mi się dużo łatwiejszy do odczytania...

int myVar        = 1;    // comment 1
int myLongerVar  = 200;  // comment 2

MyStruct arrayOfMyStruct[] = 
{   
    // Name,                 timeout,   valid
    {"A string",             1000,      true    },   // Comment 1
    {"Another string",       2000,      false   },   // Comment 2 
    {"Yet another string",   11111000,  false   },   // Comment 3
    {NULL,                   5,         true    },   // Comment 4
};

Natomiast pojawi się ten sam kod, który nie jest wcięty i sformatowany jak powyżej... (A little harder to read to my eyes)

int myVar = 1; // comment 1
int myLongerVar = 200; // comment 2

MyStruct arrayOfMyStruct[] = 
{   
    // Name, timeout, valid
    {"A string", 1000, true},// Comment 1
    {"Another string", 2000, false }, // Comment 2 
    {"Yet another string", 11111000,false}, // Comment 3
    {NULL, 5, true }, // Comment 4
};

Public Top-Private Down

Pozornie mała optymalizacja, ale odkąd przeszedłem na tę konwencję, mam o wiele więcej zabawy, aby uchwycić moje zajęcia, zwłaszcza po tym, jak nie oglądałem ich od 42 lat.

Konsekwentna widoczność członków, przechodzenie od punktów częstego zainteresowania do nudnych rzeczy, jest niezwykle pomocna, zwłaszcza gdy kod powinien być samodokumentujący.

(uwaga dla Qt-userów: sloty są przed sygnałami, ponieważ powinny be called like non-slot member functions, and abstrahując od ich slottyness be unforgivable from non-slots)

• publiczne, chronione, prywatne
• potem Fabryka, ctor, dtor, kopiowanie, Zamiana
• wtedy interfejs klasy' Na koniec, w oddzielnej sekcji private:, pojawiają się dane (najlepiej tylko wskaźnik impl).

Ta zasada pomaga również ton, jeśli masz problemy z utrzymaniem deklaracji klasy w czystości.

class Widget : public Purple {
public:
    // Factory methods.
    Widget FromRadians (float);
    Widget FromDegrees (float);

    // Ctors, rule of three, swap
    Widget();
    Widget (Widget const&);
    Widget &operator = (Widget const &);
    void swap (Widget &) throw();

    // Member methods.
    float area() const;

    // in case of qt {{ 
public slots:
    void invalidateBlackHole();

signals:
    void areaChanged (float);
    // }}

protected:    
    // same as public, but for protected members


private:    
    // same as public, but for private members

private:
    // data
    float widgetness_;
    bool  isMale_;
};

W poleceniach if, gdy istnieją trudne warunki, można wyraźnie pokazać, na jakim poziomie każdy warunek jest używany za pomocą wcięcia.

if (  (  (var1A == var2A)
      || (var1B == var2B))
   && (  (var1C == var2C)
      || (var1D == var2D)))
{
   // do something
}

No favorites but I will fix code that has:

1. tabs-powoduje niewspółosiowość w wielu Idach i narzędziach do przeglądania kodu, ponieważ nie zawsze zgadzają się na tab w spacjach mod 8.
2. linie dłuższe niż 80 kolumn-spójrzmy prawdzie w oczy, krótsze linie są bardziej czytelne. Mój mózg może analizować większość konwencji kodowania, o ile linie są krótkie.
3. linie z końcowymi białymi spacjami-git będzie narzekał na to jako białe spacje błędy , które pojawiają się jako czerwone plamy w diffs, co jest irytujące.

Tutaj jest jednolinijkowy, aby znaleźć pliki obrażające:

git grep -I -E '<tab>|.{81,}|  *$' | cut -f1 -d: | sort -u

Gdzie <tab> jest znakiem tabulacji (Wyrażenie regularne POSIX nie robi \t)

Re: ididak

Naprawiam kod, który łamie długie instrukcje na zbyt wiele krótkich linii.

Spójrzmy prawdzie w oczy: to już nie lata 90. Jeśli Twoja firma nie może sobie pozwolić na panoramiczne LCD dla swoich koderów, musisz znaleźć lepszą pracę:)

Polimorfizm czasu kompilacji

(znany również jako polimorfizm syntaktyczny i polimorfizm statyczny, w przeciwieństwie do polimorfizmu czasowego.)

Z FUNKCJAMI szablonowymi, można pisać kod, który opiera się na konstruktorach typów i wywołaniu sygnatur rodzin parametryzowanych typów, bez konieczności wprowadzania wspólnej klasy bazowej.

W książce elementy programowania, autorzy określają to traktowanie typów jako abstrakcyjne rodzaje . Z koncepcje można określić wymagania dotyczące takich parametrów typu, choć C++ nie nakazuje takich specyfikacji.

Dwa proste przykłady:

#include <stdexcept>

template <typename T>
T twice(T n) {
  return 2 * n;
}

InIt find(InIt f, InIt l,
          typename std::iterator_traits<InIt>::reference v)
{
  while (f != l && *f != v)
    ++f;
  return f;
}   

int main(int argc, char* argv[]) {
  if (6 != twice(3))
    throw std::logic_error("3 x 2 = 6");

  int const nums[] = { 1, 2, 3 };
  if (nums + 4 != find(nums, nums + 4, 42))
    throw std::logic_error("42 should not have been found.");

  return 0;
}

Można wywołać twice z dowolnym typem regularnym, który ma zdefiniowany Operator binarny *. Podobnie, można wywołać find() z dowolnymi typami, które są porównywalne i że model iterator wejściowy . Jeden zestaw kodu działa podobnie na różnych typach, bez współdzielonych klas bazowych w zasięgu wzroku.

Oczywiście, co jest naprawdę chodzi o to, że ten sam kod źródłowy jest Rozszerzony do różnych funkcji specyficznych dla typu w czasie tworzenia szablonu, każda z osobnym wygenerowanym kodem maszynowym. Przyjęcie tego samego zestawu typów bez szablonów wymagałoby albo 1) oddzielnych funkcji pisanych odręcznie z określonymi podpisami, albo 2) polimorfizmu uruchomieniowego poprzez funkcje wirtualne.

Szablon i hak

Jest to sposób, aby obsłużyć jak najwięcej w frameworku i daćdrzwi lubhak do personalizacji przez użytkowników frameworka. Znany również jako Hotspot i metoda szablonów .

class Class {
  void PrintInvoice();     // Called Template (boilerplate) which uses CalcRate()
  virtual void CalcRate() = 0;  // Called Hook
}

class SubClass : public Class {
  virtual void CalcRate();      // Customized method
}

Opisany przez Wolfganga Pree w swojej książce wzorce projektowe dla programowania obiektowego.

Nie wiem, czy to się kwalifikuje do idiomu, ale sporo ciężkiego programowania szablonów zależy (często mocno) od SFINAE (substitution failure is not a error). Kilka odpowiedzi na poprzednie pytanie zawiera przykłady.

If/while / for wyrażenie (wyrażenia) w nawiasie z separatorem spacji

if (expression)  // preferred - if keyword sticks out more

Vs.

if(expression)  // looks too much like a void function call

To chyba oznacza, że lubię, gdy moje wywołania funkcji nie mają separatora spacji

foo(parm1, parm2);

Po pracy z kimś, kto był częściowo ślepy - I na jego prośbę-przerzuciłem się na korzystanie z wielu innych przestrzeni. Nie podobało mi się wtedy, ale teraz wolę. Poza moją głową, jedynym miejscem, gdzie nie ma białych spacji między identyfikatorami i słowami kluczowymi i tym podobne jest po Nazwa funkcji i przed poniższymi nawiasami.

void foo( int a, int b )
{
  int c = a + ( a * ( a * b ) );
  if ( c > 12 )
    c += 9;
  return foo( 2, c );
}

Naprawdę lubię umieszczać małe stwierdzenie w tej samej linii co if

int myFunc(int x) {
   if(x >20) return -1;
   //do other stuff ....
}

Nie wiem, czy to się liczy jako idiom, ale zazwyczaj używam komentarzy w stylu doxygen, nawet jeśli projekt nie używa jeszcze doxygen...

bool MyObjects::isUpToSomething() ///< Is my object up to something 

(na bok. Moje komentarze zazwyczaj nie są aż tak lamerskie.)

Przydatne jest umieszczanie nazw funkcji w nowej linii, dzięki czemu możesz grepować jak

grep -R '^fun_name' .

static void
fun_name (int a, int b) {
    /* ... */
}

Zapisuje każdą metodę lub argument funkcji w osobnej linii, tak aby można było ją łatwo skomentować.

int ReturnMaxValue(
    int* inputList,   /* the list of integer values from which to get the maximum */
    long size,        /* count of the number of integer values in inputList */
    char* extraArgs   /* additional arguments that a caller can provide.    */
)

Sugerowałbym PIMPL lub jak James Coplien pierwotnie nazywał to "korpus uchwytu".

Ten idiom pozwala całkowicie oddzielić interfejs od implementacji. Podczas pracy nad przepisaniem i ponownym wydaniem głównego komponentu middleware CORBA, ten idiom został użyty do całkowitego oddzielenia API od implementacji.

To praktycznie wyeliminowało wszelkie możliwości inżynierii odwrotnej.

Doskonałym źródłem dla idiomów C++ jest doskonała książka Jamesa Copliena " Advanced C++ Style programowania i idiomy". Gorąco polecam!

Edit: Jak zauważył poniżej Neil, ta książka jest dość nieaktualna, a wiele z jego zaleceń jest faktycznie włączonych do samego standardu C++. Jednak nadal uważam, że jest to źródło użytecznych informacji, esp. w formie pracy PLoP na temat idiomów C++ , w której wiele idiomów przekształcono w formę patterm.

Zawsze dodaję i edytuję:

• zbędne newlines
• Brak newline w EOF

Zwykle trzymam się KNF opisanego w stylu *BSD (9)

Dokumentuje zwracane wartości w linii funkcji, dzięki czemu są one bardzo łatwe do znalezienia.

int function(void) /* return 1 on success, 0 on failure */ 
{
    return 1;
};

Mam tendencję do stawiania innych na wszystkich moich "if".

if (condition)
{
    complicated code goes here
}
else
{
    /* This is a comment as to why the else path isn't significant */ 
}