Возник спор - где лучше ставить звёздочку(для читабельности) - перед объявляемым типом или непосредственно после типа. Т.е. делать int* char или int *char? Как делаете вы?
>> int *ptr;
+1
Раз уж пошла такая тема...
if (smthng) do_some_evil1();
else do_some_evil2();
vs.
if (smthng)
do_some_evil1();
else
do_some_evil2();
&&
if (smthng)
{
/* ... */
}
vs.
if (smthng) {
/* ... */
}
???
ну да, где-то так. впрочем, некоторые кто посообразительнее пошли езё дальше и заменили 8 на 4 а tabs на spaces но это уже где-то ближе к гуру, то не всем дано понять.
А это не ложится в c++'сную идеологию. Ибо нефиг определять переменные до их инициализации. А если сразу инициализировать, то можно и на несколько строк разнести, читабельнее будет.
>А если сразу инициализировать, то можно и на несколько строк
> разнести, читабельнее будет.
int* i = abyrwalg(1),
j = abyrwalg(2),
k = abyrwalg(3);
Сильно помогло? ;)
int, вестимо. Именно поэтому лучше писать звёдочку рядом с именем переменной. Хотя ещё лучше не совмещать объявление нескольких переменных в одной строке.
>>> int *ptr;
> +1
> Раз уж пошла такая тема...
> if (smthng) do_some_evil1();
> else do_some_evil2();
> vs....
if (smthng) {
do_some_evil1();
} else {
do_some_evil1();
}
Так не надо будет добавлять скобки, если по каждой ветке захочется добавить ещё пару действий. Ну и не будет проблем при одновременном использовании C и Tcl :)
Совершенно пофиг. Ибо во-первых любой сишник знает, к чему относится звёздочка, во-вторых компилятор на спутанный тип скорее всего ругаться будет, и ошибка обнаружится при первой же компиляции.
это не столько вопрос читабельности, сколько вопрос coding style. обсуждается коллективно. главное - чтобы все писали одинаково. у нас было принято int * ptr, именно из-за двойственного прочтения
с учётом аватарки совет особенно прекрасен. по теме : подход с typedef в данном случае - дерьмо, ибо вместо самодокументированного символа * получаем зоопарк унылых нестандартизованных имён, и сопутствующие развлечения во время отладки
> по теме : подход с typedef в данном случае - дерьмо, ибо вместо самодокументированного символа * получаем зоопарк унылых нестандартизованных имён, и сопутствующие развлечения во время отладки
* Integer types capable of holding object pointers
The following type designates a signed integer type with the property that any valid pointer to void can be converted to this type, then converted back to a pointer to void, and the result will compare equal to the original pointer: intptr_t
The following type designates an unsigned integer type with the property that any valid pointer to void can be converted to this type, then converted back to a pointer to void, and the result will compare equal to the original pointer: uintptr_t
[XSI] [Option Start] On XSI-conformant systems, the intptr_t and uintptr_t types are required; [Option End] otherwise, they are optional.
> стандартный intptr_t был введён не потому, что вломы писать звёздочку и предназначен мягко говоря не для этого.
ни о каком стандартном intptr я не собирался философствовать, я лишь об еще одной возможности записи, поведал. Если будет легче, давайте назовем новый тип IntRef, хотя это не православное название, т.к. это не референс в плюсовом понимании. Однако суффикс Ref на практике не так уж и редко используется.
Очевидно что для int-а, такое сокращение не особо имеет смысл, но для более громоздкого типа может пригодится, т.к. предоставляет еще один из механизмов для реализации инкапсуляции: в *.h файле дефайним тип как void*, а в файле реализации - дефайним "по нормальному".
>> в *.h файле дефайним тип как void*, а в файле реализации - дефайним "по нормальному"
>Бгг.
ржы-ржы-ржы.. А потом посмотри, как например устроен интерфейс у Core Foundation в OS X, или у многих "рядом идущих" фреймворков, там ногочисленные CFStringRef-ы и CFArrayRef-ы, правда они для большей type safe-ности дефайнятся как указатели на нигде (в публичном доступе) не обьявленные структуры.
> Ну то есть разумные люди один и тот же typedef по-разному всё же не определяют, ага? О том и спич.
void* был применен для демонстрации концепции, про разумность -- нет, не разумные, многократно встречаются typedef-ы, которые в зависимости от дефайнов (аля __APPLE_API_INTERNAL__) дефайнятся либо так, либо так, на разные структуры указывая).