Такс, на самом деле прежде чем спорить, мне стоило бы почитать стандарт.
ISO/IEC 9899:201x, пункт 6.5.2.1 Array subscripting:
Successive subscript operators designate an element of a multidimensional array object.
If E is an n-dimensional array (n ≥ 2) with dimensions i × j ×... × k, then E (used as
other than an lvalue) is converted to a pointer to an (n − 1)-dimensional array with
dimensions j ×... × k.
Так что да, признаю, был не прав.
Но пока что не могу изменить своего мнения насчет практического использования указателей как массивов, о чем писал в предыдущем комментарии. Так что по-прежнему нахожу противопоставление указателя и "указателя на массив" запутывающим.
Тем не менее, array "распадается" в обычный указатель int * — и таким указателем можно пользоваться так же, как самим массивом, без разыменования.
Двумерный массив распадется в указатель int (*a)[2] — и таким указателем, опять же, можно пользоваться как самим массивом.
У меня не такой уж большой опыт программирования, но я еще никогда не видел, чтобы чей-то код ожидал одномерный массив по указателю типа int (*a)[2]; все массивы везде передаются как пара int * и размер.
Соответственно моя основная претензия все-таки к называнию int (*a)[2] "указателем на массив" (хотя пример в вашем комментарии логичен); поскольку это противоречит сложившейся практике и только сильнее запутывает.
К тому же непонятно как тогда называть int (*a)[2][2]?
Лучше поздно, чем никогда :) Осмелюсь вам возразить:
«Указатель на массив». Строго говоря, «указатель на массив» — это именно указатель на массив и ничто другое. Иными словами: int (*a)[2]; // Это указатель на массив. Самый настоящий. Он имеет тип int (*TYPE)[2]
Интересно, почему же "указатель на массив" не может указывать на массив?
int (*a)[2];
int array[2] = {0};
a = array;
jdoodle.c:7:7: warning: assignment to ‘int (*)[2]’ from incompatible pointer type ‘int *’ [-Wincompatible-pointer-types]
7 | a = array;
| ^
Окей, проигнорируем варнинг, попробуем обратиться по "указателю на массив":
a[0] = 1;
error: assignment to expression with array type
Почему же? Потому что int (*a)[2] — это не "указатель на массив", а указатель на двумерный массив, у которого вторая размерность равна 2. Поэтому по такому указателю можно будет обратиться через двойные квадратные скобки и компилятор проведет вычисление смещения до элемента, так же, как сделал бы это для обычного двумерного массива.
А int (*a)[2][3] был бы указателем на трехмерный массив соответствующих размерностей.
Но никак не просто "указателем на массив"!
int b[2];
int *c = b; // Это не указатель на массив. Это просто указатель. Указатель на первый элемент некоего массива
int *d = new int[4]; // И это не указатель на массив. Это указатель
Безусловно, int * a — это просто указатель. Но он может указывать и на массив (на первый элемент массива), именно поэтому к указателю можно применять оператор квадратные скобки. Как будто это одномерный массив.
Соответственно "неформально" говорят "указатель на массив" всего лишь имея в виду, что это указатель на одномерный массив.
Разумеется, int * может указывать и не на массив вовсе, а на отдельную переменную, но это на уровне языка неразличимо. Соответственно фраза "указатель на массив" дополнительно подчеркивает, что по указателю лежит именно массив.
Мне было скорее интересно, есть ли у вас какая-то любимая "медитативная" активность, не связанная с потреблением информации. Т.е. есть ли у вас время, чтобы побыть "наедине с собой".
В целом, ваши доводы звучат логично и я не чувствую себя достаточно квалифицированным, чтобы их оспаривать.
Тем не менее, вполне возможно что просто бенчмаркинг был проведен плохо, а мы тут пытаемся артефакты измерений как-то объяснить рационально. На мой взгляд, данных в статье просто мало.
Ну на то и обсуждение, чтобы подсказать идею. Может, автор сам это сделает, а может, кто-то ещё...
Жаль, что это перевод. Так что вся надежда на кого-то еще.
По-моему, всё чётко однозначно. Или вы не верите тут даже Intel?
Intel я, конечно, верю, хотя тут сказано конкретно о предсказании, когда этот переход выполняется впервые (если я правильно понимаю — do not have a history подразумевает это).
Соответственно, неясно, как это повлияет на код из поста. Переходов назад при обработке ошибок в любом случае быть не должно (вроде как?), т.е. тогда влияет порядок обработки условий в if'e.
Но влиять-то он должен все равно только в самый первый раз когда совершается этот конкретный переход, а дальше все будет зависеть от того, насколько предсказуемые входные данные в тесте.
Если в них ошибки чаще не происходят, то и предсказываться будет соответствующая ветка. Иначе какой смысл в динамическом предсказании вообще?
Честно говоря, у меня основные вопрос все же к посту — нет толком ни кода бенчмарка, ни попытки вникнуть в ассемблер, чтобы понять, почему же так выходит.
В идеале — конечно. Но моя реальность уже такова, что эти люди пришли, и будут приходить каждый год — и с ними надо что-то делать. Отчислить при этом кого-то практически нереально (такова политика ВУЗа).
Я пока что пришел к мысли, что нужно стараться вовлечь в процесс как можно больше людей, но на тех, кто никак не вовлекается — просто не тратить слишком много сил и нервов.
Плюс нельзя забывать, что даже те, кто поступил осознанно, может быть не очень мотивирован или нуждаться в некотором давлении обстоятельств, чтобы шевелиться.
Повторюсь — это вы предполагаете или точно знаете?
Я лично достаточно приблизительно в курсе, как работают предсказатели переходов, но предполагаю, что современные реализации довольно сложны. Поэтому не рискну вот так, без реальных замеров на конкретном процессоре, утверждать, что будет быстрее, а что медленнее.
Не знаю, как у вас, но по моим наблюдениям около 40% группы идут в ВУЗ не потому, что хотят получить эту специальность, а потому что родители заставили, от армии косят или "все пошли — и я пошел". С чего бы им изначально быть мотивированными?
Часть из них можно замотивировать уже в процессе обучения, при некотором напряжении (и везении), конечно.
Гитом как таковым нужно уметь пользоваться 100%, на этом сейчас почти все пайплайны завязаны, соответственно разработчику с этим придется взаимодействовать.
Это-то понятно. Но я все-таки не хочу слишком сильно усложнять студентам (и себе) жизнь. Про гит и клиенты к нему я рассказываю, кто хочет (читай — у кого глаза горят) — поставит и будет пользоваться, а кому лишь бы сдать и забыть, тем и через браузер норм, у них и без этого с предметом проблем достаточно -_-
Лично я от студентов вообще не требую пользоваться каким-то клиентом git'a и в результате получаю 80% коммитов, сделанных через браузер, с названием "Added files via upload" -_-
Относительно небольшое количество студентов все же делает осмысленные коммиты и пользуется при этом каким-то клиентом. Но можно ли (и стоит ли) заставлять всех? Вот не знаю даже.
Я работаю в отделе, где почти все массово переходили с TortoiseSVN на TortoiseGit… и на мой взгляд корреляция с пониманием была, скорее с общим уровнем разработчика.
Или, можно сказать, кто хотел — разобрался. То, что три человека сидели на SourceTree, им вроде как не помогло.
Лично мне TortoiseGit нравится в основном понятным логом (не, можно конечно написать git log --branches=* --graph --oneline --decorate --all --pretty=format:'%C(yellow)%h %ad (%ar) [%an]%n%s%C(auto)%d%n', но до этого еще дойти нужно), который, как справедливо отмечают выше, интерактивный.
Ну и интеграция в проводник, по мне так тоже огромный плюс — если пользоваться проводником. Можно "окинуть взглядом" рабочую копию, не вводя никаких команд и не кликая, узнать, поменялось ли что-нибудь или нет.
Конечно, если пользоваться другой оболочкой, то постоянно в проводник переключаться только ради git'a не удобно.
Такс, на самом деле прежде чем спорить, мне стоило бы почитать стандарт.
ISO/IEC 9899:201x, пункт 6.5.2.1 Array subscripting:
Так что да, признаю, был не прав.
Но пока что не могу изменить своего мнения насчет практического использования указателей как массивов, о чем писал в предыдущем комментарии. Так что по-прежнему нахожу противопоставление указателя и "указателя на массив" запутывающим.
И вас не смущает, что двумерный массив в таком случае будет распадаться в "указатель на массив", а трехмерный массив — в "указатель на двумерный"?
Хмм. Резонно.
Тем не менее, array "распадается" в обычный указатель
int *— и таким указателем можно пользоваться так же, как самим массивом, без разыменования.Двумерный массив распадется в указатель
int (*a)[2]— и таким указателем, опять же, можно пользоваться как самим массивом.У меня не такой уж большой опыт программирования, но я еще никогда не видел, чтобы чей-то код ожидал одномерный массив по указателю типа
int (*a)[2]; все массивы везде передаются как параint *и размер.Соответственно моя основная претензия все-таки к называнию
int (*a)[2]"указателем на массив" (хотя пример в вашем комментарии логичен); поскольку это противоречит сложившейся практике и только сильнее запутывает.К тому же непонятно как тогда называть
int (*a)[2][2]?Лучше поздно, чем никогда :) Осмелюсь вам возразить:
Интересно, почему же "указатель на массив" не может указывать на массив?
Окей, проигнорируем варнинг, попробуем обратиться по "указателю на массив":
Почему же? Потому что
int (*a)[2]— это не "указатель на массив", а указатель на двумерный массив, у которого вторая размерность равна 2. Поэтому по такому указателю можно будет обратиться через двойные квадратные скобки и компилятор проведет вычисление смещения до элемента, так же, как сделал бы это для обычного двумерного массива.А
int (*a)[2][3]был бы указателем на трехмерный массив соответствующих размерностей.Но никак не просто "указателем на массив"!
Безусловно, int * a — это просто указатель. Но он может указывать и на массив (на первый элемент массива), именно поэтому к указателю можно применять оператор квадратные скобки. Как будто это одномерный массив.
Соответственно "неформально" говорят "указатель на массив" всего лишь имея в виду, что это указатель на одномерный массив.
Разумеется,
int *может указывать и не на массив вовсе, а на отдельную переменную, но это на уровне языка неразличимо. Соответственно фраза "указатель на массив" дополнительно подчеркивает, что по указателю лежит именно массив.Насколько я вижу, существует RFC, оно даже принято.
Мне было скорее интересно, есть ли у вас какая-то любимая "медитативная" активность, не связанная с потреблением информации. Т.е. есть ли у вас время, чтобы побыть "наедине с собой".
А друзья у вас тоже не занимаются спортом?
Скажите, пожалуйста, а вы вообще чем-нибудь помимо программирования занимаетесь? Какие формы отдыха предпочитаете?
Ну, почему исключения оказались быстрее.
В целом, ваши доводы звучат логично и я не чувствую себя достаточно квалифицированным, чтобы их оспаривать.
Тем не менее, вполне возможно что просто бенчмаркинг был проведен плохо, а мы тут пытаемся артефакты измерений как-то объяснить рационально. На мой взгляд, данных в статье просто мало.
Жаль, что это перевод. Так что вся надежда на кого-то еще.
Спасибо!
Intel я, конечно, верю, хотя тут сказано конкретно о предсказании, когда этот переход выполняется впервые (если я правильно понимаю — do not have a history подразумевает это).
Соответственно, неясно, как это повлияет на код из поста. Переходов назад при обработке ошибок в любом случае быть не должно (вроде как?), т.е. тогда влияет порядок обработки условий в if'e.
Но влиять-то он должен все равно только в самый первый раз когда совершается этот конкретный переход, а дальше все будет зависеть от того, насколько предсказуемые входные данные в тесте.
Если в них ошибки чаще не происходят, то и предсказываться будет соответствующая ветка. Иначе какой смысл в динамическом предсказании вообще?
Честно говоря, у меня основные вопрос все же к посту — нет толком ни кода бенчмарка, ни попытки вникнуть в ассемблер, чтобы понять, почему же так выходит.
Спасибо!
А где вы сейчас преподаете, если не секрет?
В идеале — конечно. Но моя реальность уже такова, что эти люди пришли, и будут приходить каждый год — и с ними надо что-то делать. Отчислить при этом кого-то практически нереально (такова политика ВУЗа).
Я пока что пришел к мысли, что нужно стараться вовлечь в процесс как можно больше людей, но на тех, кто никак не вовлекается — просто не тратить слишком много сил и нервов.
Плюс нельзя забывать, что даже те, кто поступил осознанно, может быть не очень мотивирован или нуждаться в некотором давлении обстоятельств, чтобы шевелиться.
Повторюсь — это вы предполагаете или точно знаете?
Я лично достаточно приблизительно в курсе, как работают предсказатели переходов, но предполагаю, что современные реализации довольно сложны. Поэтому не рискну вот так, без реальных замеров на конкретном процессоре, утверждать, что будет быстрее, а что медленнее.
Не знаю, как у вас, но по моим наблюдениям около 40% группы идут в ВУЗ не потому, что хотят получить эту специальность, а потому что родители заставили, от армии косят или "все пошли — и я пошел". С чего бы им изначально быть мотивированными?
Часть из них можно замотивировать уже в процессе обучения, при некотором напряжении (и везении), конечно.
Haskell, Scala?
Гитом как таковым нужно уметь пользоваться 100%, на этом сейчас почти все пайплайны завязаны, соответственно разработчику с этим придется взаимодействовать.
Это-то понятно. Но я все-таки не хочу слишком сильно усложнять студентам (и себе) жизнь. Про гит и клиенты к нему я рассказываю, кто хочет (читай — у кого глаза горят) — поставит и будет пользоваться, а кому лишь бы сдать и забыть, тем и через браузер норм, у них и без этого с предметом проблем достаточно -_-
Но это чисто мое мнение, конечно.
Это вы предполагаете или точно знаете?
Это довод.
Лично я от студентов вообще не требую пользоваться каким-то клиентом git'a и в результате получаю 80% коммитов, сделанных через браузер, с названием "Added files via upload" -_-
Относительно небольшое количество студентов все же делает осмысленные коммиты и пользуется при этом каким-то клиентом. Но можно ли (и стоит ли) заставлять всех? Вот не знаю даже.
Я работаю в отделе, где почти все массово переходили с TortoiseSVN на TortoiseGit… и на мой взгляд корреляция с пониманием была, скорее с общим уровнем разработчика.
Или, можно сказать, кто хотел — разобрался. То, что три человека сидели на SourceTree, им вроде как не помогло.
Лично мне TortoiseGit нравится в основном понятным логом (не, можно конечно написать
git log --branches=* --graph --oneline --decorate --all --pretty=format:'%C(yellow)%h %ad (%ar) [%an]%n%s%C(auto)%d%n', но до этого еще дойти нужно), который, как справедливо отмечают выше, интерактивный.Ну и интеграция в проводник, по мне так тоже огромный плюс — если пользоваться проводником. Можно "окинуть взглядом" рабочую копию, не вводя никаких команд и не кликая, узнать, поменялось ли что-нибудь или нет.
Конечно, если пользоваться другой оболочкой, то постоянно в проводник переключаться только ради git'a не удобно.