Const przed czy const po?

Na początek prawdopodobnie wiesz, że constmożna to wykorzystać do uczynienia danych obiektu lub wskaźnika niemodyfikowalnymi lub obu.

const Object* obj; // can't change data
Object* const obj; // can't change pointer
const Object* const obj; // can't change data or pointer

Możesz jednak również użyć składni:

Object const *obj; // same as const Object* obj;

Jedyne, co wydaje się mieć znaczenie, to po której stronie gwiazdki umieścisz constsłowo kluczowe. Osobiście wolę umieścić constpo lewej stronie typu, aby określić, że dane nie są modyfikowalne, ponieważ uważam, że lepiej czyta się w moim nastawieniu od lewej do prawej, ale która składnia była pierwsza?

Co ważniejsze, dlaczego istnieją dwa prawidłowe sposoby określania constdanych i w jakiej sytuacji wolałbyś lub potrzebowałbyś jednego nad drugim, jeśli w ogóle?

Edytować:

Wygląda więc na to, że była to arbitralna decyzja, kiedy standard dotyczący tego, jak kompilatorzy powinni interpretować rzeczy, został opracowany na długo przed moim urodzeniem. Ponieważ constjest stosowane do tego, co znajduje się po lewej stronie słowa kluczowego (domyślnie?), Domyślam się, że nie było nic złego w dodaniu „skrótów” do stosowania słów kluczowych i kwalifikatorów typów w inny sposób, przynajmniej do czasu, gdy deklaracja zmieni się o analizowanie * lub & ...

Tak było również w C, więc zakładam?

dlaczego istnieją dwa poprawne sposoby określania constdanych i w jakiej sytuacji wolisz lub potrzebujesz jednego nad drugim, jeśli w ogóle?

Zasadniczo powodem, dla którego pozycja constwewnątrz specyfikatorów przed gwiazdką nie ma znaczenia, jest to, że gramatyka języka C została zdefiniowana w ten sposób przez Kernighana i Ritchiego.

Powodem, dla którego zdefiniowali gramatykę w ten sposób, było prawdopodobne, że ich kompilator C przeanalizował dane wejściowe od lewej do prawej i zakończył przetwarzanie każdego tokenu, gdy je zużywał. Użycie *tokenu zmienia stan bieżącej deklaracji na typ wskaźnika. Spotkanieconst po *oznacza, że constkwalifikator jest stosowany do deklaracji wskaźnika; napotykając go przed *środkami, kwalifikator jest stosowany do wskazanych danych.

Ponieważ znaczenie semantyczne nie zmienia się, jeśli constkwalifikator pojawia się przed lub po specyfikatorach typu, jest akceptowany w obu przypadkach.

Podobny przypadek pojawia się przy deklarowaniu wskaźników do funkcji, gdzie:

• void * function1(void)deklaruje funkcję, która zwraca void *,
  

• void (* function2)(void)deklaruje wskaźnik funkcji do funkcji, która zwraca void.

Znowu należy zauważyć, że składnia języka obsługuje parser od lewej do prawej.

Zasada jest taka:

const dotyczy tego, co z niego zostało. Jeśli nic nie znajduje się po lewej stronie, dotyczy to rzeczy po prawej stronie.

Wolę używać const po prawej stronie rzeczy, aby być const tylko dlatego, że jest to „oryginalny” sposób definiowania const.

Myślę jednak, że jest to bardzo subiektywny punkt widzenia.

Wolę drugą składnię. Pomaga mi śledzić to, co jest stałe, czytając deklarację typu od prawej do lewej:

Object * const obj;        // read right-to-left:  const pointer to Object
Object const * obj;        // read right-to-left:  pointer to const Object
Object const * const obj;  // read right-to-left:  const pointer to const Object

Kolejność słów kluczowych w deklaracji nie jest ustalona. Istnieje wiele alternatyw dla „jedynego prawdziwego porządku”. Lubię to

int long const long unsigned volatile i = 0;

czy powinno być

volatile unsigned long long int const i = 0;

??

Pierwszą zasadą jest użycie dowolnego formatu wymaganego przez lokalne standardy kodowania. Po tym: umieszczenie początku constna początku prowadzi do niekończącego się zamieszania, gdy w grę wchodzą kroje pisma, np .:

typedef int* IntPtr;
const IntPtr p1;   // same as int* const p1;

Jeśli twój standard kodowania zezwala na typedef wskaźników, to naprawdę powinien nalegać na umieszczenie stałej po typie. W każdym przypadku, ale w przypadku zastosowania do typu, const musi być zgodne z tym, do czego się odnosi, więc spójność również przemawia na korzyść stałej po. Ale lokalne wytyczne dotyczące kodowania mają przewagę nad wszystkimi tymi; różnica zwykle nie jest na tyle ważna, aby wrócić i zmienić cały istniejący kod.

Istnieją historyczne powody, dla których lewica lub prawica są dopuszczalne. Stroustrup dodał const do C ++ w 1983 roku , ale nie dotarł do C aż do C89 / C90.

W C ++ jest dobry powód, aby zawsze używać const po prawej stronie. Będziesz spójny wszędzie, ponieważ funkcje składowe const muszą być deklarowane w ten sposób:

int getInt() const;