Модули в C

Может выкинут, а может и нет. Фича нужная, не понимаю зачем её вырезать. В основном используется 1-3 размерности. По крайней мере у меня так. Я понимаю, что это не удобно, но снова, лучше варианта ведь нет. Фортраном мало того что мало пользуются даже в научной среде, так ещё нет уверенности, что производительность на уровне С.

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

Да ты еще и по Фортрану специалист.

Где я выставлял себя специалистом хоть в чём-то? Меня просто заинтересовало ваше высказывание про многомерные массивы и решил уточнить. На счёт фортрана, я работал в одном НИИ, где писали кое-какой наукоёмкий софт, так вот писали там прототип в матлабе, а потом переписывали на C/C++, некоторые сразу на C/C++, но ни одной программы на фортране.

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

Да ты еще и по Фортрану специалист.

Где я выставлял себя специалистом хоть в чём-то?

В процитированной фразе.

потом переписывали на C/C++ некоторые сразу на C/C++, но ни одной программы на фортране.

Это может говорить о многом, но только не о сравнительной производительности Фортрана и Си.

Во. Ретрограды подъехали. Ты ещё ООП на ассемблере приведи. Чё сишники только не придумают, чтобы не писать на нормальных языках с ООП.

в реальной жизни ООП нужен в 0.01% случаев

ООП - естественный подход к описанию предметов окружающего мира. Именно поэтому он так удобен.

поэтому от его отсутствия в C никто не страдает.

В 99.9% сишных программ будет кривая пародия на ООП через макрокостыли как у stanson'чика.

я работал в одном НИИ, где писали кое-какой наукоёмкий софт

Argumentum ad verecundiam во все поля

Я тоже в одном НИИ работал, там вообще ничего не писали, только руками работали. А в другом НИИ только математики сидели.

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

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

ты что-нибудь кроме школьных заданий писал?

Как быстро ты слилась в обсуждение личности.

программирование не описывает «реальный мир»

Здрасте. Компьютер тем и занимается, что обрабатывает данные из реального мира. Ну кроме абстрактных математических штук, но их меньшинство. И вообще, ты про domain driven design слышала? Ах да, у сишников же паттерны проектирования не в почёте, вам бы велосипеды поизобретать.

оно имеет дело с системными ресурсами

Давай, ещё раз расскажи про свой подвиг с разработкой pci железки. Я соскучился.

математическими моделями

Т.е. математические модели никакого отношения к реальному миру не имеют? Тогда что они моделируют? Кроме вышеупомянутой абстрактной фигни.

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

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

Я понимаю, но тут речь про «I've seen things you people wouldn't believe». Тут каждый может свой опыт привести, но это не значит, что нужно обобщать.

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

Может и так. Но мне иногда ООП кажется весьма удобным с точки зрения дизайна моего научного кода.

Программирование не ограничивается только лишь лютой системщиной. Утверждение обратного - проявление манямирка.

На счёт фортрана, я работал в одном НИИ, где писали кое-какой наукоёмкий софт

ты сходил во все отделы и спросил какой язык они используют?

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

На территории РФ, наверняка меньше чем C++, но не факт, что за пределами ситуация такая же.

С уровнем производительности всё хорошо.

И когда ты используешь VLA память под него разве не в стэке выделяется? В некоторых случаях это действительно хорошо и даже быстрее, да и размер стэка можно увеличить перед компиляцией. Зато не даёт возможности изменить размер массива после его объявления.

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

пожалуйста: сети, базы данных, любой бэкенд, утилиты. никакого намёка на ООП.

А ты правда системный программист? Не найти никакого намека на ООП в сетях - это... даже не знаю, как это. PostgreSQL - объектно-реляционная СУБД, MySQL вообще на Си++ написан.

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

С++ - не ООП. ещё раз. я уже сто раз это писала. «написан на С++» не означает какого-либо отношения к ООП. можно его написать на С. никакой разницы не будет.

сети, базы данных, любой бэкенд, утилиты.

Что из этого нельзя написать с использованием ООП?

даже если попытаться натянуть сову на глобус (применить ООП в сетях), то ничего не получится.

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

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

Он просто написал руками ущербную версию того что делает С++ автоматически если пользователь попросит. А если не попросит, то С++ сам скукоживается до С

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

то можно написать без его использования. ответ - всё.

Никто и не спорит.

сделать оверинжиниринг

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

Просто ООП - не обязательно лобуда с наследованием и виртуальными методами.

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

https://doc.rust-lang.org/beta/book/second-edition/ch17-01-what-is-oo.html

а если вы попробуете в raw socket со своими жабками - тут же сядете в лужу с производительностью

Жабка это не про производительность.

ну и вообще весь этот слой никак не совместим с теоретическими фантазиями про наследования

Вот опять. Тебя кто-то насильно заставляет использовать наследование? Если в конкретном случае оно не нужно, то просто не делай. Будет класс без предков.

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

А ты правда системный программист? Не найти никакого намека на ООП в сетях - это... даже не знаю, как это. PostgreSQL - объектно-реляционная СУБД, MySQL вообще на Си++ написан.

в сетях - вообще никакого. от слова совсем

Хм. То есть ты не знакома с сетевым стеком Linux. Забавно.

каждый день лазаю в RFC и имею дело с протоколами

Ну, если ты искала ООП в RFC, кто ж тебе доктор.

С++ - не ООП.

Си++ - это больше, чем ООП. А вот классы и наследование - это именно ООП. И, внезапно, оно используется в серверах СУБД.

«написан на С++» не означает какого-либо отношения к ООП. можно его написать на С. никакой разницы не будет.

Разработчики gcc смотрят на тебя, как на сумрачную царицу сишки.

более того, даже эти «некоторые элементы» можно и вовсе не применять :) но ящик Пандоры уже открыли и это расползлось по всему миру.

Хм. То есть ты не знакома с сетевым стеком Linux. Забавно.

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

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

Полиморфизм, который вытирается компилятором полезен. Использовать одну функцию суммы чисел (или любой другой функции высшего порядка) в списке, множестве, последовательности - полезно и удобно. Легко читается, указывает намерение программиста декларативно, ничего не стоит в рантайме если реализовано в языке правильно

и таки никакого ООП в ядре нет. от слова совсем

facepalm.jpg

https://lwn.net/Articles/444910/

https://lwn.net/Articles/446317/

Обычный снобизм, «ящитаю» и «я читала RFC» (да много кто читал, и чо?), с целью почесать ложное превосходство (и растянуть сроки выдачи результата на «слоптимизацию» от которой выхлоп будет с гулькин клюй, по сравнению с потраченным временем и баблом — зато ЧСВ у тебя опухнет с гарантией :)) Если б так все думали — до сих пор бы «свистели в модем двоичным кодом»... точнее, выставляли состояния памяти прямой коммутацией на патчпанели — а чо, слабо двоичным кодом-то, что за полумеры? Алсо есть мнение что мультипоточность эта твоя (особенно с блокировками) — «современный goto» и просто «форсед мем» компаний, производящих многоведерные процы, «придуманный в прошлом веке», вместо развития действительно нужных технологий.

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

детка, перегрузка функций в С была и в 80-е. мамой клянусь. никакое это не ООП. ООП придумали лет на 20 позже, дебилы-теоретики. так что узбагойся и не суй мне под нос эти писульки. я знаю, что и как в TCP-стеке устроено и что никакого «ООП» там нет.

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

Ты совершенно поехавшая.

так что узбагойся и не суй мне под нос эти писульки

Тетя, ты бы хоть посмотрела, кто автор этих «писулек».

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

фанаты могут обзывать «ООП» то, что существовало десятки лет до появления этого термина. и, кстати, существовало себе спокойно без всякой встроенной в язык программирования поддержки. никакой мишуры в С нет. и ООП там тоже нет. там есть работа с указателями - это да. и всё, что есть в ядре - это правильная работа с указателями. то самое, о чем тут неосиляторы постоянно плачутся в Девелопменте и никак не могут осилить самые простейшие вещи. и кричат, что им нужен «ООП» и «защита на уровне ЯП».

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

Ну да, просто у тебя в Си в 80-е годы была прегрузка функций, а через 20 лет изобрели ООП.

«при чём тут этот бред?» «я просто говорю о том, как реально устроена сеть»

«вместо того, чтобы учить студентов мультипоточному программированию» (с) Ты, если забыла, просто говоришь про сорта хайпа, почему-то считая один лучше другого :)

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

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

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

Yep, но это не значит, что его версия плоха.

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

Ну да, просто у тебя в Си в 80-е годы была прегрузка функций, а через 20 лет изобрели ООП.

да.

Да я понял уже.

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

никаких перегрузок

Как так, ведь перегрузка функций в Си есть с 80-х!!!11 (не с 70-х - значит, добавлена позже).

только прямые адреса функций

Каждый раз удивляюсь твоей замшелости. Хотя у тебя и вектор операций наверное, просто прямые адреса функций. И полного аналога с таблицей виртуальных методов ты в упор не видишь.

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

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

«Специалист подобен флюсу» (ТМ) В какую практику не укладывается ООП, судя по приведенным тебе хвостострелом опровержениям твоих утверждений о ядре?

Хотя у тебя и вектор операций наверное, просто прямые адреса функций. И полного аналога с таблицей виртуальных методов ты в упор не видишь.

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

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

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

Тетя, что ты несешь. «Прямой» адрес функции («прямой» вызов, direct call) - это адрес, заданный в команде:

call 0xDEADBEEF

Как ты собралась вызывать операцию из вектора через прямой адрес - ХЗ.

ничего сверхъестественного или «виртуального»

Ничего сверхъестественного и в ООП нет; а виртуального в ООП не больше, чем в векторе операций.

хвостострел не отличает эвфемизмы от реализации

Ага, кроме тебя вообще никто ничего не отличает.

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

Там со времен перешагивания через ручное программирование 10-го прерывания, давно не алгоритмы, а треугольники, шейдеры и банальная матричная математика :) конвейерная модель, где сущности создаются «по месту» и выдается ссылочный Id «этот буфер твой, ты наверное знаешь чо там». Но без софта, которому надо лопатить «объекты сцены» (которыми оперирует логика приложения), которым соответствуют эти пачки треугольников, это все только «рассеяние тепла в атмосферу» (особенно когда трассировка лучей и ныне «вон там»). А в гуе, которым обмазан сверху этот софт, чтоб мог делать что-то полезное, вообще поток один.

многопоточность

в которой ничего нового по сравнению с многопроцессностью нет, кроме пошареной памяти, совместный доступ к которой породил больше костылей, чем решил проблем (10 потоков на 10 ведрах норм, когда у них есть независимые куски работы, а вот типичные 50 за фасадом однопоточного по определению гуя на 4-х ведерном проце — какой-то борщ, который большей частью спит, греет проц или «борецца за лок», а на 100500 чего-то одновременного уже твои потоки ложатся не всегда... почти никогда, где есть 100500 нормальных процов или достаточно мультиплексирования на одном)

и кэш

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

но ядро-то написано до всех ваших ООП

Чо? Ядро чего? Ядро венды, которое появилось на основе древней как гуано VMS («от создателя»), оперирует «классами» (полуось тоже «объектно-ориентированная» была), ядро линукса написано существенно после разработки и внедрения в жызу «ООП» (и не удивительно что поимело кое-что в виду). «Обработчики прерываний» — это ты про какое ядро? ДОСа или эмбеда что ли? «Сферическое в вакууме ядро», из времен пакетной обработки, ооок. Перфокарты набивать не запарилась?