Вычислить значение функции

Приветсвую , прошу помощи в написании кода.
Задача несложная , математическая.
На языке QBASIC.

Вычислить значения функции Y = x2 - 5 для x [-2; 26], шаг h = 2. Если среди значений Y есть число, равное a, то вычислить сумму всех значений Y, в противном случае вывести на печать значение "111" (Вычисления выполнять для a = 95).

0

Сообщение от Quiet Snow INCLUDE автоматически лепит из пачки файлов один в памяти.

Да, есть такой подход, называется «header-only библиотека».

Недостатки:
1. Изменился только один включаемый файл — но компилятор перекомпилирует весь проект, это медленнее, чем при раздельной компиляции.
2. Необходимо включать файлы в правильном порядке и вручную разруливать зависимости. Вполне может быть, что файл Foo.bas ссылается на сущности из файла Bar.bas, а Bar.bas ссылается на сущности из Foo.bas. Это решается введением общих интерфейсов, но ООП здесь принято ненавидеть и стремиться уничтожать.
3. Чехарда с предварительным объявлением функций. Где‐то будет требоваться Declare, потому что тело функции ниже по коду, а где‐то он будет мешать, потому что выскочит «Complier error — Duplicated Definition».
4. Конфликты имён переменных уровня модуля, так как теперь такие переменные все висят в одном модуле и из локальных превращаются в глобальные.
5. То же самое про функции. Например, функция GetBytes из модуля MemoryBuffer будет конфликтовать с функцией GetBytes из модуля FileBuffer.
6. Затрудено независимое тестирование отдельных модулей и классов.
7. Отладка усложнена, потому что не виден настоящий номер строки кода.

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

1

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

1) Это БЫСТРЕЕ, чем когда у тебя около 100 модулей которые подключают сотни тысяч строк кода подлежащих
компиляции.

2) ONCE - уберегает от ручного разруливания. Ещё есть #ifndef тоже классная штука. Но я предпочитаю
не полагаться на случай и вести ревизию всех имён функций и процедур.
В QB кстати делалось иначе - сначала подключались файлы с константами и декларациями(.dec),
потом с массивами(.bi) и только потом с кодом (.bas)

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

Сообщение от Замабувараев Вполне может быть, что файл Foo.bas ссылается на сущности из файла Bar.bas, а Bar.bas ссылается на сущности из Foo.bas.

Это ситуация слабой продуманности архитектуры.

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

4) Ни разу не испытывал конфликты даже при массовом использовании глобалок, но в данном случае
помогает NAMESPACE и массовое заворачивание функционала в процедуры\функции.

5)

Сообщение от Замабувараев 5. То же самое про функции. Например, функция GetBytes из модуля MemoryBuffer будет конфликтовать с функцией GetBytes из модуля FileBuffer.

Неймспейсы, либо переименовывание.

6)

Сообщение от Замабувараев 6. Затрудено независимое тестирование отдельных модулей и классов.

Если всё делать правильно и используется разделение: API программы \ движок. А архитектура
проработана заранее - нет вообще никаких проблем.

7)

Сообщение от Замабувараев 7. Отладка усложнена, потому что не виден настоящий номер строки кода.

Мой принцип: Нет отладки - нет проблем. Чистота чисто тайд, вы ещё отлаживаете? - тогда мы идём к вам!
Но вообще нормальный отладчик должен показывать и модуль(файл) и номер строки.

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

Сообщение от Замабувараев ArrayStringWriter.bas - записывает строки и числа в буфер AsyncResult.bas - результат асинхронной операции, почти футура ClientRequest.bas - заголовки запроса клиента ClientUri.bas — URI из запроса CreateInstance.bas — фабрика классов FileBuffer.bas — отображённый в память файл, который нужно отправить клиенту HeapBSTR.bas — строка по типу BSTR в приватной куче памяти HeapMemoryAllocator.bas — менеджер памяти на приватной куче HttpGetProcessor.bas — обработчик запросов типа GET и HEAD HttpProcessorCollection.bas — коллекция обработчиков запроса HttpReader.bas — читатель клиентского запроса HttpWriter.bas — записыватель серверного ответа клиенту MemoryBuffer.bas — байты в памяти, который нужно отправлять клиенту NetworkStream.bas — сокетный поток, откуда идёт чтение и запись клиентских и серверных данных ReadRequestAsyncTask.bas — асинхронная задача чтения клиентского запроса, сервер запускает задачу чтения, которая обрабатывается пулом потоков ServerResponse.bas — заголовки ответа клиенту ThreadPool.bas — пул потоков, обрабатывает асинхронные задачи WebServer.bas — принимает соединения с клиента и ставит задачи в очередь на исполнение пулу потоков WebServerIniConfiguration.bas — чтение конфигурации WebSite.bas — вебсайт WebSiteCollection.bas — коллекция сайтов WriteErrorAsyncTask.bas — асинхронная задача отправки ошибочного ответа клиенту WriteResponseAsyncTask.bas — асинхронная задача отправки ответа обработчика HTTP‐запроса клиенту

Слишком большая декомпозиция API. Если слишком много сфер влияния, ну сделать 1 файл Main_API
и разбить остальное на сферы влияния, 3-4. Всё что работает с сетевыми функциями - в одно место,
всё что работает с данными и их форматами - в другое место и т.п. Слишком много сфер влияния,
тебе тяжело обслуживать этот код, рано или поздно ты просто забьёшь его обслуживать, т.к. слишком
сложно из-за как раз подобной стратегии декомпозиции.
Например явная мелочёвка HeapBSTR.bas, WebServerIniConfiguration.bas и наверное там ещё подобного хватает.

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

Сообщение от Замабувараев Сейчас работает старая версия, но там подход «каждому клиенту отдельный поток»

Я видел графики по ускорению на более 10000 клиентов. Будет интересно увидеть реальные тесты.
Мне просто не совсем понятно как это вообще тестировать. Есть какие-то сервисы специальные?

1

Сообщение от Quiet Snow 1) Это БЫСТРЕЕ, чем когда у тебя около 100 модулей которые подключают сотни тысяч строк кода подлежащих компиляции.

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

Сообщение от Quiet Snow Неймспейсы, либо переименовывание

Тогда не получится иметь единый независимый от реализации интерфейс.

Сообщение от Quiet Snow Это ситуация слабой продуманности архитектуры.

Простой пример: задача чтения клиентского запроса ReadRequestAsyncTask должна прочитать запрос, создать и запустить задачу отправки серверного ответа клиенту WriteResponseAsyncTask. После того, как задача WriteResponseAsyncTask отправила все серверные данные, она должна создать задачу чтения запроса клиента ReadRequestAsyncTask. У меня получается, что две сущности ссылаются друг на друга.
А как следовало бы решить проблему «чтение → обработка → отправка → снова чтение → …» без ссылки друг на друга двух задач?

Сообщение от Quiet Snow Мой принцип: Нет отладки - нет проблем. Чистота чисто тайд, вы ещё отлаживаете? - тогда мы идём к вам!

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

1

Сообщение от Замабувараев А как следовало бы решить проблему «чтение → обработка → отправка → снова чтение → …» без ссылки друг на друга двух задач?

Я в серверах и сетях "ни в зуб ногой". И зная тот факт, что архитектура не проектируется исходя из
одной обособленной подзадачи, очевидно, не смогу ответить что надо сделать конкретно тут.
Все советы которые могу дать - только глобального характера.
Более того асинхронные операции означают наличие коллбеков(высокоуровневых аналогов прерываний),
построение модели данных при этом идет следующим образом - коллбеки лежат функциями
и сгружают данные последовательно, при этом должна быть обеспечена блокировка вызова остальных
коллбеков работающих с данными(в 1 момент времени выполняется только один).
Далее должен быть движок(конвеер), который занимается обработкой всех полученных данных и формировкой
отправляемых. Если нам важен отклик - то можно использовать таймер с большой частотой, если не особо
важен(упор на кол-во запросов) - можно использовать поток со sleep-ом. Коллбеки в этом случае должны
фиксировать кол-во полученных и отправленных данных, конвеер должен проверять эти значения
и действовать соответствующим целевой задаче образом.
И да любые попытки вызвать из коллбеков сразу конвеер - это жопа, даже если есть способы сделать
нормальную синхронизацию.
Всё это очень грубо и всё равно без знания конкретной предметной области не даёт ничего.

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

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

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

1

Сообщение от Quiet Snow Слишком большая декомпозиция API. Если слишком много сфер влияния, ну сделать 1 файл Main_API и разбить остальное на сферы влияния, 3-4. Всё что работает с сетевыми функциями - в одно место, всё что работает с данными и их форматами - в другое место и т.п.

Вот как оно работает.

Вебсервер принимает соединение, создаёт класс NetworkStream (унаследованный от IBaseStream) для чтения‐записи данных и ставит задачу пулу потоков в обработку. Что происходит дальше — это уже WebServer волновать не должно.
HttpReader читает клиентский запрос, но не непосредственно из сокета, а дёргает интерфейс IBaseStream. Казалось бы, почему не читать прямо из сокета? Всё будет хорошо, когда у нас только сокет. А когда надо читать зашифрованный поток типа SSL или TLS, тогда придётся делать Select Case от флага как правильно читать и какие функции чтения вызывать: сокетные или SLL. А так HttpReader просто дёргает общий интерфейс IBaseStream, как оно там реализовано — его волновать не должно.

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

Когда ClientRequest справился с парсингом заголовков — задача чтения запроса завершена. Настало время задачи формирования ответа клиенту. Создаётся задача записи ответа клиенту, а задача чтения больше не нужна и уничтожается.

Ответ клиенту состоит из заголовков и тела. Тело ответа может быть в файле, может формироваться динамически или приходить из другой сети. Это всё задачу не волнует, задача лишь дёргает общий интерфейс IBuffer, который умеет выдавать порцию данных по запросу. Задача записи берёт эту порцию данных и отправляет клиенту, но не непосредственно в сокет, а тоже через интерфейс IBaseStream, под которым может скрываться обычный соект, а может и SSL или TLS.

Пул потоков вообще не знает что за задачи он выполняет, какие там байты пишутся и читаются, откуда они берутся и куда уходют. Он просто обрабатывает задачи, как оно реализовано — на его работу это не влияет. Потому что пуол потоков только дёргает общий интерфейс IAsyncTask, от которого унаследованы все задачи.

Сообщение от Quiet Snow Например явная мелочёвка HeapBSTR.bas, WebServerIniConfiguration.bas и наверное там ещё подобного хватает.

Строки в приватной куче памяти HeapBSTR — это важно. Потому что общая куча памяти всегда использует межпоточную синхронизацию на создание и уничтожение памяти, в эти моменты программа превращается в однопоточную. Приватная же куча памяти может работать независимо от других потоков, и синхронизация не требуется. Это конечно выигрыш в тысячные доли тактов процессора, но даже такой выигрыш упускать не хочу.
Насчёт WebServerIniConfiguration — это конкретная реализация класса, который читает конфигурацию сервера формате INI‐файлов. Потому что чтение конфиругации — это не задача вебсервера, эти функции вынесены в отдельный класс, конфигурацию можно и через командную строку получать, вебсервер это волновать не должно.

Сообщение от Quiet Snow Более того асинхронные операции означают наличие коллбеков(высокоуровневых аналогов прерываний)

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

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

Этим всем занимается порт завершения ввода‐вывода.

Сообщение от Quiet Snow Если нам важен отклик - то можно использовать таймер с большой частотой

Таймер — ни в коем случае! Для высоконагруженных систем следует использовать порт завершения ввода‐вывода.

Сообщение от Quiet Snow И да любые попытки вызвать из коллбеков сразу конвеер - это жопа, даже если есть способы сделать нормальную синхронизацию.

Это допустимо для перекрывающихся операций.

1

Сообщение от Замабувараев Таймер — ни в коем случае! Для высоконагруженных систем следует использовать порт завершения ввода‐вывода.

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

Добавлено через 5 минут
Замабувараев, ты пытаешься мне объяснить "на пальцах" то, что нужно вдумчиво и кропотливо
изучать не один месяц и с кучей документации в зубах. Я это всё равно так с ходу не распедрю. Да и
не хочу себе бошку забивать, это не моя задача.

0

Сообщение от Замабувараев Ну а make за три секунды справилась со ста тысячами строк.

Вы же написали что это ориентировочное число строк.
Да и какая разница будет собран проект за секунду или за 0.98 секунд?

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

При скорости сборки десятки тысяч строк в секунду, разница по времени незаметна.

Сообщение от Замабувараев 4. Конфликты имён переменных уровня модуля, так как теперь такие переменные все висят в одном модуле и из локальных превращаются в глобальные. 5. То же самое про функции. Например, функция GetBytes из модуля MemoryBuffer будет конфликтовать с функцией GetBytes из модуля FileBuffer.

Пространства имен не зря придумали. Зачем называть переменные и функции одинаково в пределах проекта?

Сообщение от Замабувараев 7. Отладка усложнена, потому что не виден настоящий номер строки кода.

В PB нет таких проблем. Почему они есть в FB?

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

На сколько быстрее? На 2 секунды (с учетом скорости компиляции примерно 10 тысяч строк в секунду и число строк 25 тысяч)?

0

Сообщение от locm Вы же написали что это ориентировочное число строк.

Это оценка снизу, значит, может быть и больше.

Сообщение от locm Да и какая разница будет собран проект за секунду или за 0.98 секунд?

Вот поэтому выбираю FreeBASIC, там нет такой длительной компиляции в 10 секунд при изменении только одной строки кода.

Сообщение от locm Пространства имен не зря придумали. Зачем называть переменные и функции одинаково в пределах проекта?

Потому что они Private для другой единицы трансляции и вызвать конфликт не могут. А в PureBasic для этого приходится вводить дополнительные уровни косвенности и выдумывать пространства имён.

Сообщение от locm В PB нет таких проблем. Почему они есть в FB?

У меня нет кода в заголовочниках, таких проблем не имею.

1

Сообщение от Замабувараев Вот поэтому выбираю FreeBASIC, там нет такой длительной компиляции в 10 секунд при изменении только одной строки кода.

Я же написал что скорость компиляции в PB примерно 10 тысяч строк в секунду. Это пользовательский код. Библиотеки скомпилированы и в виде статических библиотек.
Много у вас проектов с десятками тысяч строк кода?

Сообщение от Замабувараев А в PureBasic для этого приходится вводить дополнительные уровни косвенности и выдумывать пространства имён.

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

Сообщение от Замабувараев У меня нет кода в заголовочниках, таких проблем не имею.

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

1

Сообщение от locm Я же написал что скорость компиляции в PB примерно 10 тысяч строк в секунду.

А как же десять секунд на проект?

Сообщение от locm Пространства имен никак не влияют на скорость компиляции, размер и скорость работы исполняемых файлов. Тогда чем они вам не понравились?

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

Сообщение от locm То есть все файлы компилируете отдельно и ни в одном подключаемом файле нет исполняемого кода?

В моих файлах точно нет.
Есть в заголовочных виндовых файлах несколько интринсиков.

Сообщение от locm Сами себе создаете сложности. В том числе с отладкой.

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

0

Сообщение от Замабувараев А как же десять секунд на проект?

Это если в нем 100 тысяч строк.
Многие мои проекты содержат меньше 10 тысяч строк и компилируются меньше чем за секунду (при отключенном антивирусе).

1

Сообщение от locm (при отключенном антивирусе)

Это что за компилятор ради которого нужно антивирусы отключать. Это ненормально.

0

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

1

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

Кстати удивлён, что в мейнстриме до сих пор нет специального режима разработчика.
Помню когда использовал антивирус(сейчас без него) меня это адски напрягало.
"Зависалити" секунд на 30 просто так, когда прога компилилась в клик. И не отменить, просто всё повисает нахер.
Да это был касперский KIS.

0