LINUX.ORG.RU

Правильный(???) стиль работы со строковыми данными на С

 ,


2

4

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

К примеру, размеры mult1_str, mult2_str и equal_str известны, нужно выделить память под всю строку:

snprintf(
    buf,
    buflen,
    "%s miltilple %s equals %s",
    mult1_str,
    mult2_str,
    equal_str
    );
варианты:
- махнуть шашкой и сделать килобайт на стеке ( ((( )
- ничем не размахивать и посчитать руками. (еще хуже)
- написать функцию которая будет вычислять длину «%s miltilple %s equals %s» без символов подстановки (уже лучше)
- отказаться от snprintf и собирать строку пачкой конкатенаций с аллокациями памяти и прочим...

А как делаешь ты?


Я беру C++, а если мне кто-то говорит что нужно использовать C плюю ему в рожу, пишу докладную его непосредственному руководителю, а если надо по цепочке выше о профнепригодности и беру C++.

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

А ты на С много писал? Интересно стало.

Deleted
()
Ответ на: комментарий от slovazap

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

Deleted
()
Ответ на: комментарий от Deleted

Вы детский сад устроили тут какой-то: «мой папа твоему папе морду начистит». У вас своя голова есть, или за вас начальство думает?

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

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

byko3y ★★★★
()
Ответ на: комментарий от byko3y

просто популярен среди продвинутых аутистов

Эмм, если обвиняешь в том что я делаю детский сад, будь добр не устраивай его сам, а то выглядит как наглое лицемерие. И с чего ты взял что кто-то из нас карьерист? Не наговаривай.

А сраться по поводу С vs C++ мы с ним начали ещё до этого треда, так что ты просто не в курсе контекста :D

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

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

byko3y ★★★★
()
Ответ на: комментарий от byko3y

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

Deleted
()
Ответ на: комментарий от byko3y

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

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

vinvlad ★★
()
Ответ на: комментарий от Deleted

А сраться по поводу С vs C++ мы с ним начали ещё до этого треда

О каком сраче может идти речь, если вы даже не программист.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Это мне может мешать? Ты вот не писатель (вероятно), но пишешь текст. Для того что бы обсуждать что-то не обязательно иметь для этого призвание или специальность. Также можно о готовке мяса спорить и не быть поваром.

Deleted
()
Ответ на: комментарий от slovazap

Я беру C++, а если мне кто-то говорит что нужно использовать C плюю ему в рожу, пишу докладную его непосредственному руководителю, а если надо по цепочке выше о профнепригодности и беру C++.

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

ocr
() автор топика
Ответ на: комментарий от Deleted

Это мне может мешать?

Да. Вы не разбираетесь в предмете, но мнение имеете.

Также можно о готовке мяса спорить и не быть поваром.

Если спорите не с поваром - то пожалуйста.

RazrFalcon ★★★★★
()
Ответ на: комментарий от Deleted

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

slovazap ★★★★★
()
Ответ на: комментарий от RazrFalcon

Если спорите не с поваром - то пожалуйста.

Спасибо, только вот повар не делает правильно, правильного способа готовки мяса не существует в принципе и спорить с ним можно, ты понял суть то?

Да. Вы не разбираетесь в предмете, но мнение имеете.

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

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

Deleted
()
Ответ на: комментарий от slovazap

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

ocr
() автор топика
Ответ на: комментарий от slovazap

Ну, так там дело в человеке. Если полгода рефракторил самого себя. Так на любом языке можно. Ну если вы перестали писать на С в этом нет ничего плохого, значит выбрали иные технологии в чём проблема. Под каждую задачу желательно выбирать наиболее подходящее и то без фанатизма, а то проект 1, а рабочих языков 63 и на каждый пук прогрессивный фремворк/либа. Ну ты понял. Это я могу писать на том что мне просто нравится и более общно. Сишка покрывает широкий круг задач для меня в том и фишка. Да, порой видно что какую то отдельную вещь удобнее/быстрее и проще сделать на ином, но у меня написать лишнюю функцию для себя боли не вызывает и всё у меня в одних рамках и мне норм. Вот поэтому я и не понимаю твоего бугурта. И да нормальных языков не бывает, они просто все разные. Эх, ладно.

Deleted
()
Ответ на: комментарий от slovazap

Ну в реальном мире оказалось что человек последние полгода занимался в основном тем что правил свои же баги, поэтому уволили так человека и на C писать перестали.

Полное отсутствие какой-либо логики в поведении начальства ) Тут вообще-то «начальство» надо увольнять, если смена языка проекта определяется просто тем, что какой-то конкретный чувак взялся не за свое дело. Да, грамотно и надёжно писать на C может далеко не каждый - но это не недостаток языка. Ну просто способности у людей разные... И, соответственно, не каждого встречного-поперечного нужно сажать на задачи, где требуется программирование именно на C.

vinvlad ★★
()
Ответ на: комментарий от Deleted

Вот то что уровень не высок, это да.

Вот это «да». Человек не написал ничего сложнее хелоуворлда, но рассуждает о высоких материях.

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

Человек, бросающий сырое мясо в костёр и обсуждающий кулинарное искусство с поваром - это вы. PS: повар в шоке.

Если для тебя это не так то ты странный.

Я, но не ты. Логика / 0.

RazrFalcon ★★★★★
()
Ответ на: комментарий от vinvlad

Да, грамотно и надёжно писать на C может далеко не каждый - но это не недостаток языка.

Для начальства - недостаток.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Вот это «да». Человек не написал ничего сложнее хелоуворлда, но рассуждает о высоких материях.

Ну, я хотя бы не фантазирую. А вот о высоких материях даже намёка не было.

Человек, бросающий сырое мясо в костёр и обсуждающий кулинарное искусство с поваром - это вы

Лучший способ, улететь в космос крайностей. Круто чё. Мммм, а ты нарцисс, как был так и остался. Расчёску для ЧСВ пора менять :D

Я, но не ты.

Естественно, мы все разные.

я

Думать о разном, заниматься разным и для всего иметь «свой» взгляд и мысли это нормально

ты

Логика / 0.

Оооооок, вопросов нет. Интересно было поболтать, до свидания. Топ-топ-топ-топ….

P.S.: Будь подобрее, может ты там и умный, но злой как я не знаю что.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 3)
Ответ на: комментарий от vinvlad

Да, грамотно и надёжно писать на C может далеко не каждый - но это не недостаток языка

Вот за одну эту фразу можно уже увольнять.

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

... Да, грамотно и надёжно писать на C может далеко не каждый - но это не недостаток языка

Вот за одну эту фразу можно уже увольнять.

А ты не отдельные фразы выдергивай, а весь пост попытайся «переварить» ) Или способностей не хватило? Тебе видимо задачи просто не попадались низкоуровневые, вот ты наивно и считаешь, что все можно делать на языках уровнем повыше С.

vinvlad ★★
()
Ответ на: комментарий от Deleted

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

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

На любом языке писать надежно может далеко не каждый, нужен опыт везде!

Deleted
()
Ответ на: комментарий от vinvlad

А ты не отдельные фразы выдергивай, а весь пост попытайся «переварить» ) Или способностей не хватило?

А вы можете аргументировано вести обсуждение, а не на детсадовском уровне, с «или слабо?» и «а мой папа твоего на C перепишет». Ты прямо написал - «грамотно и надёжно писать на C может далеко не каждый - но это не недостаток языка». Это неимоверный бред, потому что только и недостатком языка это и является. Он неэффективен и небезопасен.

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

Тебе видимо

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

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Да нет, есть варианты проще. Есть хобби, а программирование это хобби для многих и тут вырастает огромная разница между элитизмом, бизнесом и прочим. Когда программирование это твоя профессия и ты по сути инженер, а код твой инструмент это одно. А хобби это иное там твоя воля на 100% Тебе нравится язык, ну тупо вот нравится и всё и ты на нём пишешь то что тебе надо и всё. В этом случае аргументы по применимости не катят. Вот кто-то на PHP гуй пишет… или тому подобное. А вот должен или нет использоваться надо смотреть не идеологически, а технически. Если у меня atmega8L и тулчейн готовый и отлаженный, то будет крайне странно городить прошивку для замеров двух датчиков на чём то ином кроме С. Ну как пример. Хотя даже там может быть вообще свой микро язык чисто под задачу, да хоть Rust через последующую трансляцию

надёжно писать на C может далеко не каждый

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

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от slovazap

ну вот представь себе, что тебе нужно запрограммировать какой-нибудь микроконтроллер... Или те же драйвера писать ты на чем собираешься? На Java? )) Да, такими задачами может заниматься далеко не каждый. Те же модули ядра грамотно и надежно программировать может далеко не каждый. Вон, полно людей, которые и высокоуровневый СУБД-шный SQL освоить не способны.

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

vinvlad ★★
()
Ответ на: комментарий от RazrFalcon

это точно
моя изначальная задача была «выкачивать данные по http и складывать их в базу». Ссылок может быть овердофига. Потом добавилась сортировка и понеслось. Работать с https я отказался. Мог сделать это на Qt, но в тот момент многие моменты были неясны, это сейчас понятно что можно использовать кастомный эвентдиспетчер на EPOLL...((

ocr
() автор топика
Ответ на: комментарий от Deleted

А хобби это иное там твоя воля на 100%

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

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

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

вот и вся разница.

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

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

slovazap ★★★★★
()
Ответ на: комментарий от vinvlad

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

Представлять мне ничего не нужно, я пишу под микроконтроллеры на C++ и микропитоне.

Те же модули ядра грамотно и надежно программировать может далеко не каждый. Вон, полно людей, которые и высокоуровневый СУБД-шный SQL освоить не способны.

К чему вся эта балаболия? Я жду хоть каких-то аргументов почему хоть что-то нужно и можно писать на C. Пока всё что я увидел - твои представления о программировании микроконтроллеров на уровне прошлого века.

slovazap ★★★★★
()
Ответ на: комментарий от vinvlad

Да, такими задачами может заниматься далеко не каждый

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

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

anonymous
()
Ответ на: комментарий от slovazap

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

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

vinvlad ★★
()
Ответ на: комментарий от vinvlad

Повторю еще раз: разным задачам - свой набор подходящих языков.

Не надо юлить. Ответь прямо на вопрос - каким задачам подходит C? И аргументируй.

slovazap ★★★★★
()
Последнее исправление: slovazap (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

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

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

В моем случае си это ошибка

ocr
() автор топика
Ответ на: комментарий от slovazap

anonymous: Вау, сколько ЧСВ. А ведь область совершенно тупая, задрачивается монотонной долбежкой с железом в течение нескольких лет.

Не надо юлить. Ответь прямо на вопрос - каким задачам подходит C?

Да я вроде тебе уже привел примеры - ты просто не читаешь ) А у anonymous-а вообще фантазия разыгралась... )

Ну вот, к примеру, мы здесь на LOR-е беседуем. Ядро Linux-а на чем написано? И с чего вы решили, ребятишки, что только вы одни другие языки знаете?

vinvlad ★★
()
Ответ на: комментарий от slovazap

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

Deleted
()
Ответ на: комментарий от ocr

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

И что такого в C++, что оно медленнее плюсов? Или это Эдик нашептал.

RazrFalcon ★★★★★
()
Ответ на: комментарий от vinvlad

Да я вроде тебе уже привел примеры - ты просто не читаешь )

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

Ну вот, к примеру, мы здесь на LOR-е беседуем. Ядро Linux-а на чем написано?

Выше я уже кого-то тыкал носом в несусветную глупость использования легаси как аргумента за язык. Мне не сложно, ткну ещё раз: даже если забыть про абсурдность такого аргемента, легаси, вообще-то, кладезь аргументов за НЕприменимость C, о чём кричит каждая ошибка и уязвимость в коде за всё его историю.

И с чего вы решили, ребятишки, что только вы одни другие языки знаете?

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

slovazap ★★★★★
()
Ответ на: комментарий от Deleted

Так он умер, причём уже давно. Просто если вы не программируете, вы этого и не увидите - отмашки вам никто не даст.

slovazap ★★★★★
()
Ответ на: комментарий от RazrFalcon

Да все практически, например sprintf vs stringstream. Можно конечно писать на си с классами, но это другое.

Deleted
()
Ответ на: комментарий от slovazap

Представлять мне ничего не нужно, я пишу под микроконтроллеры на C++ и микропитоне.

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

anonymous
()
Ответ на: комментарий от slovazap

использования легаси как аргумента за язык

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

Deleted
()
Ответ на: комментарий от slovazap

И вообще, я просил не примеров, а обоснования почему им подходит C.

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

vinvlad ★★
()
Ответ на: комментарий от RazrFalcon

Если бы Линус начал его писать сейчас, он опять бы выбрал С.

Deleted
()
Ответ на: комментарий от RazrFalcon

Ядру линя 25 лет

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

anonymous
()
Ответ на: комментарий от RazrFalcon

предлагает переписать тонны легаси

еще одиин идиот - какое легаси ? это самое современное коммерчески успешное ядро ОС.

anonymous
()
Ответ на: комментарий от anonymous

Они там еще переписывают иногда важные подсистемы, модернизируют ядро постоянно, могли бы уже начать новое делать, по настоящему шовременное!

Deleted
()
Ответ на: комментарий от anonymous

А у Оракла самая коммерчески успешная СУБД. Знаешь сколько в ней легаси? Чини словарь.

anonymous
()
Ответ на: комментарий от anonymous

коммерчески успешная СУБД. Знаешь сколько в ней легаси?

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

anonymous
()
Ответ на: комментарий от vinvlad

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

Ну вот самый простой пример: тебе надо обращаться напрямую к конкретным адресам оперативной памяти… Большинство высокоуровневых языков тебе такой возможности не предоставляют.

Какие, назовите их. Хотя бы понимание того что C++ может всё что может C у вас должно быть? Про unsafe в rust слышали? Про inline assembler в микропитоне может и не слышали, так будете знать. При этом современные языки гораздо более выразительны чем убогий сишный (volatile uint16_t*)0x123 которым наверняка ограничивается всё ваше знание, и позволяют более точно указывать семантику регистра, а значит получать более оптимизированный код.

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

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

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

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

пример будет или опять болтовня ?

anonymous
()
Ответ на: комментарий от slovazap

обычно не пишу ничего фанатикам, но мне интересно реакция на такой вопрос.. на чем сложнее писать — на Си или на крестах?

waker ★★★★★
()
Ответ на: комментарий от anonymous

пример будет или опять болтовня ?

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

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

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

Что характерно, у меня коллега на Qt пишет, мировой чел, и кодит прилично, так вот, он в программисты из менеджеров пришёл, возможно потому у него и иммунитет. Сейчас, например, на Андроиде под явкой пишет, без всяких выпендрёжей! Он единственный нормальный плюсовик, которого я знаю лично. С остальными(хорошими) я знаком только по их коду в котором ковырялся/правил. Остальные знакомцы — сраные елитарии и нарцисы, выдающие свой говнокод, за божественное откровение.

anonymous
()
Ответ на: комментарий от slovazap

... Хотя бы понимание того что C++ может всё что может C у вас должно быть? ...

Ну вот мне, например, очень нравится C# - писал на нём код за денежки. Или к примеру, если речь пойдет о backend-е, то, пожалуй Golang возьму - из-за встроенной асинхронности работы с сокетами и наличия изначально встроенных в язык «зеленых» потоков. И на С++ очень много писал, и свой и чужой Cи-шный код приходилось и дорабатывать и использовать (это иногда дает понимание того, что есть задачи чисто для C) - всё тоже не для себя, а за денежки. Ну вот я почему-то не лезу в чужие темы с выступлениями типа «ваш язык - говно, а вы все - чудаки»... Всякому языку своё место. Ну давайте еще Oracle на Питоне перепишем! ))))))))))

с чего вы взяли что высокоуровневое программирование невозможно без динамического выделения памяти?

Не путайте понятия «высокоуровневый язык» и «высокоуровневое программирование». Когда вы пишете строчку типа «str1 = str2 + str3», в процессе её выполнения для сохранения значений переменных используется не стек - память выделяется динамически (иначе она очень быстро закончится). Когда вы используете плюсовый new-оператор, то память под объект тоже выделяется динамически.

Если есть память, её можно выделять динамически

Можно написать код, который будет реализовывать этот функционал, но пишется такой код не на C++ и не на Питоне )))

vinvlad ★★
()
Ответ на: комментарий от vinvlad

Ну вот мне, например, очень нравится

Мне наплевать что вам нравится. Я задал конкретные вопросы, ответов я не увидел.

Всякому языку своё место

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

Когда вы пишете строчку типа «str1 = str2 + str3», в процессе её выполнения для сохранения значений переменных используется не стек - память выделяется динамически

Для начала, о какой именно реализации строк вы изволите столько снисходительно разглагольствовать?

Можно написать код, который будет реализовывать этот функционал, но пишется такой код не на C++ и не на Питоне )))

Этот код, как и любой другой, пишется и на C++ и на питоне.

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Этот код, как и любой другой, пишется и на C++ и на питоне.

Судя по вашим выступлениям у вас отсутствует нормальное профильное образование и такая область деятельности как «системное программирование» для вас просто пустой набор слов. Я вот вам привел ссылочку на проект micropython-а. Вот идите туда и рассказывайте авторам, что они все дураки...

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

vinvlad ★★
()
Ответ на: комментарий от waker

Писать просто на всём. Сложнее чтоб оно потом работало и от кода не тянуло блевать.

anonymous
()
Ответ на: комментарий от vinvlad

Если ты много писал на C++, то давно можешь ответить на вопрос - что можно сделать на C, что нельзя на C++. Или нельзя на Rust. Но от тебя ничего кроме лозунгов. Как раз таки свойственных людям без «нормального профильного образования».

anonymous
()
Ответ на: комментарий от anonymous

Если ты много писал на C++, то давно можешь ответить на вопрос - что можно сделать на C, что нельзя на C++ ...

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

vinvlad ★★
()
Ответ на: комментарий от vinvlad

То есть по сути у вас возражений нет, я понял. Вся аргументация «но на C же что-то написано!».

Ok, тогда продолжим возить вас лицом по _вашему_ профильному образованию. Я жду ответа

Для начала, о какой именно реализации строк вы изволите столько снисходительно разглагольствовать?

slovazap ★★★★★
()
Ответ на: комментарий от vinvlad

ссылку дал на конкретный C-шный проект

Микропитон? Ты выше микроконтроллеры привел как пример ниши для C, теперь сам приводишь проект, дающий другой, более удобный язык для этой ниши (хотя и до тебя его тут приводили). Ты там определись внутри себя. Или ты думаешь что программист на микропитоне пишет на самом деле на C?

Еще драйвера упоминались, ну так не только их, а целые ядра на C++ пишут, если это для тебя новость.

Если у вас профессиональных знаний не хватает

Для постоянных съездов на личности надо бы свою компетентность сначала показать. В этом треде от тебя вообще никакой технической конкретики.

anonymous
()
Ответ на: комментарий от slovazap

Вся аргументация «но на C же что-то написано!»

так у тебя никакой аргументации вообще - «я не пишу на С значит он не нужен!»

anonymous
()
Ответ на: комментарий от anonymous

Вся аргументация «но на C же что-то написано!»

так у тебя никакой аргументации вообще - «я не пишу на С значит он не нужен!»

Э не, у него аргументация другая «кто пишет на С, тот не нужен»

anonymous
()
Ответ на: комментарий от anonymous

более удобный язык для этой ниши

ты всегда покупаешь что более удобно или всё же смотришь снвчала на цену ?

anonymous
()
Ответ на: комментарий от anonymous

Если питон дорог - берем кресты

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

anonymous
()
Ответ на: комментарий от anonymous

Вы там с тезисами определитесь. «Не могу взять язык, жена/начальник/Линус не позволяет» - не то же самое что «на языке нельзя решать эти задачи».

anonymous
()
Ответ на: комментарий от anonymous

«Не могу взять язык, жена/начальник/Линус не позволяет» - не то же самое что «на языке нельзя решать эти задачи»

разумеется не то же самое, повторю вопрос - ты уже написал хоть один драйвер для Linux на питоне/крестах ? я разрешаю.

anonymous
()
Ответ на: комментарий от slovazap

То есть по сути у вас возражений нет, я понял. Вся аргументация «но на C же что-то написано!».

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

vinvlad ★★
()
Ответ на: комментарий от anonymous

Микропитон? Ты выше микроконтроллеры привел как пример ниши для C, теперь сам приводишь проект, дающий другой, более удобный язык для этой ниши (хотя и до тебя его тут приводили). Ты там определись внутри себя. Или ты думаешь что программист на микропитоне пишет на самом деле на C?

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

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

anonymous
()
Ответ на: комментарий от anonymous

«пчёлы против мёда»

«неосиляторы против профессионалов» скорей всего.

anonymous
()
Ответ на: комментарий от anonymous

Ниша есть? Есть, сам признал.

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

А с эмоциями сам иди лесом.

Какие тут эмоции, голые факты и опыт.

anonymous
()
Ответ на: комментарий от slovazap

Отвечай на прямой вопрос (С vs С++).

C - это язык, для запуска кода которого на гольном железе достаточно установить указатель стека. Для запуска и полноценой работы C++ кода требуется предварительная инициализация runtime-среды - нужен какой-то уже реализованный механизм «кучи» для хранения объектов, нужно предварительно инициализировать static-объекты. Ну т.е. чтобы запустить C++ код на гольном железе, предварительно должен быть запущен код, подготовленный си-шным программистом со знаниями «внутренностей» конкретного С++ компилятора (та же самая картинка, что и в случае с микропитоном).

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

Для более подробных обсуждений, если тебе очень хочется «поглумиться» над отсталыми ретроградами-сишниками (с твоей точки зрения), лучше открой отдельную тему. Может, туда заглянут грамотные люди, которым не лень тратить свое время на подобные обсуждения, и тебе всё растолкуют на пальцах. Могу только еще добавить, что если вдруг в одначасье вымрут все сишники - основательно так и навсегда :) - то следом загнутся все диалекты UNIX-систем, Linux, да и Windows тоже. Всё придется начинать «с нуля». На C очень много чего завязано.

vinvlad ★★
()
Ответ на: комментарий от anonymous

Или ты думаешь что программист на микропитоне пишет на самом деле на C?

программист на QML на самом деле не пишет на C++. QML понятней, проще, безопасней, UI летает по сравннию с убогими плюсовыми виджетами. Следуя вашей логике (вернее отсутствию её) можно сказать что C++ не нужен вообще.

целые ядра на C++ пишут

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

anonymous
()
Ответ на: комментарий от anonymous

QML понятней, проще, безопасней, UI летает по сравннию с убогими плюсовыми виджетами

давно пора плюсовое легаси на Rust переписать

anonymous
()
Ответ на: комментарий от anonymous

Ниша для чего? Для уровня хеллоуворлд?

Да хотя бы даже.

Какие тут эмоции

Вот эти:

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

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

anonymous
()
Ответ на: комментарий от anonymous

Следуя вашей логике (вернее отсутствию её) можно сказать что C++ не нужен вообще.

Тут действительно отсутствие логики, только не у меня.

этого мусора навалом на гитхабе, только попроси плюсовика сыграть мурку

То ли дело сишники, ага. Каждый второй сделал готовый продукт на продажу.

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

мне непонятно - для чего нужен C++ если если есть С и Rust. С это настоящее, Rust возможное будущее, а C++ для чего ? То что на нём что-то написано - это не аргумент.

anonymous
()
Ответ на: комментарий от vinvlad

Отвечай на прямой вопрос (С vs С++).

Я этого не писал, не надо мои цитаты подменять. Ты мне не ответил на:

Для начала, о какой именно реализации строк вы изволите столько снисходительно разглагольствовать?

И предупреждаю: когда ответишь, это будет только начало того как я буду тебя возить лицом по луже твоей безграмотности, потому что наглому безграмотному школию не написавшему ни строчки ни на C, ни на C++, нельзя прощать разглагольствования о применимости языков, да ещё и поучения с использованием лживых фактов.

Для запуска и полноценой работы C++ кода требуется предварительная инициализация runtime-среды - нужен какой-то уже реализованный механизм «кучи» для хранения объектов

Я тебе ещё раз говорю - нет, не нужен. Что ещё придумаешь?

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Считай это ответом на твои заявления:

Серьёзно, как можно прямо заявить что «надёжно писать на C может далеко не каждый», и при этом спорить с тем что C не должен использоваться нигде.

Хотя бы понимание того что C++ может всё что может C у вас должно быть?

То есть по сути у вас возражений нет, я понял. Вся аргументация «но на C же что-то написано!».

нужен какой-то уже реализованный механизм «кучи» для хранения объектов

Я тебе ещё раз говорю - нет, не нужен...

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

P.S. По поводу строчек: «String представляет собой строку, размещённую в куче».

vinvlad ★★
()
Ответ на: комментарий от vinvlad

На микроконтроллерах и С кастрированный. Так что C не настоящий и не годится для ембеда. Набросил.

anonymous
()
Ответ на: комментарий от anonymous

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

vinvlad ★★
()
Ответ на: комментарий от vinvlad

Считай это ответом на твои заявления

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

Я повторяю вопрос: о какой именно реализации строк вы имели неосторожность заявить что они выделяются исключительно на куче?

Ну раз «куча» не нужна, то это уже будет не полноценный C++

Второй вопрос - в чём вы измеряете полноценность, и почему она зависит от наличия кучи?

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Вся аргументация «но на C же что-то написано!».

Ну так авторы микропитона дураки без образования или нет?

Deleted
()
Ответ на: комментарий от anonymous

C++ нужен тем, для кого C это прошлое

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

anonymous
()
Ответ на: комментарий от slovazap

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

Deleted
()
Ответ на: комментарий от slovazap

в чём вы измеряете полноценность, и почему она зависит от наличия кучи?

Ну если C++ без оператора new - это для вас полноценный язык, имеющий какие-то преимущества над С ...

vinvlad ★★
()
Ответ на: комментарий от vinvlad

Ну если C++ без оператора new

С чего ты взял что без? Что, по-твоему, делает new? Как он связан с кучей? Как часто он, по-твоему, используется в современном C++?

это для вас полноценный язык, имеющий какие-то преимущества над С …

Абсолютно. Тебе есть что возразить?

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

... Что, по-твоему, делает new? Как он связан с кучей? Как часто он, по-твоему, используется в современном C++?

ну насмешил... ))

vinvlad ★★
()
Ответ на: комментарий от vinvlad

Я жду ответов на поставленные вопросы - посмеёмся вместе. Ну или сразу признавайся что не знаешь.

slovazap ★★★★★
()
Последнее исправление: slovazap (всего исправлений: 1)
Ответ на: комментарий от slovazap

Да нет - это ты мне ответь: где, по-твоему, хранятся значения строчных переменных (объектов) произвольной длины - в стеке или в «куче»?
Не литералов, не указателей - а к примеру значения std::string?

vinvlad ★★
()
Ответ на: комментарий от vinvlad

Да нет - это ты мне ответь

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

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

Я не просто так спросил - про какую ты реализацию строк? У меня есть реализация где они вообще не хранятся.

Не литералов, не указателей - а к примеру значения std::string?

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

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Ок, std::string. Они могут храниться где угодно.

А где угодно - это где? (без собственного кастомного аллокатора). Вот к примеру, написал ты:

std::string s1 = s2;
где s2 - это тоже std::string переменная с каким-то значением. Что в этот момент происходит внутри STL-класса?

vinvlad ★★
()
Ответ на: комментарий от waker

Хотя бы понимание того что C++ может всё что может C у вас должно быть?

даже restrict может?

Конечно может

struct T { int i; };
struct T var_1;

int main () {
   T * __restrict  var2 = &var_1;
   int * __restrict  var_3 = &var2->i; // undefined behavior
   {
      int * __restrict  var_4 = &var2->i; // допустимо
   }
   return 0;
}

Проверил и на gcc и на clang и на MSVC

C++ может всё, что может С и плюс ещё много другого.

Но это и хорошо, чтобы знать С++ нужно знать С хотя бы на каком-то уровне. Без С++ было бы меньше знающих С, так как уменьшалась бы мотивация осваивать С...

fsb4000 ★★★★★
()
Ответ на: комментарий от RazrFalcon

На стеке ...

Не-не-не. Строчка в s2 у нас очень длинная оказалась ) Что в этот момент происходит внутри STL-класса?

vinvlad ★★
()
Ответ на: комментарий от waker

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

fsb4000 ★★★★★
()
Ответ на: комментарий от vinvlad

А где угодно - это где? (без собственного кастомного аллокатора)

О, неужели наконец прочитал про кастомный аллокатор? И сфига ли без него?

Где угодно, это, например, на стеке, потому что SSO. Что позволяет писать высокоуровневый код работающий со строками без вызовов new вообще. С использованием кастомного аллокатора, как ты наконец догадался, данные строк также можно хранить где тебе нравится - в специально выделенном для этого глобальном куске памяти, на стеке, в TLS, в регистрах, где угодно. Так что всю чушь которую ты нёс про необходимость рантайма, якобы предоставляющего некую магическую кучу, непременно написанную на C, можешь забыть. Аллокатор - это всего лишь функция, возвращающая кусок памяти, в зависимости от твоих нужд она может занимать 5 строк и при этом будет работать весь stl.

Далее, std::string - это не единственная реализация строк, и, понятное дело, не самая удобная для embedded программирования, коли мы о нём заговорили. Боюсь разрушить твой мир, но есть реализации строк которые вообще не хранят содержимое строки. Можно хранить дерево, листьями которого являются константы и ссылки на переменные, а узлами - операции конкатенации. Она ничего не аллоцирует, она ленивая, она умеет считать длину строки в compile time (constexpr), при этом взаимозаменяема с std::string + std::to_string, что позволяет один и тот же код (а у нас большая часть кода прошивки рисует менюшки и взаимодействует с пользователем, помимо неё есть только загрузчик и минимальный HAL) собрать как в автоматические тесты (и иметь в итоге 100% покрытие), так и в десктопное приложение эмулирующее девайс, так и в собственно прошивку, изменением одного флага компилятора.

Я хочу чтобы ты как следует подумал как реализоваыл бы всё это на C.

Вот к примеру, написал ты std::string s1 = s2:

Удивительно, но мы опять возвращаемся к вопросу о реализации строк. Потому что в libstdc++ до c++11, когда были позволены refcounted строки, в этот момент происходило только инкремент счётчика ссылок. Не то что ты ожидал?

slovazap ★★★★★
()
Ответ на: комментарий от fsb4000

Но тем не менее, это не стандарт, т.е. в c++ его нет. Юзать можно конечно, но потом при сборке под экзотичную платформу оптимизация превращается в тыкву. Впрочем, c99 под те платформы тоже нет, так что в целом пофигу на стандарты.

waker ★★★★★
()
Ответ на: комментарий от slovazap

О, неужели наконец прочитал про кастомный аллокатор?

У тебя воспаленная фантазия. Я много лет программировал платежные терминалы на C++ )

«Сфига ли без него» ...

ну так ты ж у нас про прелести высокоуровневого C++ ратуешь, стало быть не должен жизнь усложнять такими сложностями. Чем писать собственную хитрую реализацию хранения строк (еще лишних ошибок наделаешь), может проще и компактнее просто прямо всё контролировать на С? И с чего ты взял, что мы говорим только об «embedded» и все можно посчитать во время «compile time». Ты ж влез в обычную C-шную тему...

vinvlad ★★
()
Последнее исправление: vinvlad (всего исправлений: 1)
Ответ на: комментарий от vinvlad

У тебя воспаленная фантазия. Я много лет программировал платежные терминалы на C++ )

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

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

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

может проще и компактнее просто прямо всё контролировать на С?

Не может. Проще и компактнее это так:

temp_message = "temperature="s + to_string(temp) + "°C"s;  // temp - показание с датчика

это одна строка, она очевидна даже девочке-пиэму, здесь негде ошибиться или что-то забыть, здесь нельзя выехать за границу буфера, здесь нельзя взять sizeof или strlen не от той строки, здесь нельзя не освободить ресурсы. При этом она будет работать и на AVR без аллокаций вообще, и на десктопе с изкоробочным stl. Это - высокоуровневый код, и любой код должен быть таким.

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

всё контролировать

Постоянно слышу это от начинающих программистов. Потом это проходит.

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

temp_message = «temperature=„s + to_string(temp) + “°C"s;

Да уж... ради такого, конечно, надо специальный кастомный код писать для хитрого хранения строчек, в котором запросто может оказаться ошибка (тут что C, что С++ - все едино). И не дай бог еще за границу массива вылезешь... )

vinvlad ★★
()
Ответ на: комментарий от vinvlad

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

Скажи, ты специально придуриваешься? Кода этих менюшек в одном девайсе - под тысячу sloc, и он постоянно дорабатывается. И ошибка не должна оказаться там, а не в двух страницах реализации строк, написанных 5 лет, покрытых тестами и с тех пор не менявшихся, за исключением добавления to_string для пары дополнительных типов. Я очень хотел бы посмотреть как ты напишешь хотя бы одну десятую этих менюшек на C.

И не дай бог еще за границу массива вылезешь… )

О чём я и говорю. В C всё «не дай бог». В C++ этот класс ошибок также можно полностью исключить, при желании на этапе компиляции.

slovazap ★★★★★
()
Ответ на: комментарий от anonymous

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

vinvlad ★★
()
Ответ на: комментарий от vinvlad

не дай бог - оказаться в одном рабочем пространстве вот с таким фанатиком

годы разработки менюшек в конторе менюшкошлёпов - у любого крыша съедет

anonymous
()
Ответ на: комментарий от anonymous

И ведь так и не захотел явно признать, что в C++ напрямую встроены динамические запросы памяти. Даже когда уже прямо про new-delete несколько раз напомнили и попросили конкретно объяснить, что происходит при присвоении значений произвольной длины в std::string, ужом стал изворачиваться и вести себя как нашкодивший кошак, которого мордой в лужу тыкают. Сначала попытался смухлевать ссылкой на SSO. Не вышло - на какую-то свою персональную реализацию хранения строк попытался стрелки перевести. Демагог и трепло...

vinvlad ★★
()
Ответ на: комментарий от vinvlad

slovozap упертый хам, но я бы предпочел работать с ним, у тебя какое-то очень альтернативное восприятие происходящего. Ибо C++ без кучи тебе показали. И, между прочим, new-delete запросто могут не использовать кучу. Короче нет, не «напрямую встроены».

anonymous
()
Ответ на: комментарий от anonymous

И, между прочим, new-delete запросто могут не использовать кучу. Короче нет, не «напрямую встроены».

Мне не показали C++ без динамических запросов памяти - был упомянут частный кастомный вариант хранения строк, в алгоритме которого так или иначе должны быть задействованы динамические запросы памяти, если речь идет о произвольных строчках. Ну можно было про другие, более сложные контейнеры упомянуть, где вообще не имело смысла так мудрить, как со строчками.

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

Под словом «куча»/heap просто подразумевается вариант постоянного хранения данных и объектов - как альтернатива стеку. Без такого функционала это уже не C++, о преимуществах которого принято твердить. Ну и, естественно, такие альтернативные, самописные «кучи» уж точно не добавляют надежности коду. Си ведь ругают за «ненадежность» - а тут на тебе... «улучшили» C++ )

vinvlad ★★
()
Ответ на: комментарий от vinvlad

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

Хранить подстроки как интрузивный список, и вроде можно обойтись.

Если использование даже своей кучи недопустимо и в си ты обошелся без нее, то и в C++ обойдешься так же. Контейнеры STL отвалятся большей частью, алгоритмы останутся. И останется еще 100500 фич языка. Не надо думать что он тут же скатится до си.

anonymous
()
Ответ на: комментарий от anonymous

Если использование даже своей кучи недопустимо и в си ты обошелся без нее, то и в C++ обойдешься так же

Т.е. сначала заявляется: С++ такой весь из себя классный и универсальный, а C - «говно» и его нигде использовать нельзя. Ну какой-нибудь молодой студент думает: Во, зашибись - напишу-ка я начальный загрузчик, а потом и новое ядро на C++. Зачем мне этот древний С? И тут начинаются тонкости: этого оказывается нельзя использовать, того тоже нельзя... С runtime-средой непонятки... И вообще чего можно, может рассказать только абстрактный «Вася» - и то, в отношении конкретного компилятора. Зашибись супер-замена.

И останется еще 100500 фич языка.

Ну, это очень сильное преувеличение в отношении системных задач.

vinvlad ★★
()
Ответ на: комментарий от vinvlad

И тут начинаются тонкости

Есть ещё один момент, который стараются замолчать: на Си можно написать «любой» компилятор. Не на многих «любых» компиляторах можно написать сам компилятор Си.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от vinvlad

И вообще чего можно, может рассказать только абстрактный «Вася» - и то, в отношении конкретного компилятора

Не эмбеддщик, но открытые ОС на плюсах есть, значит есть база знаний. Целая подгруппа в комитете этим занимается. А с динамической памятью всё довольно ясно и от компилятора не зависит.

это очень сильное преувеличение в отношении системных задач

Навскидку, шаблоны и constexpr много стоят. И вообще язык сильно движется в сторону compile-time возможностей.

anonymous
()
Ответ на: комментарий от Deleted

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

anonymous
()
Ответ на: комментарий от anonymous

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

template<T> T foo(T x) { return x+1; }

Здесь все ровно, но это простой случай. Что если для комплексных чисел нужно добавлять не 1, а 1+i? Или на основании наличия/имени какого-то поля в типе аргумента решать, что делать дальше? Это не движение в компайл-тайм, а просто макросы на стероидах. Метакод сейчас не может общаться с компилятором на равных, он просто имеет совещательный голос. Как насчет:

template<T> void complex_foo(T x) {
    auto m = std::meta(x);
    typedef void T::bar_proto();

    if (m.methods['bar'] && m.methods['bar'].proto == bar_proto) {
        x.bar();
    }

    x.baz();

    auto filename = std::string("./%s/null-members.txt").format(m.identifier);

    for (auto name : read_names_from_file(filename)) {
        m.set_member(name, nullptr); // x.<name> = nullptr
    }

    // прочие прямолинейные подходы
}

И пусть компилятор сам решает, что можно делать в compile-time, а что нет. Контраргументы типа «ну это слишком даст волю стрелять в ногу» уже слышал.

anonymous
()
Ответ на: комментарий от slovazap

Какие, назовите их. Хотя бы понимание того что C++ может всё что может C у вас должно быть?

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

К тому же, С++ не может ничего сам по себе - т.к. базовый язык(который и может всё) - там си, причём достаточно обрезанный.

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

Предоставь основания этим нелепым потугам.

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

Ты не балаболь, а показывай.

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

Это аксиома. Хочешь поспорить - показывай.

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

Опять сел в лужу. Я специально проверил и он действительно под динамическим выделением имел ввиду рантайм. Ну вот, задачу я тебе определил - показываешь язык без рантайм-зависимостей/инжектов.

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

NishiragiShintaro
()
Ответ на: комментарий от vinvlad

С++ такой весь из себя классный и универсальный

Твоя информация немного устарела. Актуальный С++ уже частично отвязан от рантайма.

И тут начинаются тонкости: этого оказывается нельзя использовать, того тоже нельзя... С runtime-средой непонятки...

Остались только исключения, но через пару лет(возможно, если опять не пожрут раст-говна) завезут статические исключения.

Ну, это очень сильное преувеличение в отношении системных задач.

В контексте актуального С++ - уже нет. На самом деле нет где-то уже с С++17.

Правда мало кто это всё использует, поэтому у рядовых адептов С++ без рантайма действительно днище.

NishiragiShintaro
()
Ответ на: комментарий от anonymous

Ты просто написал неведанную херню - ты явно из жабаскрипта сбежал.

По поводу сути твои рассуждений - они имеют смысл. Но ты неверно мыслишь. Т.к. ты адепт жабаскрипта - ты не разделяешь рантайм/компилтайм. В этом твоя проблема.

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

Дело в том, что декларативность в С++ статичная. Т.е. у нас весь компилтайт - статичный. Нельзя ничего изменять, нельзя ничего переопределять, нельзя ничего удалять. Но.

Ведь по-сути это полная херня. Что нам мешает иметь не статичный, а динамический компилтайм. Ведь комплятор - это попросту интерпретатор конструкций, описанных в коде. А сейчас он ещё и интерпретатор кода.

Но зачем нам язык для интерпретатора ограничивать статикой? Незачем. Поэтому на уровне компилтайма С++ можно превратить в жаваскрипт. Где можно как угодно изменять поля, где можно передавать auto везде и всюду. Не делать никакой разницы между типами и значениями. Сейчас мы живём с костылями вида type_c<T>.

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

Допустим, как ты будешь реализовывать асист в ide тогда, когда у тебя пропадёт вся эта декларативность? Там асист до сих пор не может в шаблоны.

Поэтому все и идут по базовому пути. Пихаем что придумали, но ни о чём фундаментальном не думаем. Хотя С++ в этом плане ещё адекватен. Всякие там расты - это просто помойка.

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

NishiragiShintaro
()
Ответ на: комментарий от anonymous

Хейтеры С - они такие! Мозгов нет, вот и выдумывают всякие отмазки, чтобы С не изучать!!!

anonymous
()
Ответ на: комментарий от NishiragiShintaro

вместо vla есть alloca (да, нужно быть аккуратнее, так как область действия у alloca функция, а не {} как у vla, и в цикле не нужно делать выделения, но мне и vla в циклах не нужно было)

Вместо compound literals, можно использовать обычные литералы.

char lam[] = "lamerok";
p = lam;

Где нельзя использовать обычные литералы(обычно это всякие макросы), то решаем задачу с помощью ifdef...

Типа такого:

#include <stdio.h>

long double (sum)(long double* arr, size_t arr_size)
{
    long double result = 0.0L;
    for (size_t i = 0; i < arr_size; ++i)
    {
        result += arr[i];
    }
    return result;
}

#ifdef __cplusplus

template<class ... Types> 
long double sum(Types ... args)
{
    const size_t size = sizeof...(Types);
    long double arr[size] = {static_cast<long double>(args)...};
    return sum(arr, size);
}

#else

#define sum(...) (sum)((long double[]){__VA_ARGS__}, \
    sizeof((long double[]){__VA_ARGS__})/sizeof(long double))

#endif


int main()
{
    long double res = sum(1,2,4,5);
    printf("res = %f\n", (double)res);
}

inline есть и в C++.

fsb4000 ★★★★★
()
Ответ на: комментарий от fsb4000

вместо vla есть alloca (да, нужно быть аккуратнее, так как область действия у alloca функция, а не {} как у vla, и в цикле не нужно делать выделения, но мне и vla в циклах не нужно было)

Тебя попросили показать, а ты мне начинаешь рассказывать какие-то истории охренительные. К тому же аллока не имеет никакого отношения к С++.

Вместо compound literals, можно использовать обычные литералы.

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

К тому же - ты не используешь «обычный литерал» - ты используешь его копию. Зачем ты пытаешься меня обмануть?

Где нельзя использовать обычные литералы(обычно это всякие макросы), то решаем задачу с помощью ifdef...

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

inline есть и в C++.

Нету.

NishiragiShintaro
()
Ответ на: комментарий от anonymous

Во-первых ты пишешь херню. Во-вторых ты нихрена не понимаешь. То, что ты написал - это не С++. Так же, ты не понимаешь НИЧЕГО. Т.к. твоя портянка вообще никак не связана с проблемой описанной мною.

NishiragiShintaro
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.