Нужны советы по разработке игр

Здравствуйте,Я давно мечтаю создавать свои онлайн игры, Сейчас освоил базу си, покопавшись в нем понял что игр хороших на нем не слепишь, ни один день скитаюсь по форумам, читаю статьи и Решил. Начну изучать C++. Я знаю что разработка игр это нелегко и мне много чего нужно узнать, Я не знаю с чего начать. Сейчас любой совет на вес золота.
А больше мне нравится кодить и придумывать сценарий. Для моих будущих игр я уже придумал частичто свою историю.
Может это и покажется странным, но когда я смотрю прохождение игр, у меня включается во мне разработчик, и я начинаю думать с точки зрения разработчика. Как какая то механика могла быть реализована в коде.

Вобщем Буду очень благодарен вашим Любым полезным советам!

0

0

Сообщение от COKPOWEHEU С тех пор поменялось и внутреннее устройство операционки, и библиотеки.

С 3.1 ничего существенно не поменялось.

Добавлено через 8 минут

Сообщение от COKPOWEHEU Я примерно это и написал: 10% задач по обработке информации, 90% примитивная автоматизация и формошлепство.

То что примитивом типа формошлепства и веб-хеллоувердов занимается 90% разрабов в индустрии попутно создающие 99% проблем в индустрии, абсолютно ни как не делает эти задачи 90% задач индустрии. Это ровно 1% задач и ровно 1% экономического эффекта индустрии. А то что для этого требуется в 10 раз больше средств чем для остальных 99% задач - ну вот это и говорит о крайней неэффективности срамо-агила.

Добавлено через 2 минуты

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

А вас что в ликбезе не учили что счет нужно обязательно отделять от ввода-вывода, средства которого могут меняться в отличии от предметной области для которой выполняется счет? Или вы и это прогуляли на рекламных пати по срамо-агилу, единственная цель которых - срубить бабаса за входной билет?

Добавлено через 10 минут

Сообщение от COKPOWEHEU Еще раз: все эти проверки нужны не для того чтобы гарантировать отсутствие ошибок (это невозможно), а чтобы снизить их количество.

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

Добавлено через 12 минут

Сообщение от COKPOWEHEU Надеюсь, суть понятна.

Суть в том что думать надо сначала а потом код писать. Тщательнее предметную область анализировать тщательнее. Тогда и граблей таких нет. А разделять на части/очереди реализации нужно только по замкнутым на себя подсистемам которые кроме как форматом входных/выходных данных с другими подсистемами не связаны. К примеру тех же САПР - либо геометрическое ядро сразу универсальный набор примитивов и непротеворичивый набор операций над ними (т.е. в результате любой операции получаются примитивы из того же набора), либо это в общем то не ядро, и реализация проверки геометрических условий применимости операций к примитивам будет гораздо сложнее чем расширение набора до универсального.
А интерфейсы вообще дело десятое. К примеру 75% современных САПР при всем их разнообразии сделаны на одном геометрическом движке. И при этом никто при его разработке никаких демок и т.д. не выпкскал. Там просто хорошо подумали, годик покодили скромной командой из одного единственного доктора наук, и результат сразу начал вытеснять с рынка все остальное.

0

Сообщение от Fulcrum_013 Вот как раз этим слоем и является стандартная библиотека языка. Единственная ее задача - сокрытие различий между апи ОС а не то что туда сейчас принято пихать.

Серьезно? Вы правда не знаете что такое слой абстракции и портируемость? Потому что такую чушь вместо ответа мог написать только тот, кто об этом слышал только краем уха.
Как одной только стандартной библиотекой реализовать доступ к COM-порту? Как открыть канал (pipe), как изменить права доступа к файлу?

Сообщение от Fulcrum_013 таковой является стандартная библиотека языка.

Сообщение от Fulcrum_013 К примеру Банальный анализ общего назначения такой штук и как начерталки сразу выявляет что 2D интерфейс вообще не применим 3D онли.

Чушь. Автокад примером. По сути он двумерный.

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

Программисты TeX с тобой не согласны. Они-то считают что текстовое представление удобно даже для размеченного текста и всякие неотображаемые символы - зло.

Сообщение от Fulcrum_013 Потом опять что то рефакторят в реализации и в этом же месте опять вылазит ошибка. Потому что ветки исполнения поменялись и тест без полной переработки нифига не тестирует.

Ну, если делать как вы, тестируя каждую ветку, то да. А если как люди, тестируя функционал - то нет.

Сообщение от Fulcrum_013 Такое тестирование как вы описываете - лучшая гарантия техногенных катастроф.

Ну конечно, если код не проверять вообще, как советуете вы, катастроф будет куда меньше

Сообщение от Fulcrum_013 С 3.1 ничего существенно не поменялось.

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

Сообщение от Fulcrum_013 То что примитивом типа формошлепства и веб-хеллоувердов занимается 90% разрабов в индустрии попутно создающие 99% проблем в индустрии, абсолютно ни как не делает эти задачи 90% задач индустрии.

То есть количество разработчиков не делает, количество затрачиваемого времени и денег не делает. А что делает?

Сообщение от Fulcrum_013 А вас что в ликбезе не учили что счет нужно обязательно отделять от ввода-вывода

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

Сообщение от Fulcrum_013 Подобное юнит тестирование их только увеличивает. А тем более их плодит во всю написание кода без анализа предметной области и вечные рефакторинги.

Увеличивает? Разве что видимых разработчику. От отсутствия тестирования ошибки никуда не денутся, вот только заметит их не программист, а пользователь.
.
Впрочем, ваши высказывания про способы разработки и тестирования, про переносимость, модульную разработку, теорию и практику разработки уже сказали достаточно о вашем уровне. Засим не буду отвлекать от сбора требований и теоретического материала для вашей игры. Которую вы, разумеется, будете делать без тестирования, на основе универсальных безглючных библиотек... точнее, стандартной Си-шной библиотеки, ведь остальное - ересь... Которая будет прекрасно компилироваться под все известные человечеству операционные системы от суперкомпьютеров до RTOS в стиральной машине. Когда... если доделаете, выложите хотя бы демку полюбоваться на результат самого лучшего подхода к разработке.

0

Сообщение от COKPOWEHEU Надеюсь, суть понятна.

Суть в том что думать надо сначала а потом код писать. Тщательнее предметную область анализировать тщательнее. Тогда и граблей таких нет. А разделять на части/очереди реализации нужно только по замкнутым на себя подсистемам которые кроме как форматом входных/выходных данных с другими подсистемами не связаны. К примеру тех же САПР - либо геометрическое ядро сразу универсальный набор примитивов и непротеворичивый набор операций над ними (т.е. в результате любой операции получаются примитивы из того же набора), либо это в общем то не ядро, и реализация проверки геометрических условий применимости операций к примитивам будет гораздо сложнее чем расширение набора до универсального.
А интерфейсы пользователя вообще дело десятое. К примеру 75% современных САПР при всем их разнообразии сделаны на одном геометрическом движке. И при этом никто при его разработке никаких демок и т.д. не выпкскал. Там просто хорошо подумали, годик покодили скромной командой из одного единственного доктора наук, и результат сразу начал вытеснять с рынка все остальное. При этом главный фишкан из за которого оно вынесло все был даже не в том что система счета позволяла перейти к революционному в плане удобства интерфейсу с лентой редактирования позволяющей изменять параметры предыдущих команд, а не только откатывать,
моделированием от 3D, и автоматическим/полуавтоматическим построением чертежей из 3D модели, а в первую очередь благодаря универсальному формату хранения геометрии построенных моделей, позволяющему обмениваться готовыми моделями между любыми САПР сделанными на этом движке, и при этом дальнейшее редактирование типа сверления отверстий по месту сборки и т.д. делать уже в том САПР в который модель импортирована.
Вот вам и универсальный набор кирпичиков (примитивов и опреаций над ними) для описания моделей,без которого создание такого функционала в принципе невозможно.

Добавлено через 2 минуты

Сообщение от COKPOWEHEU Вот только о том, что работают они только для сферического коня в вакууме, забываете

Ну в таком случае любой софт и есть сферический конь в вакууме.

Добавлено через 5 минут

Сообщение от COKPOWEHEU Увеличивает? Разве что видимых разработчику.

Да вот ничего подобного. Корректность тестов ничем не гарантирована. При этом дает ложную уверенность что функция прошедшая тест работает корректно. Особенно это касается случаев с рефакторингом реализации изменяющим ветки выполнения под капотом функции, равно как и с набором тестов тестирующим не все возможные ветки выполнения и не все варианты внутреннего состояния приводящего к смене выбранной ветки (что в общем случае вообще не возможно). Такое тестирование только скрывает ошибки. А соответственно как раз увеличивает вероятность того что баг попадет к пользователю.

Добавлено через 25 минут

Сообщение от COKPOWEHEU От отсутствия тестирования ошибки никуда не денутся, вот только заметит их не программист,

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

Добавлено через 14 минут

Сообщение от COKPOWEHEU Чушь. Автокад примером. По сути он двумерный.

И при этом он по факту умер. Живет только на том что огромное количество чертежей было создано до появления трехмерных САПР твердотельного моделирования, и на том что в сам автокад кое какое 3D таки прикрутили и съехал он в нишу low-end средств еще 90-х

Добавлено через 2 минуты

Сообщение от COKPOWEHEU ак одной только стандартной библиотекой реализовать доступ к COM-порту?

Он типа не разу не файл?

0

Сообщение от Fulcrum_013 Суть в том что думать надо сначала а потом код писать. Тщательнее предметную область анализировать тщательнее. Тогда и граблей таких нет.

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

Сообщение от Fulcrum_013 При этом дает ложную уверенность что функция прошедшая тест работает корректно.

Ничего подобного. Она говорит что функция, скорее всего, работает не хуже чем раньше.
Впрочем, чисто из любопытства - какую альтернативу вы предлагаете? Вот есть у нас функция, жестко завязанная на winapi, для определенности пусть будет создание канала. Канал штука платформо-зависимая и в стандартной библиотеке этого все равно нет. И надо эту функцию портировать на Linux. Каким образом вы проверите ее работоспособность?

Сообщение от Fulcrum_013 А вот толковая декомпозиция основанная на детальном анализе предметной области

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

Сообщение от Fulcrum_013 минимизирует саму возможность допущения ошибки

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

Сообщение от Fulcrum_013 А юнит-тесты для нее когда нибудь прогоняли или хотя бы видели?

Точно сказать не могу, но вот это не близко?

Добавлено через 6 минут

Сообщение от Fulcrum_013 Он типа не разу не файл?

Сюрприз!
Вообще-то, это набор портов для записи и чтения. Для COM1 они расположены по адресам 0x3F8, 0x3F9. И именно так он выглядит для ядра ОС, и именно так его программировали до winNT. И точно так же (с учетом другого назначения портов) это делается в микроконтроллерах. Это современные ОС могут отображать его на файл, но не обязаны. Да и как вы через "чистый файл" будете задавать скорость работы, контроль четности и т.п.?

0

Сообщение от COKPOWEHEU Точно сказать не могу, но вот это не близко?

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

Добавлено через 24 минуты

Сообщение от COKPOWEHEU И именно так он выглядит для ядра ОС, и именно так его программировали до winNT

Да как бы туда и 95-я не пустит туда точно так же. Это только для жителей 0-го кольца можно.

Сообщение от COKPOWEHEU Это современные ОС могут отображать его на файл, но не обязаны.

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

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

Сообщение от COKPOWEHEU Да и как вы через "чистый файл" будете задавать скорость работы, контроль четности и т.п.?

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

Добавлено через 10 минут

Сообщение от COKPOWEHEU Толковая декомпозиция возможно только после использования на практике

Без толковой декомпозиции до использования на практике оно просто не доедет. А если и доедет то проще будет переписать с нуля на основе анализа чем отладить.

Добавлено через 1 минуту

Сообщение от COKPOWEHEU Она говорит что функция, скорее всего, работает не хуже чем раньше.

На каком основании он вообще может это говорить если набор веток выполнения под капотом функции полностью поменялся так же как и набор состояний приводящих к выбору разных веток?

Добавлено через 13 минут

Сообщение от COKPOWEHEU Каким образом вы проверите ее работоспособность?

Сообщение от COKPOWEHEU Но не до нуля, так что хоть какое-то тестирование по прежнему желательно.

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

Добавлено через 1 минуту

Сообщение от COKPOWEHEU Одной теории не хватит

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

Добавлено через 15 минут

Сообщение от COKPOWEHEU Канал штука платформо-зависимая и в стандартной библиотеке этого все равно нет.

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

Сообщение от COKPOWEHEU И надо эту функцию портировать на Linux. Каким образом вы проверите ее работоспособность?

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

0

Сообщение от Fulcrum_013 Да как бы туда и 95-я не пустит туда точно так же.

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

Сообщение от Fulcrum_013 Потому что верно товарищ Томпсон в свое время подметил что любое устройство ввода-вывода вне зависимости от его физической конструкции можно предстваить как поток.

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

Сообщение от Fulcrum_013 Вот как раз через хендл файла все это в виндах и задается. Функции все это устанавливающие аккурат к нему применимы

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

Сообщение от Fulcrum_013 И вот как раз унифицированным оборачиванием всего этого и должна заниматься стандартная библиотека в первую очередь

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

Сообщение от Fulcrum_013 А если и доедет то проще будет переписать с нуля на основе анализа чем отладить.

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

Сообщение от Fulcrum_013 На каком основании он вообще может это говорить если набор веток выполнения под капотом функции полностью поменялся так же как и набор состояний приводящих к выбору разных веток?

На том, что проверяется функция, а не ее ветки, разумеется.

Сообщение от Fulcrum_013 Использование ее в куче кода и проверка нештатных ситуаций под ее капотом типа не дают больше чем тесты?

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

Сообщение от Fulcrum_013 Оно хотя бы полностью покрывает все ветки выполнения и гарантированно перерабатывается вместе с реализацией ежели чего.

И именно поэтому в смысле тестирования совершенно бесполезно. Поскольку результат работы не с чем сравнивать.

Сообщение от Fulcrum_013 Теория она в том чтобы анализ детальный проводить до написания кода и объясняет почему кодить до аналлиза бесполезно. А сам анализ и т.п. - это и есть самая что ни на есть практика.

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

Добавлено через 7 минут

Сообщение от Fulcrum_013 Не важно есть или нет но стандартные библотеке, либы даже стандартные

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

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

...если кроссплатформенность планировалась изначально. А это редкость.

Сообщение от Fulcrum_013 Ну точно не юнит-тестами. еще не хватало еще для полноты счасть юнит-тесты на обертки функций апи лепить. Открыла вернула дескриптор. Не открыла -выбросила исключение. Там тестировать вообще нечего то по большому счету потому что результат ее работы в конкретной цифери выразить нельзя.

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

0

Сообщение от COKPOWEHEU Практика это реализация.

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

Добавлено через 5 минут

Сообщение от COKPOWEHEU А это редкость.

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

Добавлено через 3 минуты

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

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

Добавлено через 2 минуты

Сообщение от COKPOWEHEU Поскольку результат работы не с чем сравнивать.

Как это не с чем? Со списком кодов ошибок возвращаемой функцией API. Сразу и место и причину показывает. А как результат позволяет по стеку вызовов отследить кто именно туда некорректные данные передал. Юнит-тестирование в этом плане абсолютно бесполезно. Хотя бы потому что работает извне и места возникновения ошибки занть не может.

0

парень, скорее всего, хочет создавать far cry'и, gta'шки, god of war'ы, а не онлайн змейки в браузере

0

Сообщение от COKPOWEHEU Все это прекрасно тестируется автоматически.

Все это прекрасно пишется один раз и на века.

Добавлено через 2 минуты

Сообщение от COKPOWEHEU Но все это останется теорией, пока не будет проверено на реальном коде.

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

Добавлено через 8 минут

Сообщение от kusancho парень, скорее всего, хочет создавать far cry'и, gta'шки, god of war'ы, а не онлайн змейки в браузере

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

0

Сообщение от Fulcrum_013 Это бытность любой вменяемой разработки.

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

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

Вся работа с каналом, естественно. Мы же говорим про модуль, а не про конкретную функцию.

Сообщение от Fulcrum_013 Как это не с чем? Со списком кодов ошибок возвращаемой функцией API. Сразу и место и причину показывает.

Обычно показывает либо "не удалось открыть", либо "успешно передано / принято". Что толку с таких результатов.

Сообщение от Fulcrum_013 Юнит-тестирование в этом плане абсолютно бесполезно. Хотя бы потому что работает извне и места возникновения ошибки занть не может.

Еще раз: оно и не должно точно указывать место возникновения ошибки.

Сообщение от Fulcrum_013 Все это прекрасно пишется один раз и на века.

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

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

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

0

Сообщение от Fulcrum_013 Все это прекрасно пишется один раз и на века.

Увы. Даже такие простейшие вещи как io-обертки со временем приходиться править. Даже такая "мелочь", как переход на 64битный off_t заставляет лезть в старинные коды.
Или вот живой пример с этого форума: https://www.cyberforum.ru/c-li... 70090.html вы же не застрахованы от того, что какой-то добрый человек из апстрима стандартной библиотеки переводя с mmap на malloc файловые буфера на полуживой платформе сломает ваш прекрасный фреймворк. А тесты словили б такое сразу...

0

Сообщение от COKPOWEHEU Обычно показывает либо "не удалось открыть", либо "успешно передано / принято". Что толку с таких результатов.

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

Добавлено через 3 минуты

Сообщение от COKPOWEHEU Но как это опровергает мое высказывание о том, что одной теории недостаточно для написания программы?

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

Добавлено через 19 минут
[

Сообщение от prik Даже такая "мелочь", как переход на 64битный заставляет лезть в старинные коды.

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

Сообщение от prik А тесты словили б такое сразу...

Каким образом? Переработка реализации требует и полной переработки тестов. Либо тестируется каждая подкапотная ветка выполнения либо оно вообще ничего не тестирует.

Сообщение от COKPOWEHEU Еще раз: оно и не должно точно указывать место возникновения ошибки.

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

Добавлено через 3 минуты

Сообщение от COKPOWEHEU Вся работа с каналом, естественно

Каким боком подсистема буферов вообще от функций отдачи оных буферов самому каналу зависит? Буфера отдельно их передача оси отдельно. И все пучком.

Добавлено через 3 минуты

Сообщение от COKPOWEHEU Вся работа с каналом, естественно

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

Добавлено через 3 минуты

Сообщение от COKPOWEHEU Вот только требования меняются и пример я привел

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

Добавлено через 5 минут

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

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

Добавлено через 9 минут

Сообщение от COKPOWEHEU На том, что проверяется функция, а не ее ветки, разумеется.

Ну дак проверка функции это и есть проверка всех возможных вариантов ее работы. Или вы под этим что то другое подразумеваете?

0

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

Конкретно с off_t да. Но таких примеров у меня есть еще.

Сообщение от Fulcrum_013 Опять же это вопросы стандартной бибилиотеки а не конкретной проги.

Если вас не коснулось - хорошо. Мне же пришлось править все наследство находящиеся в моем ведение по работу с большим файлами.

Сообщение от Fulcrum_013 Каким образом?

Как вы и говорите - бранч тесты в прикладухе, для самой библиотеки хватило бы и юнитов (наверное).

Сообщение от Fulcrum_013 еще с POSIX едет где не то что набор параметров, а номер под которым та или иная функция экспортируется жестко задан.

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

0

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

Добавлено через 19 минут

Сообщение от COKPOWEHEU Насколько я помню, с сетью такое не прокатывает.

И чем она отличается? Та же сериализация/десериализация при приеме отправке.

Добавлено через 5 минут

Сообщение от prik для самой библиотеки хватило бы и юнитов (наверное).

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

Добавлено через 25 минут

Сообщение от prik Вообще такое ощущение, что спор идет о том сколько думать нужно перед тем как трясти начинать...

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

0

Сообщение от Fulcrum_013 И чем она отличается? Та же сериализация/десериализация при приеме отправке.

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

Сообщение от Fulcrum_013 А она чем отличается то? Эта срань в плане надежности еще критичней.

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

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

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

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

Ну как минимум ребята с SQLIte с вами не согласны.

Добавлено через 11 минут

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

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

0

Сообщение от COKPOWEHEU Для этого есть сторонние библиотеки, зачастую кросслатформенные, которые создают именно слой абстракции.

Вообще то именно это исходное и главное предназначение стандартной библиотеки - обеспечить переносимость между платформами путем перекомпиляции, и этот слой абстракции как раз и должна занимать именно стандартная библиотека.
Что сделать абсолютно реально.
А то во что их сейчас превратили стандартные библиотеки - это вообще результат чрезмерного и ненужного увлечения нишевыми скриптами, не пригодными для написания на них эффективных библиотек даже базовых стркуткур данных для себя самих. При этом вездеходом подобные скрипты стать не могут априори. Основная то проблема мультиплатформы как раз в различиях в оконном апи современных осей, а не в различиях процов которые банально перекомпиляцией или докомпиляцией из промежуточного представления в машкод еще в 70-х нивелировать научились.
И библиотеки таких базовых структур данных на все случаи жизни типа сделать искоробочными - ну тоже малореально. Требования к их реализации у разных случаев жизни очень уж противоречивы. Хотя для плюсов почти абсолютную настраиваемость поиметь реально. Но если это и делать то начинать нужно со стандартизации бинарных форматов буферов и т.п. Иначе промеж dll и прочими вариантами либ как пихали сишные строки и массивы через сырые указатели так и будут пихать. А сама stl из средства для топ-разрабов все больше и больше превращается в средство защиты даже не от дурака, а от полного идиота. Взять те же счетчики которые без вариантов атомарные. На кой спрашивается без вариантов атомарные, если и ежу понятно что параллелить надо или в режиме разделения ресурсов или в другом месте, а как результат и счетчиков атомарных нужно подавляющее меньшинство и то в исключительных случаях?

Добавлено через 3 часа 34 минуты

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

Ага было дело - как то просили заменить перделку на ПЕРДЕЛКУ, потому как если на дежурстве вместо того чтобы бдеть в машзале дрыхнуть в архиве без задних ног с закрытой дверью, сигналов тревоги нихрена не слышно. Электроники которые тоже на ночных дежурствах дрыхли там же в результате с этим справились прекрасно и без всякого рефакторинга. Там в этом плане полиморфизм врожденным оказался и гудок от белаза на разъем pc-speakera подключился как родной после небольшого шаманства с оберткой в виде простейшего усилка
А как то просили рабочий стол виндоузы заменить своей прогой так чтобы кроме нее вооще ниче не запускалось и оффисный планктон на работе пасьянвы не раскладывал. Ну это как бы не прогу рефакторить надо было а самую малость реестр чтобы вместо эксплорера запустится и присобачить небольшой лаунчер который следил чтобы ничего другого открыть нельзя было включая диспетчер задач.
Ну а если серьезно то ли мне такие задачи попадались то ли хрен его, но общая суть сводилась к тому чтобы заменить всего один элемент системы - а именно прокладку между стулом и клавиатурой на что нибудь более адекватное. Хотя были и немного другого характера - заменить комп шкафного базирования на современный, при условии что исходники давно потерялись а те кто их писал давно умерли, но так чтобы при этом убиенные зайцы лежали в тех же местах и в тех же позах. Изводить кротов и даже мамонтов при этом тоже никак не запрещалось.
Ну а если совсем по наукам и теориям то в общем то никто кроме разраба не знает что вообще и где нужно делать а тем более менять. А на практике всем включая заказчика сугубо пофигу каким образом оно работает главное чтобы оно делало то что нужно. При этом заказчика и т.п. колыхает только результат. А именно сколько прокладок между стулом и клавиатурой оный софт заменяет. И как сделать эту циферь побольше никто кроме разраба который анализировал предметную область не знает в принципе. Так что просить что то переделать во первых особо и не кому а во вторых особо и нечего. А в главных там где не справляется заклинание "настройки" избежать рефакторинга и отделаться только расширением номенклатуры очень сильно помогает заклинание "полиморфизм". Хотя опять же во многих предметных областях набор сущностей и механизмов взаимодействий между ними которые которые видны/управляемы юзверем четко ограничен логикой предметной области и ни добавить ни убрать ничего нельзя в принципе.

Добавлено через 11 часов 1 минуту

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

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

Сообщение от prik Как я понимаю, речь о том, что беркли сокеты несмогли полностью подвести под файловый интерфейс,

Ну UDP под него

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

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

0

Сообщение от Fulcrum_013 Ага. Типа взяли и предметную область заменили. Ну так же не бывает.

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

Сообщение от Fulcrum_013 То так сводили. При этом в подавляющем большинстве случаев все это делалось по принципу делаем из TCP стрим (которым он в итоге и есть) а лоховской UDP реальным пацанам нафиг не тарахтел. Если же при этом смотреть на UDP как на просто другой тип стрима - а именно просто стрим с порядком байт таким в котором они поступают в сетевуху то все совсем по другому. Другое дело что у него совсем другой и гораздо более редкий юсе-кейс чем у TCP-стрима, но именно поэтому TCP поверх UDP и изобрели. То же самое в принципе касается и режимов sctp. А особенно многоканального режима который полностью соответствует многопоточному файлу, чего в TCP еще нету.

Прочитал три раза, но так и не смог понять, что вы хотели этим потоком сознания донести.
Банальные AF_UNIX сокеты под которые собственно и рожали концепт беркли сокетов, не смогли полностью подвести под файловый интерфейс. Причем тут TCP и UDP? Причем тут похожесть (именно похожесть, не соответствие) SCTP на многопоточный файл? С таким же успехом можно сравнивать с ныне почившим концептом STREAMS из "настоящих" юниксов, который кстати тоже не укладывался полностью под файловый интерфейс. Сейчас наверное можно было бы полностью подвести сокеты под файл аля FUSE "/socket/host/port/proto/mode", но как сложилось так и повелось. А ведь кроме упомянутых уже com-портов(tty) и сокетов еще достаточно много IPC сущностей занимающихся передачей данных и не вписывающихся под файловый интерфейс. И нужна ли для них стандартная унифицирующая обертка или пусть все остается как есть.
Касательно тех же сокетов большинству нужна библиотека реализующая простейший (ныне обычно HTTP) клиент, а не сокеты как таковые. А оставшееся меньшинство разберется и с тем как оно есть сейчас. Зачем же плодить новые сущности в стандартных библиотеках, тем более часть этих библиотек должна жить и в free-standing средах.

0

Сообщение от prik Касательно тех же сокетов большинству нужна библиотека реализующая простейший (ныне обычно HTTP) клиент, а не сокеты как таковые.

Именно поэтому наверное весь веб на web-сокеты переселяется. Да и HTTP 2.0 он как бы совсем не такой как 1,1 то бишь многопоточный.

Сообщение от prik и сокетов еще достаточно много IPC сущностей занимающихся передачей данных и не вписывающихся под файловый интерфейс

Ну как бы файлы не есть тождественно равны потокам. Это тоже как бы поток со своими подкапотными ньюансами в принципе расширяющими определение абстрактного потока в сферическом вакууме. Поэтому и сводятся оно все к интерфейсу потока а не к интерфейсу именно файла.

Добавлено через 7 минут

Сообщение от prik Зачем же плодить новые сущности в стандартных библиотеках, тем более часть этих библиотек должна жить и в free-standing средах.

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

Сообщение от prik Касательно тех же сокетов большинству нужна библиотека реализующая простейший (ныне обычно HTTP) клиент

Большинству кого? Большинству задач индустрии как раз нужны голые сокеты и т.п. на которых работают свои кастомные протоколы. А то что работает на HTTP это не более 1% задач индустрии.

0

Сообщение от Fulcrum_013 Да и HTTP 2.0 он как бы совсем не такой как 1,1 то бишь многопоточный.

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

Сообщение от Fulcrum_013 Поэтому и сводятся оно все к интерфейсу потока а не к интерфейсу именно файла.

Если речь про базовые операции, типа запихать/прочитать поток (т.е. в итоге применить системные файловые read()/write() к потоку), то наверное ДА, но и то с кучей оговорок для конкретных сущностей.

Сообщение от Fulcrum_013 Чтобы переход на другую платформу требовал только перекомпиляции.

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

Сообщение от Fulcrum_013 При этом как бе что-что а средства сетевой связи они в общем то имеют один и тот же интерфейс во всех осях с мелкими нтюансами касающимися способов коммуникации с дровами сетевухи

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

Сообщение от Fulcrum_013 А в общем они одинаковы

Смотря, что и как вы используете. Например ели ваша цель максимальная производительность, то даже такая банальность как раскидать клиентов по воркерам (кто и как будет делать accept) в разных (хоть и близко родственных) ОС решается по разному. Т.е. Не смотря на схожесть, за исключением действительно мелких деталей (например в чем измеряется таймаут, или поведение при SO_*LOWAT отличном от 1, или что будет с таймером при выходе из select) приходиться жертвовать либо переносимостью (например под *win серверный код мы не пишем, а остальное легче переносится) либо скоростью (слава богу, что разница в единицы процентов) либо фактически писать под каждую платформу руками порой вынужденно забивая на местные вкусности в угоду хоть какой-то универсальности (пример: SO_SPLICE vs splice()).

Сообщение от Fulcrum_013 . А то что работает на HTTP это не более 1% задач индустрии.

Вы забыли сказать, что этот 1% (я бы оценил в 5%) занимают 90+% объема этой самой индустрии и по количеству кода и по числу занятых. Какой-то части из этого 1% хватает буст.асинк, еще кто-то давно свалил из cpp на ерланг или еще куда, кому то переносимость кроме как за пределы своей ОС вообще не нужна, а оставшиеся действительно справятся сами.
Но к тому что появиться, а что нет в стандартных библиотеках это имеет мало отношения, тут больше влияет кто именно в комитете сидит. опять же это имхо.

0