Дык ить, это современная экономика. Курями в свиней пулять стоит 9 миллиардов. Бесплатный поисковик стоит 200 миллиардов. Компания выпускающая бесплатный Линюх тоже от 9 до 200 миллиардов.
Многие знают о macromedia, как о создателе флеш, хотя она его не создавала, а купила. Создатель флеша — FutureWave Software. И назывался он тогда FutureSplash Animator.
>Лучше, качественно лучше. Собственно триумфальное шествие юникса >стало следствием именно замены ассемблера на си в качестве основного >языка системного программирования.
Триумфальное шествие юникса произошло потому, что он попал в лапы студентов в 70е, и их на нём учили. А ещё в нём есть юзнет.
>Как раз стандартная библиотека си, наряду с модульностью на включаемых >файлах — его слабое место.
Модульность! На включаемых файлах!
>Есть такие языки, для которых «сложнейший объект» является с одной стороны >простым, с другой — вполне совместим с массивом символов.
Вот я и говорю — за это надо бить.
>В совокупной стоимости использования. Получение размера как O(1) и >отсутствие запрещенных элементов имеет колоссальный мультипликатор >полезности за счет использования на всех уровнях, от драйверов до
>скриптов.
Кошмар.
Единственная область применения, где имеет смысл заранее измеренная длина это приём/передача данных.
Ты не догоняешь.
В результате того, что сложный, я бы сказал — сложнейший тип выделен в «простые» программист не видит динамического выделения памяти. Принципиально, концептуально — не видит. А динамическое выделение памяти, между прочим, к рантайму языка и его библиотеке отношения не имеет, оно имеет отношение к операционной системе и платформе.
И теперь сравни это с «постоянным проходом» и исключением нуля. Да хер с ними, это непринципиально!
Ну, и, дальше.
После того, как сложнейший тип обёрнут в простой, программист лишается возможности оперировать с ним как с массивом простых типов. А это чревато. Идиотские конструкции 'left', 'right', 'mid' проблем только добавляют и вынуждают неявно использовать динамическое выделение памяти.
Вообще, эта надуманная проблема сишных строк решается довольно просто:
struct string {
short size;
char content[];
};
… и вся хрень должна иметь размер sizeof(short)+sizeof content[];
Нормальное решение. И это значительно, на порядки лучшее решение, чем создавать новые строки динамически выделяя память на каждый чих, что и происходит при выделенном базовом типе string или при использовании класса std::string или его самописного аналога. Здесь постоянный проход asciiz строки для измерения размера как-то теряется в безднах системных вызовов.
Мы говорим про С.
Но если взять С++ и стандарт разработанный теоретиками, в виде std::string, то мы увидим, что в нём отсутствует возможность сравнения строк без учёта регистра, что критично для строк из набора ASCII (латинских). Теоретики, мать их, кампухтер сайенс, мать её.
Во первых — в С строк нет.
Во вторых — схема работы со строками в С оптимальна!
В третьих — язык, разработанный практиком отличается от языка, разработанного теоретиком наличием встроенного типа 'string'.
Обработка строки внутри довольно сложный процесс. Если его не сделать, хотя-бы визуально, немного более сложным, то это приведёт к огромной потери производительности в большом проекте. В статье Спольски об этом упомянуто, но не написано, что при использовании встроенных типов строк всё, что он рассказал про malloc() будет применяться в неявном виде.
Фар это не unix-way. Консоль в unix-way это стрим и контрол-сиквенсы. Фар-же валит в видеопамять, и не просто в видеопамять, а в IBM-PC-compatible видеопамять. И клавиатуру обрабатывает некошерно — не поддерживает терминалы PDP10, не говоря уж о перфораторах.
А ещё слэши у него не в ту сторону.
Когда всё это лопнет мало никому не покажется.
А нулевые символы вообще ничему не мешают.
Триумфальное шествие юникса произошло потому, что он попал в лапы студентов в 70е, и их на нём учили. А ещё в нём есть юзнет.
>Как раз стандартная библиотека си, наряду с модульностью на включаемых >файлах — его слабое место.
Модульность! На включаемых файлах!
>Есть такие языки, для которых «сложнейший объект» является с одной стороны >простым, с другой — вполне совместим с массивом символов.
Вот я и говорю — за это надо бить.
>В совокупной стоимости использования. Получение размера как O(1) и >отсутствие запрещенных элементов имеет колоссальный мультипликатор >полезности за счет использования на всех уровнях, от драйверов до
>скриптов.
Кошмар.
Единственная область применения, где имеет смысл заранее измеренная длина это приём/передача данных.
Не лучше, а быстрее.
> Ага, как же, своей кучи помимо системной не бывает :)
Бывает, но своя куча стандартной библиотекой не поддерживается.
>Это принципиально. Потому что почти любая «платформа» написана таки на си. Со всеми вытекающими.
И что?
>Расскажите это дельфистам.
Кому?
>Это «просто» означает порчу памяти и эксплойты.
Да ну?
> Потому что это дешевле, чем нуль-терминированные строки.
Где ты увидел дешевизну?
В результате того, что сложный, я бы сказал — сложнейший тип выделен в «простые» программист не видит динамического выделения памяти. Принципиально, концептуально — не видит. А динамическое выделение памяти, между прочим, к рантайму языка и его библиотеке отношения не имеет, оно имеет отношение к операционной системе и платформе.
И теперь сравни это с «постоянным проходом» и исключением нуля. Да хер с ними, это непринципиально!
Ну, и, дальше.
После того, как сложнейший тип обёрнут в простой, программист лишается возможности оперировать с ним как с массивом простых типов. А это чревато. Идиотские конструкции 'left', 'right', 'mid' проблем только добавляют и вынуждают неявно использовать динамическое выделение памяти.
Вообще, эта надуманная проблема сишных строк решается довольно просто:
struct string {
short size;
char content[];
};
… и вся хрень должна иметь размер sizeof(short)+sizeof content[];
а нахера, собственно?
Нажимают на спусковой крючок или шнеллер.
Вот так, на этом простом примере мы видим, что надо понимать что ты делаешь.
Но если взять С++ и стандарт разработанный теоретиками, в виде std::string, то мы увидим, что в нём отсутствует возможность сравнения строк без учёта регистра, что критично для строк из набора ASCII (латинских). Теоретики, мать их, кампухтер сайенс, мать её.
Во вторых — схема работы со строками в С оптимальна!
В третьих — язык, разработанный практиком отличается от языка, разработанного теоретиком наличием встроенного типа 'string'.
Обработка строки внутри довольно сложный процесс. Если его не сделать, хотя-бы визуально, немного более сложным, то это приведёт к огромной потери производительности в большом проекте. В статье Спольски об этом упомянуто, но не написано, что при использовании встроенных типов строк всё, что он рассказал про malloc() будет применяться в неявном виде.
А ещё слэши у него не в ту сторону.