Проект на чистом Си

Предупреждения, повторюсь, никто не читает.

Не надо говорить за всех.

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

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

Выбор подходящей реализации?

Да. Реализация должна была быть из коробки, и она должна была быть одна. Все последующие языки избежали этой сишной ошибки - и совершенно правильно сделали.

вот только си возник за 20 лет до utf, и если б в нем была «только одна реализация строк», он бы умер.

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

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

вот только си возник за 20 лет до utf, и если б в нем была «только одна реализация строк», он бы умер.

Странно, Бейсик и Паскаль - также, возникли за 20 лет до utf, и не умерли.

си - язык системного программирования.

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

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

в си есть «последовательность байт»

Fixed.

какая еще «строка из коробки»?

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

зачем вам вообще тип «строка»??? что вы с ней собрались делать на си.

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

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

зачем вам вообще тип «строка»??? что вы с ней собрались делать на си.

Ну уж это ты загнул. Например, path - строка; strerr() или как его там – строка. А что делать – дык path конкатенировать, а strerr() выводить в stdout.

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

Какое представление? А какое вам нужно? Хотите - в паскалевском стиле, длинастроки-телостроки, чо б нет? В 80-х уже было понятно, какие строки бывают и зачем они нужны. Надо было выбрать самую современную реализацию - и стандартизировать её.

Зачем? А хоть бы и текст из файла считать как последовательность строк. И чтобы конкатенировать их через +, как в нормальных языках, а не через дурацкий strcat.

А раз не байт, а символов, значит называют «строкой» не вульгарно, а правильно. :)

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

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

вот сначала их определите.

А зачем? Что нам даст размер одного символа?

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

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

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

Блин, вот это и плохо! Это и есть сишный недостаток.

а си для того чтобы делать так в питонах.

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

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

Во, отличное определение: «всё, что написано буковками». :) Ну или например, «человеко-читабельный кусок памяти» (по аналогии с формулой «объект – это область памяти»).

«последовательность символов некоего представления текстовых данных»

Тоже сойдёт как определение строки.

По-моему, ты крючкотворством занимаешься. «Строка» – вполне себе устоявшийся термин. В упор не понимаю, чего ты к нему прицепился.

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

А должны? В плюсях и std::string – строка, и std::wstring – строка, и CharT* – тоже строка. Первые два даже содержат «string» в названии типа. :)

Я уж не вспоминаю про sizeof(wchar_t) в винде и линуксе, т.к. этот сраный бардак опять же не влияет на употребление термина «строка». Как и тот факт, что std::string вовсю юзают для хранения бинарных данных.

Короче, кошмарно-непонятная и мутная эта штука – строка. Вот думаю: может отказаться от её использования в своих проектах?

Реализация должна была быть из коробки, и она должна была быть одна. Все последующие языки избежали этой сишной ошибки

Вон чуть выше только что написали что в Rust аж три вида строк есть.

И не очень понимаю в чем такая принципиальная разница будет используемая в проекте реализация строковых функций из libc или она будет в отдельной подключаемой библиотеке. Вот если бы других вариантов реализации строк для Си небыло доступно (как например в начале 90х) и пришлось писать самому - я бы с вами согласился что это неудобно. Но сейчас-то легко можно найти и использовать готовое.

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

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

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

И тем не менее пишут. Для glibc-строк инклудят <string.h>, для std::string инклудят <string>.

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

Ну или например, «человеко-читабельный кусок памяти» (по аналогии с формулой «объект – это область памяти»).

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

В упор не понимаю, чего ты к нему прицепился.

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

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

Ваш прекрасный char* крайне небезопасен - и даже не умеет конкатенацию по плюсу.

прицепился потому, что строка не имеет строго смысла

Да и хрен бы с ней, не? :)

и нечего ее тащить в си, где есть прекрасный char* кроющий эту строку как слон черепаху.

Отмотал на твой камент и лайкнул. Но чисто из-за возмущений по поводу кучи. Главное (и возможно единственное) достоинство сишных строк – что с ними можно работать на стеке. А кто там кого кроет – это ещё бабушка надвое сказала. И как по мне, почему 0-terminated вместо length+data – вопрос открытый (т.е. length+data тоже можно хранить и оперировать на стеке).

Хотите - в паскалевском стиле, длинастроки-телостроки, чо б нет?

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

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

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

О, кстати: в плюсях можно было бы сделать template<class CharT, uint lengthBytes, uint maxLength> class std::basic_c_string. Во какой я прошаренный!

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

В 80-е 16 байт. В 90-е пора было расширять до 32. Но, разработчики стандарта же продуманы - они могли и ещё 16 байт зарезервировать на будущее.

И да, от архитектуры не зависит абсолютно.

Строка - устоявшийся тип, и в 80-е это уже было понятно.

Так это в 80е не особо требовались разные виды строк. Тогда и писать просто int было вполне нормально, а сейчас весьма часто приходится использовать типы с явным указанием разрядности и знака(uint32_t и тому подобное). Иначе если кто-то попробует собрать мою программу на 64-битной системе то она может и не заработать. Также и строки теперь в разных случаях требуются разные.

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

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

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

Так это в 80е не особо требовались разные виды строк.

Тем более! Надо было пользоваться моментом!

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

Сову на глобус натягиваете. Особенно для тачпада (стандартный-то функционал мыши работает).

template<class CharT, uint lengthBytes, uint maxLength> class std::basic_c_string

Или даже вычислять lengthBytes из maxLength. using Path = BasicCString<char,PATH_MAX-1> – шикарно ж (-1 т.к. PATH_MAX включает 0-terminator, который я буду обеспечивать для всех строк аналогично std::string). Всё на стеке. Копирование и конкатенация полностью аналогично strcpy() и strcat(), только размер не надо каждый раз вычислять и о переполнении заботиться; у двух строк должен совпадать только CharT. И rfind() быстрый. Пожалуй, добавлю себе в TODO, будет совсем нечего делать – запилю и заюзаю в check-link-consistency.

Бейсик и Паскаль - также, возникли за 20 лет до utf, и не умерли.

не умерли

Так давно уж

В марте 2020 года Microsoft заявила, что будет поддерживать Visual Basic в унифицированной платформе .NET 5.0, но больше не будет добавлять новые функции или развивать этот язык

Правда давно? Про Lazarus я вообще молчу - там и Embarcadero Delphi неплохо себя чувствует.

Пользователей у этого всего как у брейнфака уже.

Пользователей - да, но язык живёт и развивается. Прими в 80-е правильные решения - сишники точно так же жили бы сейчас с типом «строка» из коробки, и одной проблемы бы не знали.

Правда давно?

Конечно.

Про Lazarus я вообще молчу

И правильно, что молчишь, потому что это давно не Pascal, а Object Pascal. Я же не говорю, что в Си есть строки, потому что в С++ они есть.

В отличие от Си, на Паскаль нет стандарта, поэтому Object Pascal - это таки ж Паскаль.

Паскаль нет стандарта

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

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

но паскаль не умер же.

Вопрос терминологии сугубо. Пока существует хотя бы одна цифровая копия, информация как бы существует, с этим не поспоришь. Но на нашем бытовом уровне, что вы имеете в виду? Что паскаль кому-то в мире интересен как средство решения промышленных задач? Ну это же неправда - вакансий нет, проектов нет, поддержки от ИДЕ нет, спонсоров нет, новых статей не появляется, в интернетах не срутся, в ВУЗах не преподают, никто в него не инвестирует. В каком виде это живое?

проектов нет

Не то чтобы совсем нет

Да и статьи пишутся

Не то чтобы совсем нет

Я знал, я знал - сейчас начнется выискивание исключений и выдача их за мейнстрим. А вот в деревне Золупино до сих пор работает паровоз. Паровозостроение живо!

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

в си есть «последовательность символов» и библиотечные функции для работы >с такими последовательностями. в си все сделано правильно.

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

си - язык системного программирования.

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

А вот в деревне Золупино до сих пор работает паровоз. Паровозостроение живо!

Шутка

Ага и теорему Пифагора используют.

Воопще список «дряхлой старины» огромен: рояли, скрипки, колеса, ...

си - язык системного программирования. Но, не ассемблер, а язык высокого уровня.

Вообще-то задумывался чем-то вроде «переносимого ассемблера». Языка,максимально близкого к железу. Собственно, поэтому он сейчас активно используется для микроконтроллеров. (где,кстати, чаще всего никакого utf нет).

И да, тот же паскаль умеет работать с последовательностями байтов, в >сишном стиле, и со строками - одновременно.

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

зачем вам вообще тип «строка»???

Для формирования печатных документов например.

что вы с ней собрались делать на си.

Но это лучше делать НЕ на си. Хотя вобщем-то никто не запрещает - TeX как пример.

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

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

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

Вам или ассемблер, или шашечки. Если шашечки - можно было и строки запилить. Кстати, недостроки есть даже в ассемблере (внезапно!)

Собственно, поэтому он сейчас активно используется для микроконтроллеров. (где,кстати, чаще всего никакого utf нет).

Нет, и нет. В 80-е utf, тоже, не было, а строки - были.

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

Можно. Но я о том, что возможность работы со строками - должна быть из коробки. Подключать готовые библиотеки - нужно только тогда, когда изкоробочной версии не хватает. А её ведь хватает в 90% случаев.

Вообще-то задумывался чем-то вроде «переносимого ассемблера».

А можно какую-либо ссылку на K&R где бы подобное утверждалось? Ну правда, Си от ассемблера столь же далек, как и любой другой язык того времени. Это же глупости.

Подключать готовые библиотеки - нужно только тогда, когда изкоробочной версии не хватает. А её ведь хватает в 90% случаев.

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

Шутка

Лупше конечно быть уверенным, что всё ПРОСТО!