Простых экспортируемых функций недостаточно, когда продукт постоянно развивается. Через некоторое время возникнет нехороший эффект версионности. Короче — dll hell.
Очевидно, что нужно написать экспортилку. Можешь экспортить в JSON, можешь в XML, можешь в сишный static const char []. Экспорти куда хочешь — свобода.
Потому, что головой не думают.
Фотошоп — слои и сетка, этого достаточно. Плюс маленькая программка, которая пикселы сравнивает для построения тайлсета. При этом первично игровое поле, тайлсет вторичен. Единственное что нужно, это художнику объяснить, чтобы он мысли свои выражал по 16 пиксельной границе (это довольно сложно, дизайнеры плохообучаемы).
Даже триггеры нормально размещаются с помощью закраски квадратиков ярким цветом.
Дык ить, это современная экономика. Курями в свиней пулять стоит 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() будет применяться в неявном виде.
А продолжим тем, что есть gimp или corel painter в поставке с драйверами на wacom.
Фотошоп — слои и сетка, этого достаточно. Плюс маленькая программка, которая пикселы сравнивает для построения тайлсета. При этом первично игровое поле, тайлсет вторичен. Единственное что нужно, это художнику объяснить, чтобы он мысли свои выражал по 16 пиксельной границе (это довольно сложно, дизайнеры плохообучаемы).
Даже триггеры нормально размещаются с помощью закраски квадратиков ярким цветом.
Когда всё это лопнет мало никому не покажется.
А нулевые символы вообще ничему не мешают.
Триумфальное шествие юникса произошло потому, что он попал в лапы студентов в 70е, и их на нём учили. А ещё в нём есть юзнет.
>Как раз стандартная библиотека си, наряду с модульностью на включаемых >файлах — его слабое место.
Модульность! На включаемых файлах!
>Есть такие языки, для которых «сложнейший объект» является с одной стороны >простым, с другой — вполне совместим с массивом символов.
Вот я и говорю — за это надо бить.
>В совокупной стоимости использования. Получение размера как O(1) и >отсутствие запрещенных элементов имеет колоссальный мультипликатор >полезности за счет использования на всех уровнях, от драйверов до
>скриптов.
Кошмар.
Единственная область применения, где имеет смысл заранее измеренная длина это приём/передача данных.
Не лучше, а быстрее.
> Ага, как же, своей кучи помимо системной не бывает :)
Бывает, но своя куча стандартной библиотекой не поддерживается.
>Это принципиально. Потому что почти любая «платформа» написана таки на си. Со всеми вытекающими.
И что?
>Расскажите это дельфистам.
Кому?
>Это «просто» означает порчу памяти и эксплойты.
Да ну?
> Потому что это дешевле, чем нуль-терминированные строки.
Где ты увидел дешевизну?
В результате того, что сложный, я бы сказал — сложнейший тип выделен в «простые» программист не видит динамического выделения памяти. Принципиально, концептуально — не видит. А динамическое выделение памяти, между прочим, к рантайму языка и его библиотеке отношения не имеет, оно имеет отношение к операционной системе и платформе.
И теперь сравни это с «постоянным проходом» и исключением нуля. Да хер с ними, это непринципиально!
Ну, и, дальше.
После того, как сложнейший тип обёрнут в простой, программист лишается возможности оперировать с ним как с массивом простых типов. А это чревато. Идиотские конструкции 'left', 'right', 'mid' проблем только добавляют и вынуждают неявно использовать динамическое выделение памяти.
Вообще, эта надуманная проблема сишных строк решается довольно просто:
struct string {
short size;
char content[];
};
… и вся хрень должна иметь размер sizeof(short)+sizeof content[];
а нахера, собственно?
Нажимают на спусковой крючок или шнеллер.
Вот так, на этом простом примере мы видим, что надо понимать что ты делаешь.
Но если взять С++ и стандарт разработанный теоретиками, в виде std::string, то мы увидим, что в нём отсутствует возможность сравнения строк без учёта регистра, что критично для строк из набора ASCII (латинских). Теоретики, мать их, кампухтер сайенс, мать её.
Во вторых — схема работы со строками в С оптимальна!
В третьих — язык, разработанный практиком отличается от языка, разработанного теоретиком наличием встроенного типа 'string'.
Обработка строки внутри довольно сложный процесс. Если его не сделать, хотя-бы визуально, немного более сложным, то это приведёт к огромной потери производительности в большом проекте. В статье Спольски об этом упомянуто, но не написано, что при использовании встроенных типов строк всё, что он рассказал про malloc() будет применяться в неявном виде.