Программируете ли вы на Паскале?

Даже j рядом с ним уже создает путанницу в порядках - где по логике должен использоваться i, а где j.

По вложенности обычно используют i, j, k, l, m, иногда счетчики никак нормально не назовешь. Но если их можно обозначить как x, y, z, или другим более подходящим именем, то стоит конечно.

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

Так как речь об обучении, то можно сразу Werror + clang-tidy, в CLion все настраивается и сразу при наборе коде видны проблемы. Еще неплохо было бы добавить clang-format на on save action, а то код выше так и просится...

Мое мнение - C/C++ имеют хорошие инструменты, которые перекрывают преимущества Pascal которые он имеет.

int x = 0;
int some_counter = 0;
bool ok = false;

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

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

и старайтесь возражать развернуто. или не возражайте вообще.

присвоение в переменную захватит это регистр

О чём вы??

и старайтесь возражать развернуто. или не возражайте вообще.

Никто никогда не «преаллоцирует регистры» под local variables, тем более если имеют место быть function calls в инициализаторах, и как мы помним - на x86 int’ы возвращаются в eax. Повторюсь - объясните мне пожалуйста что такое «резервирование регистров» в этом контексте?

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

отвечу за вас. в первом - стек резервируется под три переменных, во втором - под одну.

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

Никто никогда не «преаллоцирует регистры» под local variables,

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

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

Вперёд. Когда инициализаторы - это function calls. Ага.

Вперёд. Когда инициализаторы - это function calls. Ага.

даже если инициализаторы - вызовы функций. какая разница когда вызвали функцию???

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

int x;
x = fun()

и

int x = fun();

просто второе - короткая запись первого.

даже если инициализаторы - вызовы функций. какая разница когда вызвали функцию???

Огромная. Начнём с того что 3 int’а неожиданно схлопнулись в один. И закончим тем как вы собрались заранее регистры под local variables резервировать при наличии function calls когда вообще непонятно что в этих функциях происходит?? Бред.

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

чтобы захватить регистр Rn, делается -

push Rn ///спасается на стек, возможно вызывающая функция его использует
...
используем Rn под личные нужды.
...
pop Rn;
return;

это классика. классику надо знать.

да возьмите выхлоп любого современного компилятора и посмотрите где там сидят локальные переменные.

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

отвечайте развернуто. вы не сумели привести ни одного аргумента.

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

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

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

если вам выгода неочевидна, то вы можете читать исходники хоть до опупения. толку ноль. :)

просто посчитайте такты при захвате регистра

ПлАчу: «захват регистра», мать его… Давайте лучше MESI обсудим, cachelines, cachelines bouncing, CAS, lockless algos, итд итп. Или мы снова об «ивентах» разговор заведём? И об их фундаментальности?

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

свои lockless и кешлинии обсуждайте с кем нить другим… гы.

мне эти вопросы неинтересны в принципе, поскольку являются чисто аппартными. сменится «аппарат», все полетит кувырком.

свои lockless и кешлинии обсуждайте с кем нить другим… гы.

Действительно. Куда уж нам недалёким то. Удачи!

мне вот реально неинтересно «попадать в кешлинию». или обсуждать запутанно-перезапутанные локфри алгоритмы. любая запутанность есть зло.

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

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

Из последнего - нет у меня 500 «тредов». У меня всего лишь пару тысяч процессов. Часть из них общается через SHM (причём 1 <-> 1), и вот сделать этот comm completely lockless - та ещё эквилибристика. На самом деле и «вкусно», и «познавательно».

На самом деле и «вкусно», и «познавательно».

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

мне вот кааца, что проще купить еще железа, и распараллелить. и не мучаться.

о слишком высокой загрузке железа, а когда это проиходит - это «работа на краю»

Вы даже не представляете…

мне вот кааца, что проще купить еще железа, и распараллелить. и не мучаться.

Хех!

Современный Delphi нативно есть под онтопик. И даже фришная версия есть, вроде. Но это не точно.

Ты хотел сказать «необязательно»? Это разные вещи. Слово Program, Unit или Library в начале исходника добавляет исходнику основательности, законченности и сразу указывает на его назначение.

Современный Delphi нативно есть под онтопик.

Нет, но можно скомпилировать приложения под Linux.

И даже фришная версия есть, вроде.

Такая есть, с ограничениями.

Современный Delphi нативно есть под онтопик.

Он же стоит как автомобиль. Для хобби хватает lazarus.

Unit и library - значимые штуки, без них не скомпилируется как надо. Program - чисто декорация, и ничего она не добавляет кроме декоративности. В древних паскалях оно использовалось для объявления используемых файлов (программой, не компилятором) или чего-то такого, потом от этого избавились.

Помню в универе учились в Delphi, но все курсовые я делал во freepascal

связался с Solaris, и покатился…

куда прикатился?

в школе в германии?

Откройте наконец для себя уже warnings - та ещё полезняшка.

Я, когда сидел на Генту, компилил проги из официального репозитария, так там эти предупреждения сыпались все 2-5 часов компиляции. Так что я не удивляюсь утверждениям, что всё заново переписать легче, чем всё исправить.

Все примеры что вы приводили до сих пор ловятся более чем тривиально.

Естественно, поскольку это тривиальные примеры ради предупреждения о самой возможности накосячить, а не реально существующие косяки из очередного «TDE» в пару миллионов строк

Дяденька, у работы размерность не такая.

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

Просто не называй переменные одной буквой

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

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

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

По вложенности обычно используют i, j, k, l, m, иногда счетчики никак нормально не назовешь.

Так можно поступать только математикам, которым все эти i, D, df и т.д. что-то говорят, остальным следует всегда использовать «говорящие» идентификаторы: i_first, j_second, k_third или хотя бы i_1, i_2, i_3, но не i1, i2, i3.

C/C++ имеют хорошие инструменты, которые перекрывают преимущества Pascal которые он имеет

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

Т.е. сначала учимся программировать, чему поможет Паскаль, а потом учим ЯП. Но Си – только для профессиональных программистов, немного очень ограниченного с железной дисциплиной кодописания – физикам, инженерам и математикам (последним всё же лучше Лисп на CL, можно даже без Паскаля, но после булевой алгебры, контактных схем, машины Тьюринга или Поста и до Фортрана).

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

последним всё же лучше Лисп на CL

Common Lisp мертвый и убогий. Лучше уж взять Python, а так уверен у них есть свои языки для доказательств, или чем они там занимаются? Я даже не знаю.

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

Лучше до, с паскалем можно допустить много ошибок, а в настроенном CLion попробуй это сделать.

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

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

Ещё раз - да, С сложный ЯП. Вам просто не надо на нем писать, как и рассуждать о физике (физика для Вас тоже слишком сложная), и все будет ОК.

вседозволенность Си способна порождать идиотские ошибки

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

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

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

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

Проблема может быть в стороннем коде.

Не работайте с проблемным сторонним кодом? Сдуру можно все что угодно сломать. Скажем в том же питоне 100500 способов отстрелить себе все ниже пояса, ничего пишут же.

А уж плюсы это вообще ад.

Используйте проверенный сторонний код.

sabacs по существу есть что сказать? Я тебя внимательно слушаю.

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

Чушь. Что-то еще?

Больше ничего. Ты уже полностью раскрылся, так сказать.

Не работайте с проблемным сторонним кодом?

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

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

Писать можно на чем угодно, существуют же IBM RPG, SAP, 1C. Но нельзя отрицать наличие проблем.

Это твой лучший аргумент был, я так понимаю?

Поясняю для клованов:

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

Уверен проблем со спутанным именем переменной были и в Linux, что же теперь, отказываться? А уж сколько в проектах которые ты используешь каждый день было глупых уязвимостей связанных с плохим проектированием С? У Linux вообще миллионы глаз, что то от ошибок это не спасает, твои советы напоминают высказывание «с изобретением Fortran отладка теперь исчезнет», только у тебя вместо ЯВУ выступает ревью. В ядре юнит-тестов сколько лет не было?

Почему тебя волнуют чужие проекты? Баги в них фиксят их авторы.

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

В общем за всё хорошее против всего плохого. Теоретик, судя по всему.

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

Насколько я понимаю, он уже не работает «наемным программистом в офисе», как и AntonI. Как только люди перестают работать на работе, то сразу забывают начисто в чем там дело, такая же проблема и у Stanson, стал продавать интернеты, и теперь выдает топовые изречения в стиле «предлагаешь systemd - тебя нужно уволить сразу и никуда нипускать, это очевидно ЛЮБОМУ!!!». Заметил я такую общую черту.

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

Не знаю таких, не думаю что они существуют. Что вместо линукса посоветуешь?