LLVM 10.0

Вообще арифметика указателей это отдельная история, т.к. не везде плоское адресное пространство. Например в процессоре 8086 (и real mode x86) там адрес это 32 бита, 16 бит на сегмент и 16 на смещение. Но там вообще ад, там если у тебя массив начинается по адресу XXX0:0000, то после увеличения адреса на 65536 байт ты окажешься в XXX1:0000, что на самом деле на 16 байт отстоит от начала массива

Это разве не проблема бекэнда который генерирует код под эту платформу? p[i] - это *(p + i), так какая компилятору может быть разница чтобы ты напишешь p[i] или p + i, он в обоих случаях может сгенерировать одинаковый код. Или не может?

не везде плоское

такое убожество не нужно даже в микроконтроллерах, если можно воткнуть нормальный арм

pi[i] ≡ *(pi+i)

Аха, аха...

 ≡ *(i+pi) ≡ i[pi]

И в этом вся ваша сишечка

так никто не пишет кроме хейтеров С

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

Дело не в «пишет» или «не пишет». Дело в том, что компилятор вынужден такое читать и код генерить, ибо стандардъ.

Забавный? Да уж не забавней чем ваша сишечка.

напиши в шланг письмо, пусть они скажут, что это уб. тебе же сказали, что a + b = b + a. у тебя это вызывает моральные страдания? ну извини, пора изобретать современную математику которая отвечает современным вызовам, а не это старьё 3 века до нашей эры.

Сижу на жопе ровно и жду модули.

Тридцать лет в ожиданьи прошло, ты в пути, ты всё ближе ко мне…

Дело в том, что компилятор вынужден такое читать и код генерить

компиляторы С есть для любого процессора, а вот код Rust да - вынужден, в нем только завсегдатаи дурки разбираются.

Напомни пожалуйста, а что по стандарту в случае

По стандарту C — implementation-defined.

Если вспоминать какие-то implementations, то в спеке GCC написано что defined является только результат конвертации из указателя в целое число и обратно, без изменения значения целого числа. В остальных случаях (в частности, если число не получено кастом из указателя, а взято с потолка) поведение в GCC не определено.

Не моя. В этом отсутствие в C системы типов.

шланг в последнее время становится все менее адекватным

Шлангу пока есть куда становиться неадекватнее. В отличие от тебя.

Зато Си и Си++ никогда не умрут и через 20 и через 30 лет, а Раст?

Дооо, как-будто за растом будущее, загнётся мозилла, загнётся и раст (на что я очень надеюсь, говноязычков расплодилось и их пропагандистов, должно быть меньше всего этого дерьма).

ахаха, это точно. ну удачи шлангу, в его нелёгком деле потери адекватности.

Как же мне, блин, печёт с сишных фашистов. Думают, что язык прямиком из 70-х с синтаксисом провоцирующим ошибки это верх совершенства и дескать нет нужды в альтернативах. По вбывав бы! Вы, гордецы, хоть понимаете, что глючность десктопного линукса это прямое следствие выбранного инструмента/языка его разработчиками?! Вы хоть знаете, что в ПО не прощающем ошибки используется сильно урезанное подмножество сишки и 70% правил MISRA C не актуальны для детища Никлауса Вирта - Oberon-07/2016? Ваша гордыня ответственна за непрекращающиеся поток уязвимостей - я ведь не быдлокодер, я ведь не криворукий, зачем мне страховка со стороны языка - это для виртовских лохов, а я не лох, я настоящий программист, а настоящий программист, как всем известно использует Си.

на подержи, чтобы ещё сильнее поприпекало: http://way-cooler.org/blog/2020/01/09/way-cooler-post-mortem.html

ты же умеешь читать на английском?

По стандарту C — implementation-defined. поведение в GCC не определено

всегда поразительно наблюдать как defined медленно, постепенно, с растеканием мысли по древу, трансформируется в undefined. по-моему у тебя какая-то форма окр.

На, приложи чтоб полегчало: http://esr.ibiblio.org/?p=7711

TL;DR: C уже на свалке истории, у нас есть Go и в перспективе Rust. Пишет Ъ-юникс-хакер, если буквы ESR ни о чем не говорят.

Как же мне, блин, печёт с сишных фашистов

Да какой это сишный фашист, мечешь бисер. Пройди по комментам: ничего содержательного, знаний около нуля, зато во все темы лезет с «закопать, кресты форева». То ли переходный возраст затянулся, то ли просто троллинг тупостью.

C/C++ - стабильность, надёжность, качество. Выберите 0.

разделяю эту точку зрения, но предпочитаю не озвучивать её из уважения к Ричи и Страуструпу.. эти языки - это произведения искусства.

тем не менее, антиквариату - место в музее или не дальше школьной лаборатории

жаль, что разработчик way cooler его не читал, может ему полегчало бы. слова поддержки - это всегда приятно и полезно. он там ещё на реддите потом написал некоторые неприятные вещи. выглядело это всё так как будто он покидает секту, с чем я его и поздравляю. любая секта - это зло.

way cooler обсуждали: Автор Wayland композитора Way Cooler переписывает своё детище с Rust на C

любая секта - это зло

Плюсую, но хочу отметить: очень часто тот, кто начинает бороться с какой-то сектой, незаметно сам вступает в противоположную секту.

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

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

Зато Си и Си++ никогда не умрут и через 20 и через 30 лет

На COBOL тоже кое-что продолжают поддерживать.

Т.е. C++ не исчезнет, конечно же, но вот его актуальность может снизиться в десятки раз.

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

вот интересно кстати послушать мнения про скриптование на го, для десктопа

///usr/bin/env go run "$0" "$@"; exit

package main

import "fmt"

func main() {
  fmt.Println("Hello world!")
}

chmod +x hello.go
./hello.go

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

компилятор проверит весь код перед выполнением, не будет так, что скрипт выполнится наполовину, а дальше там где-то опечатка, или в 99% случаев работает, но в 1% не тот тип пихнули. нормальные языковые конструкции, хорошая стандартная библиотека. мне норм. особенно после того как на питухоне написать что-то нетривиальное стало сложнее чем на с++.

с растеканием мысли по древу Чего, простите, по древу?

спасибо. Надо будет подумать.

С большей частью твоего ответа я не согласен, кроме этой

зачем мне страховка со стороны языка - это для виртовских лохов, а я не лох, я настоящий программист, а настоящий программист, как всем известно использует Си.

Тут я согласен, все серьезное только Си!

Тебе сколько мозилла платит?

А сколько тебе Дед Керниган платит со своей пенсии, чтобы ты тут свое поделие недогеймдевное на C пиарил, а?

Разорванный Флакон

А бэкдоры в LLVM есть?

А как ещё к первому элементу обратиться? конечно 0, не 25 же, как в школоПаскале

Пишут по разному, кому как удобнее, но пример выше реально высосан из пальца - просто один из банальных методов обфускации. Практического смысла нет.

Самому сейчас приходится допиливать проект на билдер-6, вижу - писали разные люди, частично парсинг текста идёт через массивы (в смысле «[]»), частично через указки - но подобных извратов не видел…

компилятор проверит весь код перед выполнением, не будет так, что скрипт выполнится наполовину, а дальше там где-то опечатка, или в 99% случаев работает, но в 1% не тот тип пихнули. нормальные языковые конструкции, хорошая стандартная библиотека. мне норм. особенно после того как на питухоне написать что-то нетривиальное стало сложнее чем на с++.

ты в скриптухе пишешь что-то нетривиальное? ну-ка покажь, что там за сценарии такие, где питона не хватает

Чтобы обратиться к первому элементу, нужно знать его номер. Дальше - проще: второй элемент будет иметь номер на единицу больше. И так - до конца массива элементов. В Паскале «номер элемента» - необязательно целое число - может быть литерный элемент из перечислимого множества, например, «a», «b», «c»,…,«Z».

Питона не хватает даже по нормальному сходить в БД за данными, о чём речь?

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

Это был риторический вопрос. В том, что ты покажешь стэктрейс на serialization failure и «any error» на любой constraint failure, у меня сомнений не вызывает

Итого ты влез туда, куда тебя никто не звал, с х*йней, о которой речи и не шло. И куда мне тебя послать, догадаешься? (Это тоже риторический вопрос.)

Знатно ты порвался. А так, с надеждой на твоё выздоровление - об обработке ошибок речь идёт всегда, кроме херни, которую пишут те, кому «питона хватает»

отсчёт с нуля - классика, остальное чистый синтакс-сахар. Ненужный сахар. ИМХО.

Зачем вообще 0, и прочие числа?

Есть всякие begin, end в С++ или low, high в паскале

for i := low(a) to high(a) do begin
    do_work(a[i]);
end;

и вообще плевать на индексы…

на слаке current у меня не собирается mesa с десятым llvm.

это был oom-killer. странно что памяти не хватает, с предыдущей версией хватало

Посмотри не включен ли LTO. С LTO lld в легкую выжирает 45 ГиБ оперативки в 16 потоков.

:)

да вроде нет. если тока новый llvm его сам не включает...

Ты у меня в игноре и, видимо, не зря, раз задаёшь такие элементарные вопросы:

Почему UB?

Начни просвещаться с https://stackoverflow.com/q/6015080/857932, например.