Здравствуйте, мыщъх, Вы писали:

М>в курсе, что архитектурно. но в винде API разрабатывалось до архитектуры. и система писалась под API, а не API под систему, а система вообще собиралась поддерживать произвольный набор API, где win32 API был не цетром вселенной. поддержка posix была заявлена.
И потом дропнута.

М>>>я не предлагаю. я api вообще использую только специфическое (последний раз считывал показания счетчиков производительности и реализовано все это через одно место, можно было бы и через псевдофайловую систему реализовать). а так мне хватает libc.
BBI>>Мне его никогда не хватало. Более того, я практически ничем оттуда не пользуюсь дальше базового функционала уровня memcpy, который практически весь давно уже intrinsic в компиляторах.
М>если писать через API, то это делать программу намертво привязанную к платформе.
И пофиг. Зато оптимально юзаем возможности платформы.
Я когда то писал кроссплатформ. Причём платформы отличались сильнее чем win vs lin.
Что то больше не хочется.

Здравствуйте, Banned by IT, Вы писали:

М>>если писать через API, то это делать программу намертво привязанную к платформе.
BBI>И пофиг. Зато оптимально юзаем возможности платформы.
и чем же вызов CreateFile отпимальнее fopen? хотя, вероятно, у нас с вами разные задачи. я вообще не касаюсь гуи и интерфейса. у меня только ввод и вывод. аллокатор памяти свой, заточенный под конкретные нужны (освобождение памяти в определенные моменты времени).

BBI>Я когда то писал кроссплатформ. Причём платформы отличались сильнее чем win vs lin.
ну а я пишу под линух на ms vc 6. конечно, окончательно собирается оно gcc. но окончательная сборка она только перед релизом, что происходит не часто.

Здравствуйте, Driver, Вы писали:

D>Навеяно общением с идусским дизайнером...

вы забыли основную идею индусского кода — получение прибыли из воздуха

вот пример есть у вас программа

main()
{
 int a = 3;
 printf("%d\n", a);
}

что делать с этой программой что бы ее развивать но сохранить функциональность ?
правильно — заменяем тип int на класс и описываем класс для работы с числом 3
деньги получены, но проект надо дальше развивать
что нужно делать дальше?
правильно расширяем класс и добавляем в него еще кучу типов, обьектов итд
и так далее и в том же духе

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, Driver, Вы писали:

D>> В связи с чем возникает вопрос, а может все эти принципы программирования
D>>(KISS, поддерживаемость, инкапсуляция и т.п.) я понимаю неправильно? И надо брать с индусов пример?
М>я за KISS принцип. и мой шеф тоже за него. так что мы нашли друг друга. вообще, сравните апи никсов с виндами. вы действительно считаете, что в CreateFile должно быть столько параметров? и что у нее должно быть такое удачное название? и что нам позарез нужны все аргументы CreateProcess. и что нам нужно 100500 API функций?

Ну если вспоминать именно CreateFile() с её специфическим стилем, то принципиальная разница от open() в том, что в CreateFile() каждая отдельная характеристика метода открытия вынесена в свой метод, а у open() одна общая битовая маска flags. Второе действительно удобнее в нескольких аспектах — разумно понятное количество аргументов и расширяемость (например, было тривиально добавить O_NOFOLLOW, а покажите мне аналог под Windows), но принципиального различия, мне кажется, нет. Одно в другое переходит.

Вообще если вспоминать развитие API, то вряд ли можно вспомнить более классический пример, чем BerkeleyDB.
Версия 1: dbopen() о 5 аргументах (3 из которых взяты из open()).
Версия 2: надо расширить и углубить. Переименовываем в db_open(), расширяем и углубляем.
Версия 3: поняли, что углублять можно до бесконечности, а посему надо куда-то накапливать эти данные. Поэтому делаем db_create(), полученный хэндл набиваем параметрами и затем торжественно зовём dbh->open().
(Дальше там пошли уже пляски с транзакциями и прочей триокисью, это по-своему интересно, но главное уже успели сделать до.)

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

Здравствуйте, Banned by IT, Вы писали:

М>>>>вы действительно считаете, что в CreateFile должно быть столько параметров?
BBI>>>Да, я ими пользуюсь.
М>>интересно как юниксоидам хватает open?
BBI>Не хватает.
BBI>int open(const char *pathname, int flags);
BBI>int open(const char *pathname, int flags, mode_t mode);
BBI>int creat(const char *pathname, mode_t mode);

Это давным-давно одна функция. creat() это враппер для совместимости с кодом 70-х годов, реально даже не везде уже есть. Первая — на самом деле идентична второй в случае !O_CREAT. Двухаргументный open() тоже не везде уже есть.

Если уж говорить про две, то это будет open() и openat(). Но тут линейное логичное развитие.

М>>>> и что у нее должно быть такое удачное название?
BBI>>>Ну, название не особо удачное. Предложи лучше.
М>>см. posix open. уже давно предложили.
BBI>три функции там где в WinAPI одна. Да ещё одна с ошибкой в написании.

Это не ошибка, это намеренная редукция. Первые линкеры целевой среды поддерживали только 6 символов RADIX-50 в имени, внешние символы получали префикс '_', на собственно имя оставалось 5 символов. Все API имена тех времён не длиннее 5 символов.

М>>я не предлагаю. я api вообще использую только специфическое (последний раз считывал показания счетчиков производительности и реализовано все это через одно место, можно было бы и через псевдофайловую систему реализовать). а так мне хватает libc.
BBI>Мне его никогда не хватало. Более того, я практически ничем оттуда не пользуюсь дальше базового функционала уровня memcpy, который практически весь давно уже intrinsic в компиляторах.

Ну да, и системные вызовы не делаешь?

Здравствуйте, мыщъх, Вы писали:

М>>>если писать через API, то это делать программу намертво привязанную к платформе.
BBI>>И пофиг. Зато оптимально юзаем возможности платформы.
М>и чем же вызов CreateFile отпимальнее fopen?
Тем что он прямой. Не проходит через wrapper CRT в которой свои тараканы водятся.

М>хотя, вероятно, у нас с вами разные задачи. я вообще не касаюсь гуи и интерфейса.
М> у меня только ввод и вывод. аллокатор памяти свой, заточенный под конкретные нужны (освобождение памяти в определенные моменты времени).
Аналогично. У меня сейчас специализция kernel + virtualization + storage.

Здравствуйте, netch80, Вы писали:

N>Это не ошибка, это намеренная редукция. Первые линкеры целевой среды поддерживали только 6 символов RADIX-50 в имени, внешние символы получали префикс '_', на собственно имя оставалось 5 символов. Все API имена тех времён не длиннее 5 символов.
Это как в байке что размеры шаттла зависят от ширины лошадиной задницы в 16м веке?

N>Ну да, и системные вызовы не делаешь?
Что ты под этим понимаешь?
В винде libc как и libcp это тупо враппер над WinAPI

Здравствуйте, Eugeny__, Вы писали:

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

Любые крайности — неоптимальны.

[лирическое отступление]
Был у нас такой товарищь — тоже считал что мы идиоты, потому что все переусложняем. И что все надо делать проще. И все бы ничего, но у него как то так получалось, что упрощая, он почему то увеличивал сложность тех частей, за которые он не отвечал.
В конце концов нам это надоело, и ему поручили не особо сложный, но полностью вертикальный кусок. Целиком. Ну чтобы небыло отмазок, что мы своими заморочками портим ему жизнь.
В итоге, провозился он месяца два над тем, что можно было сделать за неделю. Хуже того, по его куску было какое то невероятное количество багов. Которые он до увольнения так все и не закрыл.
Ах да, его мегапростое решение в итоге оказалось проще полностью переписать.
[/лирическое отступление]

Здравствуйте, Banned by IT, Вы писали:

BBI>Здравствуйте, мыщъх, Вы писали:

М>>>>если писать через API, то это делать программу намертво привязанную к платформе.
BBI>>>И пофиг. Зато оптимально юзаем возможности платформы.
М>>и чем же вызов CreateFile отпимальнее fopen?
BBI>Тем что он прямой. Не проходит через wrapper CRT в которой свои тараканы водятся.
это с какого перепугу он прямой? KERNEL32.DLL это "толстый слой шоколада" над NTDLL.DLL, который идет куда-то вглубь, где сам черт не разберет кто его обрабатывает и сколько там фильтров-драйверов наложено. и CreateFile представляет некую абстракцию реальности, где и файлы и устройства и вообще непонятно что. а CRT как бы очень прозрачная абстракция, хотя, конечно, попытка работы с устройствами через fopen это к терапевту. да и вообще не факт, что вызов fopen дойдет до вызова CreateFile, особенно если мы создаем временный файл и форсированно закрепляем его в памяти (и без изучения исходных текстов CRT мы не может знать как оно отработает в конечном итоге).

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

М>>хотя, вероятно, у нас с вами разные задачи. я вообще не касаюсь гуи и интерфейса.
М>> у меня только ввод и вывод. аллокатор памяти свой, заточенный под конкретные нужны (освобождение памяти в определенные моменты времени).
BBI>Аналогично. У меня сейчас специализция kernel + virtualization + storage.
так ведь виртуализация это очень низкий уровень. тут без API не обойтись. а у меня основная работа идет с блоками памяти. взял блок, обработал, вернул результат. поэтому мне даже libc слишком много, а уж к АПИ обращаться и вовсе необходимости нет.

Здравствуйте, Eye of Hell, Вы писали:

...
EOH>Как раз хорошо написанный код проще менять при изменении бизнес требований.

нужна ли эта простота, может надо делать "плохо"?


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

Я вот не могу определиться, хочется всего и сразу (для простоты можно сказать что цель — бабло, но ничем отвратительным даже за бабло заниматься не будем).

Здравствуйте, мыщъх, Вы писали:

BBI>>Тем что он прямой. Не проходит через wrapper CRT в которой свои тараканы водятся.
М>это с какого перепугу он прямой? KERNEL32.DLL это "толстый слой шоколада" над NTDLL.DLL, который идет куда-то вглубь, где сам черт не разберет кто его обрабатывает и сколько там фильтров-драйверов наложено. и CreateFile представляет некую абстракцию реальности
Ну не можно и напрямую на Native API писать, но там уже становится децл неудобно для прикладного уровня.

М> а CRT как бы очень прозрачная абстракция
Которая в итоге приходит в вызовы WinAPI.

М>да и вообще не факт, что вызов fopen дойдет до вызова CreateFile, особенно если мы создаем временный файл и форсированно закрепляем его в памяти (и без изучения исходных текстов CRT мы не может знать как оно отработает в конечном итоге).
Это уже фантазии пошли.

М>но вообще, си представляет свою абстракцию. а каждая ось свою. если достаточно абстракций си -- работаем с ними. если требуются некии гарантии -- создаем свои врапперы. а баги в CRT в fopen маловероятны.
Дык используй на здоровье. Я ж не призываю всех отринуть неверный путь и узреть истинный свет единственно верного API.
Это вроде тебе было непонятно зачем WinAPI нужно когда тебе "даже libc слишком много" (С).

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, мыщъх, Вы писали:

М>>Здравствуйте, Driver, Вы писали:

N>Ну если вспоминать именно CreateFile() с её специфическим стилем, то принципиальная разница от open() в том, что в CreateFile() каждая отдельная характеристика метода открытия вынесена в свой метод, а у open() одна общая битовая маска flags. Второе действительно удобнее в нескольких аспектах — разумно понятное количество аргументов и расширяемость (например, было тривиально добавить O_NOFOLLOW, а покажите мне аналог под Windows), но принципиального различия, мне кажется, нет. Одно в другое переходит.

но ведь open (2) откроет что угодно! а вот в вин -- читать/писать в процессы отдельные АПИ вообще. а зачем? считатывать показание счетчиков производительности -- отдельная библиотека вообще. список процессов получить -- еще одна отдельная либа со своим АПИ. с дуба рухнуть можно. а ведь все это хорошо укладывается в концепцию файлов.

местами АПИ винды выглядит как издевательство. то у нас есть всего четыре (? уже не помню ?) таймера в win 3x, а то у нас есть всего горстка глобальных атомов в современной NT. вопрос -- ну и как мне предполагается использовать атомы для коммуникации между процессами, если ограничение не на процесс, а на всю систему. 27 или сколько их там -- не помню, но что-то очень мало. и что делать если атомы уже кто-то захавал?! вот тебе и многозачная многопользовательская система. т.е. атомы есть, но пользоваться ими можно только в студенческих лабах. а зачем тогда они есть?

N>Про KISS — мне кажется, что любой, кто ценит своё время, будет его использовать;
так ведь делать просто нужно талант иметь и думать головой. с другой стороны... вот предлагал шефу две версии проекта. одна с максимальным использованием всего готового где нашего будет буквально сотня строк кода и что работает тормозно как бронепоезд, но зато универсально, расширяемо, масштабируемо и унифицированно.

другой вариант в тысячи (!) раз быстрее по скрости (~10 ms против нескольких минут), но неуниверсально и придется не только писать хз сколько кода, но и дописывать его постоянно в погоне за прогрессом. я думал, что шеф как мудрый человек выберет второй вариант. шеф как мудрый человек выбрал первый. почему? потому что он проще. и дешевле. латентность в принципе удовлетворяет поставленным требованиям. пропускная способность ни ограничена ничем, только бюджетом на железо. а я еще помню упирался и все доказывал, что мы должны быть элегантными и быстрыми. и что собрать в кучу готовые кубики и стянуть их скотчем ума много не надо...

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

...да тут все зависит от требований к проекту. вот, например, если мы пишем IPS нам нужно в реальном времени успевать делать и детекцию, и анализ. если же наш IPS реально используется как IDS то в реальном времени достаточно выдать хит типа suggestion, а уже в off-line его валидировать и тут уже спешить некуда. в резульате реал-таймовый код становится очень простым, т.к. практически все можно вынести в off-line. но опять -- если слишком сильно увлечься, то мы будет делать хит на каждый пролетающий мимо пакет и чтобы успевать обрабатывать все хиты по мере поступления нам снова потребуется реал-таймовый движок.

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

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

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

Здравствуйте, мыщъх, Вы писали:

N>>Ну если вспоминать именно CreateFile() с её специфическим стилем, то принципиальная разница от open() в том, что в CreateFile() каждая отдельная характеристика метода открытия вынесена в свой метод, а у open() одна общая битовая маска flags. Второе действительно удобнее в нескольких аспектах — разумно понятное количество аргументов и расширяемость (например, было тривиально добавить O_NOFOLLOW, а покажите мне аналог под Windows), но принципиального различия, мне кажется, нет. Одно в другое переходит.
М>но ведь open (2) откроет что угодно! а вот в вин -- читать/писать в процессы отдельные АПИ вообще. а зачем? считатывать показание счетчиков производительности -- отдельная библиотека вообще. список процессов получить -- еще одна отдельная либа со своим АПИ. с дуба рухнуть можно. а ведь все это хорошо укладывается в концепцию файлов.
Ну да, когда в руках молоток — весь мир похож на гвоздь.
Ну и как ты это всё впихаешь в концепцию файлов? Те же обращения к памяти процесса и счётчики.
Я имел сомнительное удовольствие иметь дело с API, в которых, если проводить аналогию с темой этой ветки "процесс как файл": если мы открыли процесс как файи и читаем оттуда по 4 кб то это будет читаться память процесса а если по 123 байта то будет читаться perfcounter.
API этот состоял из буквально пары функций, но использование его напоминало зверское колдунство с кучей magic numbers.
Вот за такие API надо обрывать руки и засовывать в жопу, где им самое место.

По мне так очень хорошо что разные сущности не смешиваются.
Не приходится для них делать special case и generic кода.

М>а то у нас есть всего горстка глобальных атомов в современной NT. вопрос -- ну и как мне предполагается использовать атомы для коммуникации между процессами, если ограничение не на процесс, а на всю систему.
Это говно появилось в 95й винде и уже лет 11 никто в здравом уме их не использует.

М>27 или сколько их там -- не помню, но что-то очень мало.
Если верить MSDN то лимит == 0xFFFF

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

М>...в общем, я пришел к выводу, что простые решения рвут сложные
Ты путаешь простоту решения с решением на готовых кубиках. А шефу твоему походу нужен был работающий продукт и поскорее.

PS. KISS кстати ни разу не означает что надо делать меньше функций в API.

Здравствуйте, Banned by IT, Вы писали:

BBI>Здравствуйте, netch80, Вы писали:

N>>Это не ошибка, это намеренная редукция. Первые линкеры целевой среды поддерживали только 6 символов RADIX-50 в имени, внешние символы получали префикс '_', на собственно имя оставалось 5 символов. Все API имена тех времён не длиннее 5 символов.
BBI>Это как в байке что размеры шаттла зависят от ширины лошадиной задницы в 16м веке?

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

N>>Ну да, и системные вызовы не делаешь?
BBI>Что ты под этим понимаешь?
BBI>В винде libc как и libcp это тупо враппер над WinAPI

Мне непонятно что значит не использовать libc. Винда и только API вызовы, или что-то другое? Под Unix не использовать libc нереально (ну да, есть такие что сами сисколлы под все платформы рисуют, но это же задолбаться можно)

Здравствуйте, disasm, Вы писали:

D>вы забыли основную идею индусского кода — получение прибыли из воздуха

Трэш какой-то. Основная идея индусского кода — это быстрое решение поставленной задачи без размышлений о будущем. То что вы пишете, это совершенно нормальный подход: пока число 3 — это число 3, будет int, как только заказчик говорит, что там кроме числа 3 у него в предметной области бывает ещё строка "fuck", делаем класс — абстрагируемся. Индусский подход в этом случае — не класс сделать, а if написать, переделать код для int в код для string. Получается 2 примерно одинаковых куска кода. Далее выясняется, что заказчику и с числом 3 и со словом "fuck" нужно делать какое-то новое действие: в случае с классом у нас будет всего 1 место (либо 2, но совершенно явных). В случае с индусским подходом будет 2 неявных места.

Здравствуйте, andyag, Вы писали:

A>Здравствуйте, disasm, Вы писали:

D>>вы забыли основную идею индусского кода — получение прибыли из воздуха

A>Трэш какой-то. Основная идея индусского кода — это быстрое решение поставленной задачи без размышлений о будущем.

индуса когда нибудь живого видели?)
а общались с ним? а стояли у него за спиной и смотрели ход его размышлений?
основная цель индусо-кода получение денег за больший обьем кода
много строк чего то = много денежек
зайдите хотя бы в вики и посмотрите как простые конструкции int a = 3; индуссо кодеры усложняют
и только для того что бы увеличить свои гонорары за результат

а то о чем вы говорите это рефакторинг и к даному сабжу он не имеет отношения

кстати ps: я против KISS

Здравствуйте, disasm, Вы писали:

D>Здравствуйте, andyag, Вы писали:

A>>Здравствуйте, disasm, Вы писали:

D>>>вы забыли основную идею индусского кода — получение прибыли из воздуха

A>>Трэш какой-то. Основная идея индусского кода — это быстрое решение поставленной задачи без размышлений о будущем.

D>и только для того что бы увеличить свои гонорары за результат
Это работает ТОЛЬКО в случае, если заказчик платит за строки кода. Мне заказчик уже год платит за то, что кода становится меньше, а фич больше. Я теряю деньги????

D>а то о чем вы говорите это рефакторинг и к даному сабжу он не имеет отношения
Рефакторинг — это любые правки кода, призванные сократить количество вотзефаков в минуту. Рефакторингом вообще многое можно назвать. Я написал именно о мыслях между "поставлена задача" и "задача решена". Использовать классы вместо ифов — это не рефакторинг, это, блин, обычное ООП. А использовать ифы вместо полиморфизма, это классическая индусятина. И совершенно пофигу, по большому счёту, какой там у человека ход мыслей: если он мыслит в базисе процедурного программирования, а при этом пишет на ОО-языке, это просто херовый программист, не подходящий для данного конкретного проекта.

Постулат: "основная проблема разработки корпоративных программных систем" — это управление сложностью. Есть 2 ключевых инструмента для решения этой проблемы: абстракция и разделение обязанностей. Больше ничего нет, в смысле — вообще ничего. Все паттерны, все дипенденси инжекшны — это фигня, это просто конкретика. В процедурном программировании эти инструменты реализуются через много маленьких процедур. В ООП эти инструменты реализуются через интерфейсы и объекты. Индусы славятся именно тем, что нихера не знают "основную проблему разработки корпоративных программных систем", нихера не знают как эта проблема решается и решают её так, как им приходит в голову, благо, голова у них работает хорошо и они реально могут её решить. Только потом это решение хрен кто поймёт.

D>кстати ps: я против KISS
Знаю что такое KISS, но не знаю полное значение. Одна процедура с сотней ифов это кисс? Сотня маленьких классов по 1 ифу в каждом это кисс? Что-то среднее между ними это кисс?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Eugeny__, Вы писали:

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

НС>Любые крайности — неоптимальны.


Согласен. Просто в последнее время слишком уж часто попадается именно переусложнение на пустом месте, просто "потому что это круто". А нужно — "потому что это лучше решает задачу".

Здравствуйте, netch80, Вы писали:

N>Мне непонятно что значит не использовать libc. Винда и только API вызовы, или что-то другое? Под Unix не использовать libc нереально (ну да, есть такие что сами сисколлы под все платформы рисуют, но это же задолбаться можно)
В винде libc/libcp это кусок рантайма, который идёт с прогой. В самой винде есть только WinAPI.

Здравствуйте, мыщъх, Вы писали:

М>>>я за KISS принцип. и мой шеф тоже за него. так что мы нашли друг друга.
N>>Ну если вспоминать именно CreateFile() с её специфическим стилем, то принципиальная разница от open() в том, что в CreateFile() каждая отдельная
N>>Про KISS — мне кажется, что любой, кто ценит своё время, будет его использовать;
М>так ведь делать просто нужно талант иметь и думать головой. с другой стороны... вот предлагал шефу две версии проекта. одна с максимальным использованием всего готового где нашего будет буквально сотня строк кода и что работает тормозно как бронепоезд, но зато универсально, расширяемо, масштабируемо и унифицированно.
М>другой вариант в тысячи (!) раз быстрее по скрости (~10 ms против нескольких минут), но неуниверсально и придется не только писать хз сколько кода, но и дописывать его постоянно в погоне за прогрессом. я думал, что шеф как мудрый человек выберет второй вариант. шеф как мудрый человек выбрал первый. почему? потому что он проще. и дешевле. латентность в принципе удовлетворяет поставленным требованиям. пропускная способность ни ограничена ничем, только бюджетом на железо. а я еще помню упирался и все доказывал, что мы должны быть элегантными и быстрыми. и что собрать в кучу готовые кубики и стянуть их скотчем ума много не надо...
М>...в общем, я пришел к выводу, что простые решения рвут сложные, пусть даже посление очень высокотехнологичные и в теории способы обеспечить любые требования, но на практике все упирается в то, что попытка написать узкоспециализированный код, опережащий уже имеющийся код общего назначения обречена на провал, т.к. по мере расширения требования узкоспециализированный код окажется мертворожденным и его придется практически полностью переписывать.
М>короче, за простые решения потом часто приходится расплачиваться. но сложные решения часто не взлетают.

Ну вот пример типичного "KISS'а" — autotools. Типа как офигено писать "маленькие" тулзы которые стыкуются с друг другом во имя "главной" цели.
Но вы только посмотрите на этот фашизм: http://upload.wikimedia.org/wikipedia/commons/8/84/Autoconf-automake-process.svg
Вот я когда вижу эту картинку, как тут говорят, хочется оторвать руки автору и засунуть куда положено.
С другой стороны есть CMake (для него аналогичная картинка будет содержать только пару действий), он уже не состоит из зоопарка kiss'ов, а сам является непосредственно решателем "главной" цели. И это узкоспециализированное(ну с натяжкой) решение, рвёт солянку autotools по удобству использования, и имхо по скорости.
Я это к тому, что в ряде случаев, усложнить, уйти в узкую специализацию, не вредно, а даже намного полезней kiss'а.