Существует ли язык высокого уровня, который устойчиво быстрее C?

А может уже существуют такие языки,

pascal

просто из-за популярности C на них мало кто пишет,

немало

поскольку всплывают проблемы совместимости с существующей базой уже готового кода?

не всплывают

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

Какой говнистый царек то.

Ну и зачем ты мне попытался что-то кукарекать, если обосрался на первом же высере? Я в тебе, похоже, не ошибся. Бывает.

pascal

Куллстори. Убого дерьмо, которое из помойки никогда не вылезало. Без делфятского мусора это дерьмо вообще не юзабельно.

немало

На помойке да, в мире хоть чутка выше помойки - никто.

Собственно и все остальные классические языки живы и здравствуют.

На помойке.

Они не привязаны к технологиям и переживут весь быстро рождающийся

Паскаль сдох ещё не родившись. А так да, твой выйсер крайне точно соответствует действительно.

Убого дерьмо
это дерьмо
На помойке
выше помойки
На помойке.
твой выйсер

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

Ты промахнулся, я ТС писал.
Извини, что помешал тебе в перепалке с самим с собой. Не отвлекайся.

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

Ну дак вперёд - что тебе мешает помножить на ноль мартышку. К дерьму дерьмо не липнет, да и кидать дерьмом в дерьмо смысла не имеем. Вперёд. Разоблачи мартышку.

Дак зачем ты пишешь? В надежде на то, что тс нулёвая ламерюга и не сможет указать тебе - где место твоему высеру?

Тыб хоть попытался ответить, так, чисто ради приличия, что типа не совсем конченный балабол. Там показать мне паскалик живой - так чисто поржать. И остальные куллязык, которые ты не назвал, но 100% они где-то есть за пределами помойки.

И ты 100% не боишься мне ответить.

А вот, уважаемые посетители нашего зоопарка, посмотрите, мартышка взобралась на веточку и кидает свои фекали в зрителей. Но не стоит уходить! Веточку мартышки и зрителя отделяет отличное стекло. Мартышка думает, что кого-то забросала дерьмом или даже обоссала, а на самом деле ей только со стороны так кажется, уважаемые зрители. Для мартышки очень важно метнуть в кого-то дерьмом, это повышает ее статус.

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

Ад с указателями.

Ад с указателями.

А что с ними не так? Никогда не мог понять тех, кто их не может осилить.

Не так с ним то, что ими как правило эмулируют ссылки. А осилить их в этом случае не может не кто иной как оптимизатор.

Не так с ним то, что ими как правило эмулируют ссылки. А осилить их в этом случае не может не кто иной как оптимизатор.

Именно так, но даже с эмуляцией ссылок всё получается плохо

void findSum(int a[], int n, int *sum) {
    *sum = 0;
    for (int i = 0; i < n; ++i)
        *sum += a[i];
    // А вдруг sum указывает в середину a?
    // Оптимизатор теперь должен забыть о векторизации и каждый раз делать запись в память.
}

А правило про strict aliasing — ни что иное, как попытка навелосипедить это требование для частых сценариев использования.

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

Указатели сложнее - у них есть адресная арифметика.

К тому же для ссылок можно использовать информацию о типах. Для указателей тоже можно с учетом strict aliasing rule, но реально эту возможность нечасто используют - на грабли нарваться очень легко, и любимая многими эмуляция наследования оказывается вне закона (хотя в gcc есть may_alias).

static и/или inline в помощь, ламерок. Ну и писать код, а не дерьмо научись, а потом уже неси херню. Да что там говорить, даже пример вменяемый высрать не могут - совсем нулёвые в дрова.

// Оптимизатор теперь должен забыть о векторизации и каждый раз делать запись в память.

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

Требование наличия restrict для всех указателей — и возможностей для оптимизации получается на порядок больше.

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

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

А правило про strict aliasing — ни что иное, как попытка навелосипедить это требование для частых сценариев использования.

Ога и уже жопа болит у всех. Это попытка навелосипедить это там, где это имеет хоть какой-то смысл и обоснование.

В целом нулёвая жабкаобезьяна опять срывает покровы в моих тредах.

Ад с указателями.

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

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

Указатели сложнее - у них есть адресная арифметика.

Это и без адресной арифметики неразрешимая задача если этот код не встраивается в место вызова.

К тому же для ссылок можно использовать информацию о типах

Ну в случае того же ООП нельзя. Даже если у тебя не пересекаются, скажем, интерфейсы в иерархии, то не факт, что у тебя в рантайме не будет объектов, которые будут реализовывать оба интерфейса.

ссылку на тесты

неразрешимая задача если этот код не встраивается в место вызова

Так для ссылок то же самое.

не факт, что у тебя в рантайме не будет объектов, которые будут реализовывать оба интерфейса

Не понял. Если типизация статичная, то всё про интерфейсы заранее известно.

Даже C++ справляется со strict aliasing при наличии наследования.

ССылки не будет - я уже спрашивал, ничего кроме гереспов балаболка высрать так и не смогла. А про регеспы я уже писал и выкатывал руками сконпелированые регеспы в 10-50раз быстрее.

Так для ссылок то же самое.

Именно. Так что это проблема не связана с указателями, она и про ссылки тоже.

Не понял. Если типизация статичная, то всё про интерфейсы заранее известно.

У нас есть ссылка на полиморфный объект класса/интерфейса A и на полиморфный объект класса/интерфейса B. Расскажи, как ты будешь при компиляции что-то там определять.

Даже C++ справляется со strict aliasing при наличии наследования.

Это уже интереснее. А как справляется? Можно ссылку?

Так ли необходимо это хождение по минному полю для того, чтобы писать быстрый код?

Так я же уже написал. Ада.

Как твои слова соотносятся вот с этим? Существует ли язык высокого уровня, который устойчиво быстрее C? (комментарий)

С теоретической, ИМХО, лучше читать свежие статьи о Rust и ходить по ссылкам из их списка литературы.

Это я мог бы сделать и без форума. Меня интересует мнение тех, кто в теме. Статью про Cyclone местами прочитал. По-моему, в Расте реализовано ровно тоже. Но там есть ссылки на другие попытки сделать C безопасным - их ещё не смотрел.

Как твои слова соотносятся вот с этим? Существует ли язык высокого уровня, который устойчиво быстрее C? (комментарий)

Там же написано: Dynamic memory allocation should be avoided

И, в отличие от Си, там это в большей части случаев реализуемо.

И, в отличие от Си, там это в большей части случаев реализуемо.

За счёт чего? Я не увидел в управлении памятью там чего-то, чего нет в С. Либо стек, либо куча.

Как твои слова соотносятся вот с этим? Существует ли язык высокого уровня, который устойчиво быстрее C? (комментарий)

Кстати, про Java там фигня написана. В Java также течёт память (если создавать много новых динамических объектов) и также возможна «Corruption of data due to multiple pointers to the same areas. Such corruption can be difficult or impossible to correct or even detect.», так как ссылки на объекты вполне копируются.

И в Java выполнить предложение «Dynamic memory allocation should be avoided» практически нереально.

За счёт чего?

Строка и массив — это строка и массив, а не хрень под указателем.

Для создания динамического массива не нужно делать malloc:

procedure Process_Array (arraySize : Integer) is

    theArray : myArray(0..arraySize);

begin
   for I in arraySize'Range Loop
      theArray(I) := 1.2 * I;
   end Loop;
end;

С теоретической, ИМХО, лучше читать свежие статьи о Rust и ходить по ссылкам из их списка литературы.

Это я мог бы сделать и без форума.

Всё, что можно узнать на форуме, можно узнать и без форума. Но с форумом быстрее.

Статью про Cyclone местами прочитал. По-моему, в Расте реализовано ровно тоже.

Reference manual по Cyclone читал давно, но не припомню там линейных типов и borrow checker-а.

Reference manual по Cyclone читал давно, но не припомню там линейных типов и borrow checker-а.

Да, я плохо написал. Имелось в виду, что Раст взял всё то же самое и возможно добавил своё. Т.е. Циклон не даёт новых идей к расту.

P.S. причём «ниже следующие» указания по безопасному программированию занимают несколько страниц. Т.е., написать не падающую программу на Аде (во всяком случае, 95-й) не так-то и легко.

Там не про «не падающую», а про «с предсказуемым использованием памяти». Например, пишешь ты программу для контроллера, управляющего авионикой самолёта, а в том контроллере всего мегабайт памяти.

Т.е. Циклон не даёт новых идей к расту.

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

Строка и массив — это строка и массив, а не хрень под указателем.

Это да. Т.е. снижается количество случаев, где динамическое выделение нужно. Но там, где оно нужно, от него всё равно никуда не деться.

И в Java выполнить предложение «Dynamic memory allocation should be avoided» практически нереально.

Это документ конкретно про Аду: http://grouper.ieee.org/groups/plv/HISTORICAL-LINKS/NUREG CR-6463, Rev. 1/LAN...

В Java также течёт память (если создавать много новых динамических объектов)

В точном двигающем сборщике мусора без поколений память не течёт. В реальности сборщики мусора бывают разными. Например, в консервативном спокойно может течь память. Также она может теряться из-за фрагментации или не убираться в поколенческом сборщике, если не делать сборку старших поколений.

и также возможна «Corruption of data due to multiple pointers to the same areas. Such corruption can be difficult or impossible to correct or even detect.»,

Абсолютно несогласен.

Строка и массив — это строка и массив, а не хрень под указателем.

Чё?

Для создания динамического массива не нужно делать malloc:

В сишке есть «динамические массивы» - адепты продолжают срывать покровы.

Где тут «динамический массив»? Я чуть не обосрался, когда эту портянку увидел. Я уж думал, что хуже паскалятинки я ничего не увижу, но нет - это ещё более эпично. Убейте это чудовище.

Это да. Т.е. снижается количество случаев, где динамическое выделение нужно. Но там, где оно нужно, от него всё равно никуда не деться.

Чё?

В точном двигающем сборщике мусора без поколений память не течёт.

Сборщик мусора и в Аде есть (хотя, наверное, не во всех компиляторах).

Память течёт в коде вида

public static MyObject instance(int i1, int i2, int i3, int i4){
         int hashKey = Arrays.hashCode(new int[]{i1, i2,i3,i4});
         //get the object from hashtable
         MyObject myObject = objectInstances.get(hashKey);

         //if object was not already created, create now and put in the hashtable
         if(myObject == null){
           myObject = new MyObject(i1,i2,i3,i4);
           objectInstances.put(hashKey, myObject);
         }
        return myObject;
    }

также возможна «Corruption of data due to multiple pointers to the same areas. Such corruption can be difficult or impossible to correct or even detect.

Абсолютно несогласен.

private static Hashtable<Integer, MyObject> a = new Hashtable<Integer, MyObject>();

....

private static Hashtable<Integer, MyObject> b = a;

....

// работаем с a

....

// начинаем работать с b
b.clear()
...

// здесь a безвозвратно испорчено

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

Второй пример может означать неожиданное изменение данных, но не повреждение. Программа не упадёт при обращении к а.

В Аде можно создать access, скопировать его, потом unchecked_deallocate одного из указателей, а потом доступ к этому же месту по другому указателю, на котором уже могут находиться другие данные другого типа. Это один из классических примеров повреждения данных в куче для С.

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

Хэш таблица приватная и снаружи недоступная. Доступен через попытку создания нового объекта.

Можно ещё мемоизирующий sin написать. Или просто str.intern().

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

потом unchecked_deallocate одного из указателей, а потом доступ к этому же месту по другому указателю

Не делай unchecked. Ну или в Java тоже можно написать unsafe.freeMemory(resource) на один указатель, а потом доступ к этому же месту по другому указателю.

надо для этого тащить целый компилятор в рантайм.
А почему бы и нет?

Common Lisp

Жыыыыырно

человек либо программист, либо не программист

Настоятельно советую ознакомиться с нечеткой логикой, которая описывает реальный мир лучше чем булевая.

Человек, который выбрал инструментом бас-гитару, а языком си, имеет определенное устройство мышления. Уже хорошо, если там есть бинарность.

Говорю как сишник и бывший басист :)

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

Ну конечно, ссылки тоже не всегда анализируются. Но для указателя вдобавок может встретиться ++p, и сиди думай, куда теперь он указывает. Для ссылок так не бывает, а в остальном аналогично.

У нас есть ссылка на полиморфный объект класса/интерфейса A и на полиморфный объект класса/интерфейса B. Расскажи, как ты будешь при компиляции что-то там определять.

Если пришел объект реализующий A и B, значит в нем есть подобъекты типов A и B, и работаем с ними как с независимыми, ничего не испортится, не?

А как справляется? Можно ссылку?

Я про то что в стандарте есть это правило (C++14: 3.10.10), и случай наследования там явно оговорен, и всё (видимо) работает.

Это не лисп.

Почему?

Основа любого адепта и лиспа как такового - иная парадигма, которая противопоставляется императивщине и вообще какой-то близости к отражению реального мира.

Разве лисп когда-то претендовал на функциональную чистоту?

Основа любого адепта и лиспа как такового - иная парадигма, которая противопоставляется императивщине и вообще какой-то близости к отражению реального мира.

Лисп и есть императивщина...

Это что ж получается, любая программа течет?

Почему?

ПОтому, что это жабка/сисклассами мимикрирующая под лисп. Это диалект лиспа, в котором от лиспа ничего нет. Кроме названия.

Разве лисп когда-то претендовал на функциональную чистоту?

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

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

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

Потом, видя любой код на лиспе, который является бесполезным хелвордом на 90%, а не на 100% как типичный лисповысер - оказывается пишется на жабка-лисповых диалектах.

Конечно, адептам в это верить надо - типичная разводка для дебилов. Кукарекаем про «раст быстрее и безопаснее» - пруфцуем безопасность safe, а быстроту unsafe-портянками. Казалось бы - где тут ошибка?

И так со всеми адептами - когда-то я обоссывал хацкель-адепта. Ну дак у пацана жопа настолько порвалась, что он начал мне высирать портянки на гхц-диалекте сишки. Хотя всё равно обосрался. И он реально не понимал, почему сделав это - он насрал себе на голову.

То же самое и с жабкой. Адепт пастит бенчи jni, которое является чистой сишкой и с сишным же кодом, а потом кукарекает про жабку - он дебил? Да.

И так со всем, так везде. Адепт пастит asm-js, не понимая, что asmjs - это представление сишки внутри жабаскрипта, транслируемого из той же самой сишки.

Эти люди дебилы? У тебя есть твоя концепция, которая обладает уникальным подходом. Если ты заменяешь в ней 90% своих интерпретаций на левые и называешь это диалектом своей - нет, это так не работает. Это будет диалектом той, у которой ты взял большинство.

Т.е. ингрировав в свою концепцию как основу всё иное, кроме своего - ты помножил её на ноль и она не имеет права на существоание в нормальном мире, а мире нулей - хотябы не называй её прежним уровнем.

Лисп и есть императивщина...

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

Один подход снизу, а второй сверху. лиспы, всякая ооп-мура - это всё из одной оперы - модели сверху. От шизофрении к реальности - императивщина же от реальности к шизофрении.

Спутать их никак нельзя.

Ну конечно, ссылки тоже не всегда анализируются. Но для указателя вдобавок может встретиться ++p, и сиди думай, куда теперь он указывает. Для ссылок так не бывает, а в остальном аналогично.

Типичная логическая ошибка адептов, не предрасположенных к логике как таковые.

++p - это поведение за рамками ссылки, т.е. ты не можешь сравнивать и называть минусом то, аналога чего нет в твоей ссылки.

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

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

Настоятельно советую ознакомиться с нечеткой логикой, которая описывает реальный мир лучше чем булевая.

Не описывает. Опять же - адепт тотально не предрасположен к логике.

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

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

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

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

Точно так же, как всё называется «программистом». Если у секретарши «программисты» - это все, кто не пугается железяки, то в этом мире вы - не особо отличаетесь от секретарш.

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

И тут действует точно такая же логика - логика иерархии - она такая же чётка - соответствуешь или нет.

Далее происходит вырождение области и она пробивает дно и уже секретарша с экселем и еникей - программист. Он же там хреначит что-то на башике/павершеле.

Можно мне увидеть примеры нечёткости в текущем мире?