Еще вариант, что связываются по-своему, и мы, в принципе, способны это распознать, но игнорим по каким-то причинам.
Допустим, культурным. Мы лишь недавно придумали себе развлекуху — научный метод — а уже возвели в его абсолют, и всерьез полагаем, что теперь-то точно способны все понять и объяснить. Ну если не все, то уж наверняка больше половины. Ну, как минимум уже столько, что этого будет достаточно, чтобы судить по себе о других цивилизациях — что может быть и чего не может.
В научном методе камнем преткновения является воспроизводимость эксперимента. В случае контактов с нашими гипотетическими соседями мы вряд-ли можем активно влиять на ход событий на протяжении достаточно длительного времени, поэтому любые попытки описать редкие феномены с этой точки зрения будут расцениваться как ненаучные. Например, если кто-то в прошлом из наших гипотетических соседей, решил проявить себя, запустив несколько камней в Луну, в результате чего на ней получился набор кратеров, в виде известной «физиономии», то очевидцами такое сообщение могло быть считано однозначно как факт контакта. Но ученные будущих поколений будут отвергать такую версию, как ненаучную, т.к. она не воспроизводима. Скорее, согласившись на удивительный рандом (хотя это тоже не воспроизвести).
Текущий технический уровень развития нашей цивилизации (как звучит!) это сколько по времени — 100 лет, 1000, 10000? Цифры даже в масштабах Земной геологии лишь миг от пшика, не говоря уже о Вселенной.
фоточный хлам часто состоит из фоток, собранных из разных источников. с большой вероятностью в них найдутся файлы с «обобщенными» названиями (image.jpg, photo1.jpg и т.п.). как эта штука разруливает случаи, когда имена файлов не уникальны?
допустим, у меня есть несколько коллекций с фотографиями Кёльна, в которых встречаются файлы с одинаковыми названиями.
Только «подавать» вы будете не «бизнесу», а конкретному «манагеру» и не факт, что он мотивируется стратегическими бизнесовыми потребностями. И с позиции разработчика эти потребности скорее всего тоже не видны (зачастую они конфликтуют с потребностями разработки). Рационализм всей этой истории: нужно учиться аргументированнно обозначать проблему.
Под классом колес мы понимаем множество объектов. Не то, что понимается под этим термином в ООП (описание типа, модель объектов, описание общих признаков), нет. Мы понимаем просто набор каких-то объектов.
В теории множеств классом называют обобщение над множествами, а являются-ли все классы множествами это еще тот вопрос. Утвердительный ответ приводит к парадоксам, поэтому в некоторых формальных системах они не эквивалентны. Без конкретизации теории, последующие логические выкладки выглядят умопомрачительно, прямо как «Алиса в стране чудес».
Если мне удалось уловить смысл статьи, то для программирования можно было рассмотреть более привычную ситуацию — проектирование реляционной базы данных — на примере таблиц автомобилей (Auto), колес (Wheels) и их атрибутов.
Отличная статья, чисто в теоретическом смысле — уже по объему «введения» дает понять, что это не так просто, как кажется. :)
В примере с горизонтальным сдвигом «Слайд-шоу без разбивки на страницы» будут проблемы с производительностью (чем больше слайдов, тем будет больше тормозить). overflow: hidden для «окна» и гигантской «лентой» внутри, float: left — все это ацкий ад. Для того, чтобы обеспечить константную производительность, надо использовать абсолютное позиционирование.
В примере «Навигация с клавиатуры» не поддерживается фокус — если на странице несколько аналогичных слайдеров, будут перелистываться все. Нет отвязки событий от 'body' для корректного удаления слайдера.
В крайнем примере «JavaScript: использование внешнего API» при клике в слайд запускается видео не на текущем слайде, а на последнем. В общем случае трюк с «opacity: 0» не работает.
Это лишь часть того, что видно сходу. Статья может быть полезна для начинающих «потренировацца», но не как инструкция для сборки промышленного решения по шагам. На практике слайдеры собирают совсем не так.
Похоже, что отправлять жалобы в Google со списками урлов, собранными по ключевым словам, становится популярной практикой. Недавно несколько проектов на GitHub получали уведомления за созвучность с каким-то проном.
Если так дело и дальше будет так развиваться, то использование ЧПУ скоро станет антипаттерном в SEO'шных практиках.
Определено-ли «c» при объявлении во второй строчке? Да ( &*E is equivalent to E (even if E is a null pointer)).
Будет-ли в третьей строке UB при попытке разыменовать *c? Да (по правилу на которое вы ссылаетесь).
В примере «struct usb_line6 *line6 = &podhd->line6;» вычисляется указатель на line6, т.е. смещение line6 относительно podhd. Смещения не зависят от значений, только от типов. Тут нет разыменовавания, и пункт на который вы ссылаетесь не подходит. Поэтому я о нем не говорил (а не вырвал из контекста, как вы выразились).
Я мог бы с вами согласиться на 100%, если бы все четыре основных компилятора не были бы C/C++.
Вы на 100% не сможете скомпилировать программу на «C/С++»: это будет программа либо на «С», либо на «С++».
Я ни в коем случае не лезу в язык C++ — у него свой стандарт, гораздо более сложный и объемный.
Поэтому я тоже говорю про С. В стандартах «С» нет понятий ни виртуального наследования, ни перегрузки операторов. Это ведь не значит, что они, а так же все, что сними может быть связано, автоматически становятся UB? — это значит, что С совсем другой язык, это не С++.
Для С вопрос разъясняется в:
102) Thus, &*E is equivalent to E (even if E is a null pointer), and &(E1[E2]) to ((E1)+(E2)). It is always true that if E is a function designator or an lvalue that is a valid operand of the unary & operator, *&E is a function designator or an lvalue equal to E. If *P is an lvalue and T is the name of an object pointer type, *(T)P is an lvalue that has a type compatible with that to which T points.
Отсюда напрямую следует вывод, что если компилятор С вздумает разыменовывать указатели при интерпретации выражения, то свойство эквивалентности будет нарушено (как раз для случая null pointer, который тут особо отмечен, ибо в процессе он словит UB). Поэтому так делать нельзя. Поэтому нормальный компилятор С так делать не будет и с точки зрения программиста на С тут нет UB.
Мне кажется, что рационализм в проблеме, поднятой Andrey2008 есть. Делать прямые указатели на чужие внутренности может быть чревато по многим причинам. Поэтом интерес к вопросу, как разработчика статического анализатора, понятен. Просто вопрос этот скорее из области best practices программирования, а не спецификаций С.
Таким образом здесь мы соглашаемся, что podhd!=nullptr
Возражаю! :) В общем случае такая эвристика не уместна, у Andrey2008 про это было:
А есть ли какая-та ситуация, когда при P == nullptr мы напишем &P->m_foo и всё будет хорошо? Да, например это может быть аргументом оператора sizeof: sizeof(&P->m_foo).
Тут нельзя делать заключение о значении указателя на основе лишь синтаксиса, поскольку нет разыменовывания — интерпретация выражения не выходит за рамки арифметики указателей.
Обычное объявление указателя, значение указателя не определено. Возникает-ли здесь UB и надо-ли бить тревогу? Думаю, что нет. С точки зрения поведения компилятора/стандартов ситуация решается однозначно. С точки зрения поведения программы — зависит о того, как этот указатель будет использоваться дальше (чтобы вынести вердикт, нужно анализировать остальной код).
Возьмем другой пример:
int foo(int a)
{
int b = a + 100500;
Обычное сложение. Возникает-ли здесь UB, и нужно-ли бить тревогу? С точки зрения стандарта/компилятора все однозначно — какое-то значение у входного параметра будет. С точки зрения программы — зависит от значения на входе. Если прилетит значение в районе INT_MAX, будет переполнение. Является-ли такой код проблемным? Чтобы вынести вердикт нужно анализировать остальной код. Возможно тут есть место для логической ошибки, и стоит добавить проверку на граничные значения входного параметра. В общем, это нормальная программисткая ситуация, когда нужно определяться с логикой проверки входных данных, а не UB.
Если-по простому, здесь записано выражение «к podhd прибавить смещение line6 в структуре usb_interface». Т.е. не смотря на количество закорючек, тут записана такая же простая арифметика, как во втором примере. Только это арифметика с указателями. Ни какого разыменовыания здесь нет (тут уже неоднократно про это писали, в т.ч. вы сами цитатой эксперта). Можно-ли говорить тогда про UB? С точки зрения стандартов/компилятора выражение интерпретируется однозначно, поэтому UB нет. С точки зрения логики программы — зависит от значения указателя, которое прилетит на вход функции. Может прилететь правда адрес структуры, может NULL, а может какой-то бред (если передадут неинициализированный указатель, как в первом примере). Но в «С» не запрещается хранить в указателях «непонятно что» (см. первый пример). Тут может иметь место логическая ошибка (случай когда нужна проверка входных параметров функции), но само по себе это не UB.
Допустим, культурным. Мы лишь недавно придумали себе развлекуху — научный метод — а уже возвели в его абсолют, и всерьез полагаем, что теперь-то точно способны все понять и объяснить. Ну если не все, то уж наверняка больше половины. Ну, как минимум уже столько, что этого будет достаточно, чтобы судить по себе о других цивилизациях — что может быть и чего не может.
В научном методе камнем преткновения является воспроизводимость эксперимента. В случае контактов с нашими гипотетическими соседями мы вряд-ли можем активно влиять на ход событий на протяжении достаточно длительного времени, поэтому любые попытки описать редкие феномены с этой точки зрения будут расцениваться как ненаучные. Например, если кто-то в прошлом из наших гипотетических соседей, решил проявить себя, запустив несколько камней в Луну, в результате чего на ней получился набор кратеров, в виде известной «физиономии», то очевидцами такое сообщение могло быть считано однозначно как факт контакта. Но ученные будущих поколений будут отвергать такую версию, как ненаучную, т.к. она не воспроизводима. Скорее, согласившись на удивительный рандом (хотя это тоже не воспроизвести).
Текущий технический уровень развития нашей цивилизации (как звучит!) это сколько по времени — 100 лет, 1000, 10000? Цифры даже в масштабах Земной геологии лишь миг от пшика, не говоря уже о Вселенной.
допустим, у меня есть несколько коллекций с фотографиями Кёльна, в которых встречаются файлы с одинаковыми названиями.
технически, фотки photo1.jpg в разных директориях разные (на одной запечатлён закат, на другой — рассвет). мне интересно, что будет в этом листинге?
какую из двух фотографий откроет такая команда?
В теории множеств классом называют обобщение над множествами, а являются-ли все классы множествами это еще тот вопрос. Утвердительный ответ приводит к парадоксам, поэтому в некоторых формальных системах они не эквивалентны. Без конкретизации теории, последующие логические выкладки выглядят умопомрачительно, прямо как «Алиса в стране чудес».
Если мне удалось уловить смысл статьи, то для программирования можно было рассмотреть более привычную ситуацию — проектирование реляционной базы данных — на примере таблиц автомобилей (Auto), колес (Wheels) и их атрибутов.
«машина состоит из множества колес»
«машина состоит из колес одного множества»
Не уверен в правильности трактовки, ибо СПГС.
В примере с горизонтальным сдвигом «Слайд-шоу без разбивки на страницы» будут проблемы с производительностью (чем больше слайдов, тем будет больше тормозить). overflow: hidden для «окна» и гигантской «лентой» внутри, float: left — все это ацкий ад. Для того, чтобы обеспечить константную производительность, надо использовать абсолютное позиционирование.
В примере «Навигация с клавиатуры» не поддерживается фокус — если на странице несколько аналогичных слайдеров, будут перелистываться все. Нет отвязки событий от 'body' для корректного удаления слайдера.
В крайнем примере «JavaScript: использование внешнего API» при клике в слайд запускается видео не на текущем слайде, а на последнем. В общем случае трюк с «opacity: 0» не работает.
Это лишь часть того, что видно сходу. Статья может быть полезна для начинающих «потренировацца», но не как инструкция для сборки промышленного решения по шагам. На практике слайдеры собирают совсем не так.
Если так дело и дальше будет так развиваться, то использование ЧПУ скоро станет антипаттерном в SEO'шных практиках.
Определено-ли «c» при объявлении во второй строчке? Да ( &*E is equivalent to E (even if E is a null pointer)).
Будет-ли в третьей строке UB при попытке разыменовать *c? Да (по правилу на которое вы ссылаетесь).
В примере «struct usb_line6 *line6 = &podhd->line6;» вычисляется указатель на line6, т.е. смещение line6 относительно podhd. Смещения не зависят от значений, только от типов. Тут нет разыменовавания, и пункт на который вы ссылаетесь не подходит. Поэтому я о нем не говорил (а не вырвал из контекста, как вы выразились).
Вы на 100% не сможете скомпилировать программу на «C/С++»: это будет программа либо на «С», либо на «С++».
Это неизбежно, когда ненароком ставят рядом два довольно-таки разных языка (более эпичный вариант лишь Java/JavaScript). ;)
Но эту ветку комментов конкретизировал dimoclus:
Поэтому я тоже говорю про С. В стандартах «С» нет понятий ни виртуального наследования, ни перегрузки операторов. Это ведь не значит, что они, а так же все, что сними может быть связано, автоматически становятся UB? — это значит, что С совсем другой язык, это не С++.
Для С вопрос разъясняется в:
Отсюда напрямую следует вывод, что если компилятор С вздумает разыменовывать указатели при интерпретации выражения, то свойство эквивалентности будет нарушено (как раз для случая null pointer, который тут особо отмечен, ибо в процессе он словит UB). Поэтому так делать нельзя. Поэтому нормальный компилятор С так делать не будет и с точки зрения программиста на С тут нет UB.
Мне кажется, что рационализм в проблеме, поднятой Andrey2008 есть. Делать прямые указатели на чужие внутренности может быть чревато по многим причинам. Поэтом интерес к вопросу, как разработчика статического анализатора, понятен. Просто вопрос этот скорее из области best practices программирования, а не спецификаций С.
Возражаю! :) В общем случае такая эвристика не уместна, у Andrey2008 про это было:
Тут нельзя делать заключение о значении указателя на основе лишь синтаксиса, поскольку нет разыменовывания — интерпретация выражения не выходит за рамки арифметики указателей.
В топике не *x, а &*x, и как написали выше нет разыменовывания, а лишь простая арифметика с указателями:
Обычное объявление указателя, значение указателя не определено. Возникает-ли здесь UB и надо-ли бить тревогу? Думаю, что нет. С точки зрения поведения компилятора/стандартов ситуация решается однозначно. С точки зрения поведения программы — зависит о того, как этот указатель будет использоваться дальше (чтобы вынести вердикт, нужно анализировать остальной код).
Возьмем другой пример:
Обычное сложение. Возникает-ли здесь UB, и нужно-ли бить тревогу? С точки зрения стандарта/компилятора все однозначно — какое-то значение у входного параметра будет. С точки зрения программы — зависит от значения на входе. Если прилетит значение в районе INT_MAX, будет переполнение. Является-ли такой код проблемным? Чтобы вынести вердикт нужно анализировать остальной код. Возможно тут есть место для логической ошибки, и стоит добавить проверку на граничные значения входного параметра. В общем, это нормальная программисткая ситуация, когда нужно определяться с логикой проверки входных данных, а не UB.
Теперь смотрим пример из топика:
Если-по простому, здесь записано выражение «к podhd прибавить смещение line6 в структуре usb_interface». Т.е. не смотря на количество закорючек, тут записана такая же простая арифметика, как во втором примере. Только это арифметика с указателями. Ни какого разыменовыания здесь нет (тут уже неоднократно про это писали, в т.ч. вы сами цитатой эксперта). Можно-ли говорить тогда про UB? С точки зрения стандартов/компилятора выражение интерпретируется однозначно, поэтому UB нет. С точки зрения логики программы — зависит от значения указателя, которое прилетит на вход функции. Может прилететь правда адрес структуры, может NULL, а может какой-то бред (если передадут неинициализированный указатель, как в первом примере). Но в «С» не запрещается хранить в указателях «непонятно что» (см. первый пример). Тут может иметь место логическая ошибка (случай когда нужна проверка входных параметров функции), но само по себе это не UB.