LINUX.ORG.RU

Попробуй скомпилить так и так, и сравнить ассемблерный код. Мне кажется он будет одинаковый

xorik ★★★★★
()

Монописуально. Я всегда а+1 делаю.

staseg ★★★★★
()

Первый вариант понятнее.

olibjerd ★★★★★
()

Правильнее &a[1]. Потому что понятнее.

«а+1» в неуместных местах пишут фашисты от программирования.

ttnl ★★★★★
()
Ответ на: комментарий от Eddy_Em

Не подкрепленные опытом галлюцинации

ttnl ★★★★★
()

В C++ &( a[1]), в С a+1.

trex6 ★★★★★
()
Ответ на: комментарий от ttnl

Никакой разницы в читабельности нет.

&a[1] часто возникает, когда было готовое выражение, и к нему подставили &. a + 1 — когда набирали строчку с нуля.

geekless ★★
()
Ответ на: комментарий от staseg

Из которой не видно, что речь идет об адресе.

Все эти специальные символы для того и придумали, чтобы облегчить анализ кода. Чтобы с первого взгляда понимать, что речь идет об адресе, а не об абстрактном сложении.

ttnl ★★★★★
()
Ответ на: комментарий от geekless

&a[1] часто возникает, когда было готовое выражение, и к нему подставили &. a + 1 — когда набирали строчку с нуля.

Если в одном и том же коде при одинаковых условиях встречаются оба типа выражений, то его автор - идиот и быдлокодер.

ttnl ★★★★★
()

Первый вариант проще для однократного использования. В случае с доступом по указателю бывает удобно делать так (например, для многомерных массивов):

type a[DIM_ONE][DIM_TWO];
...
for( pa=a[1]; cond(pa); pa++ )
{
...
}
Для сишников, пишущих на питоне, это неприемлемо :)

placeholder
()
Ответ на: комментарий от ttnl

Бгг. Тебе не приходило в голову, что код существует годами, и над ним работают десятки человек? ЛОР такой ЛОР.

geekless ★★
()

вообще от ситуации зависит. можно еще &1[a]

waker ★★★★★
()

Адресная арифметика очевидный плюс C-подобных, я всегда пользовался вторым вариантом.

z00ke
()

Всегда считал что правильнее &a[1]

ну тогда пиши:

p = &a[p-a+1];

вместо:

p++;

wota ★★
()
Ответ на: комментарий от geekless

Тебе не приходило в голову, что код существует годами, и над ним работают десятки человек?

Если ни в одном из вовлекавших тебя проектов не были приняты общие для всех правила кодирования, то не могу не выразить своего сочувствия.

ttnl ★★★★★
()
Ответ на: комментарий от ttnl

Из которой не видно, что речь идет об адресе.

О том, что речь идет об адресе, видно из соседнего кода, где указатель объявляется или используется.

Все эти специальные символы для того и придумали, чтобы облегчить анализ кода.

Конкретно эта комбинация символов не специально придумана, а просто комбинация из двух операторов, выглядящая как нагроможденеи символов. А как анализировать код - дело каждого. Можно смотреть на соседний код, можно разглядывать эти операторы, можно давать специальные имена переменным-указателям...

staseg ★★★★★
()
Ответ на: комментарий от staseg

О том, что речь идет об адресе видно из соседнего кода, где указатель объявляется или используется.

Вот именно, нужно узнавать это где-то сбоку, что неудобно. Почему бы ни распарсивать выражение с первого взгляда!

Конкретно эта комбинация символов не специально придумана, а просто комбинация из двух операторов, выглядящая как нагроможденеи символов. А как анализировать код - дело каждого. Можно смотреть на соседний код, можно разглядывать эти операторы, можно давать специальные имена переменным-указателям...

Амперсент - это специальный оператор, который трактуется однозначно. Амперсент со скобками - тем более. То, что внутри скобок, внутри и остается и легко анализируется.

Это намного удобнее, чем вспоминать тип каждой конкретной переменной.

ttnl ★★★★★
()
Ответ на: комментарий от placeholder

В массиве-то? Вы про Си вообще?

Если непонятно, о чем идет речь, см. исходное сообщение и тэги

ttnl ★★★★★
()
Ответ на: комментарий от ttnl

Имхо, дело привычки, ведь код

std::string buf="sometext";
std::cout<<buf+"anothertext"<<std::endl;
никого не удивляет.

placeholder
()
Ответ на: комментарий от placeholder

Речь о том что не понятно без контекста. a+1 в названии топика тоже бы трактовалось как плюс один к числовому значению «а» не будь оно противопоставлено &a[1].

Kalashnikov ★★★
()

Хороший синтаксис как пишется, так и читается. Поэтому предпочитаю &a[1].

unsigned ★★★★
()
Ответ на: комментарий от ttnl

Как там было... Если непосредственно из кода функции не ясно, является ли переменная указателем, «то его автор - идиот и быдлокодер» (c)

geekless ★★
()
Ответ на: комментарий от geekless

Если непосредственно из кода функции не ясно, является ли переменная указателем, «то его автор - идиот и быдлокодер» (c)

Если даже из кода функции непонятно, то ее автор - придурок, однозначно.

Другое дело, что код остальной функции - это дополнительная информация, которую тоже требуется анализировать.

Поэтому не стоит специально усложнять себе жизнь.

ttnl ★★★★★
()
Ответ на: комментарий от ttnl

a+1 — что это? Это адрес или значение? Вот это непонятно.

а++ - что это?

wota ★★
()
Ответ на: комментарий от ttnl

общие для всех правила кодирования

Подобные правила тяжело энфорсить.

Miguel ★★★★★
()

Пиши код а не страдай ерундой.

Legioner ★★★★★
()

Эти два представления эквивалентны. При этом второе (a+1) - ближе к тому, что на самом деле происходит при определении адреса второго элемента массива, а первое (&a[1]) - «синтаксический сахар», который тоже самое только естественнее, понятнее для человека. И сахар это вводят в языки, чтобы им пользовались, поэтому использовать второе представление стоит только, если на то есть особые причины.

gag ★★★★★
()
Ответ на: комментарий от Eddy_Em

по-моему, удобнее написать «a + i*j», нежели «&a[i*j]». Первая конструкция более понятна же.

Нужно найти адрес i*j-того элемента массива a.

Для этого сначала берём i*j-ый элемент массива a:

a[i*j]
а потом узнаём его адрес:
&a[i*j]
На мой взгляд так всё последовательно и понятно.

А в a+ij кроются детали реализации.

gag ★★★★★
()
Ответ на: комментарий от gag

А по мне второе понятнее: берем адрес массива и прибавляем к нему i*j

Eddy_Em ☆☆☆☆☆
()

В правильных языках нет ни то, ни другого варианта. Там просто такой ересью не страдают.

anonymous
()

А контекст каждый волен придумать по вкусу? - потому что ваша конструкция в голом виде бесполезна.

level1 ★★
()

Правильность определяется в зависимости от контекста. Где-то ты именно занимаешься адресной арифметикой, там понятнее a+1, в другом месте ты все считаешь в индексах и лишь в определенный момент тебе нужно получить адрес элемента с индексом, здесь уже более ожидаем первый вариант.

m0rph ★★★★★
()

Всем спасибо.

LinuxUser ★★★
() автор топика
Ответ на: комментарий от xorik

Я знаю хороший способ детектить дебилов. Когда разговор идет о семантике языка, у которого есть стандарт, они предлагают:

Попробуй скомпилить так и так, и сравнить ассемблерный код.

anonymous
()
Ответ на: комментарий от Boy_from_Jungle

угу, передай то что ты написал в ф-цию на С которая принимает указатель

сделать указатель из ссылки проще чем то, что написал ты

wota ★★
()

*(((void**)x)+1) или ((void**)x)[1]?

queen3 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.