Создание раздела FreeBasic (голосование)

Приветствую всех форумчан!

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

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

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

---

Почему FreeBasic?

1. Современный
2. Свободный и бесплатный
3. Кроссплатформенный(Windows, Linux)

Давайте посмотрим на функционал:

Описание: http://ru.wikipedia.org/wiki/FreeBASIC
Официальный сайт(Англоязычный): http://www.freebasic.net/

Ресурсы сети интернет по FreeBasic

Русскоязычные сайты:

http://freebasic.narod.ru/
http://freebasic.ru/
Статейка: http://www.tiflocomp.ru/docs/programming/fbc.php

IDE для FreeBasic(Англ.): http://fbide.freebasic.net/
Мануал по операторам\функциям: http://www.freebasic.net/wiki/... kka=DocToc
Архив с тулзами\библиотеками\туториалами: http://www.freebasic.net/___old_site/arch/

Частичная цитата:
FreeBASIC — язык программирования высокого уровня по синтаксису наиболее близкий к
QuickBasic ... Первоначально разрабатывался как свободная альтернатива Microsoft
QuickBasic, но быстро оброс новыми возможностями и стал мощным средством разработки.

• Поддержка Unicode.
• Множество встроенных типов переменных (Byte, UByte, Short, UShort, Integer, UInteger,
  LongInt, ULongInt, Single, Double, String, ZString, WString).
• Типы данных определяемые пользователем (бесконечная вложенность, Union, тип поля
  (array, function, bit fields)).
• Пространства имён.
• Перечислимый тип (Enum).
• Новые возможности при работе с массивами (до 2 ГБ размером, Redim Preserve).
• Указатели (указатели на любые типы данных, неограниченная косвенная адресация).
• Перегрузка функций и операторов.
• Необязательные аргументы функций.
• Встроенный ассемблер (ассемблерные инструкции в исходном коде программы).
• Препроцессоры.
• Typedefs.
• Конструкторы и деструкторы классов.
• Улучшенная графическая библиотека.

Моё мнение:

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


P.S. Я постарался донести информацию в объективной и понятной форме, надеюсь тема не
останется без ответа и голосов, всем спасибо за внимание .

9

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

Не вижу связи. При отображении ANSI символы преобразуются в Unicode и отображаются. Т.е. избегая первого этапа - мы получаем тот же результат.

Сообщение от Quiet Snow Штука крайне нужная, крайне удобная.

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

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

Ну это правильней. ЯВУ должен быть отделен от "железа" для этого он и предназначен.

0

Сообщение от The trick При отображении ANSI символы преобразуются в Unicode и отображаются.

Неа, у меня всё "на своих харчах".))) Свой чарсет, свои процедуры печати. Даже загрузчик BMP свой,
накушался уже чужого, в т.ч. системного. Делаю максимально независимо. Беру то, что система может дать
гарантированно хорошо, что ничем просто не заменить уже.

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

Сам наоборот с Blitz-а ушёл на диалекты с ассемблером из-за того, что часто требуется и по мелочам и
иногда в оптимизационных целях. А раньше выхода не было на QB только так, MASM, модуль, потом LINK.
Наверное, если пишешь на несколько платформ - это плохо. Но я пишу только под винду, поэтому
не парюсь.

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

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

Не совсем понял про что ты писал, но я имел в виду саму организацию данных.
Чтобы сделать преобразование LCASE UCASE, это одна инструкция процессора XLAT для 8 битной.
Поиск по строке тут разные варианты действий но чисто стохастически(ну или опр. образом)
ткнуть в любое место мультибайтной кодировки - не выйдет. Фиксированной же - легко.

0

Сообщение от Quiet Snow Да использовал их уже. Ничего хорошего сказать об этом не могу. Куча гемора и головной боли. Заведи буфер, да проверь сколько под него надо, да то, да это, потом убей буфер. Бегай следи за этими указателями.

Ну смешно. Даже комментировать не буду.

Сообщение от Quiet Snow Господи, мне ещё думать как угодить туркам и арабам. ))) Анатолий жжёшь.

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

Сообщение от Quiet Snow Нет ни выигрыша, ни проигрыша. Мне просто не охота забивать этим бошку свою, как-то читал про это всё, думал думу и решил что ну его нафиг. Обойдутся узкоглазые. А на большинство европейских стран легко сделать через ASCII, если появится спрос. Сначала спрос - потом уже локализация. Для наших российских ребят и так канает.

Я до сих пор не понимаю при чем тут китайцы. У китайцев также есть ANSI кодовая страница. Про выигрыш я уже написал и про проигрыш тоже.

Сообщение от Quiet Snow Я больше 10 лет кодил на QB, глаз не цепляет эти новые шняги, выдумали какой то WSTRING. Разрабы не могут сделать STRING как STRING - а я парься по этому поводу. Да ну их нафиг. Вот как IDE напишут и заточку сделают - тогда будет им.

Не знаю как в FB, но дополнительный тип для строк - это хорошо. Это не то что в VB6 приходится извращаться чтобы хранить ANSI строку. ANSI или ASCII строки часто еще используются во всяких девайсах, поэтому уходить от них пока еще нельзя. Вот если бы ты писал под какие-либо девайсы проги, или сам клепал что-то я бы еще мог понять, что да, тут использование ANSI оправдано.

Сообщение от Quiet Snow Эмоджи это последовательность обычных символов. её можно "выклёвывать" из текста, визуально заменяя на смайлики из отдельно загруженного чарсета. В обратную сторону тоже работает.

https://unicode.org/emoji/char... -list.html

1

Сообщение от The trick а ты можешь все также продолжать сидеть на ANSI - идти против китайцев

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

Сообщение от The trick https://unicode.org/emoji/charts/full-emoji-list.html

Vivaldi браузер, с которого читаю форум ничего не знает про эти смайлы.
Я так понял эти знаки вопроса - ты поставил несколько смайлов.

0

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

Ну это смешно. У европейцев не влазил, достаточно посмотреть на таблицу кодовых страниц. Китайцы и Юникод это как сравнивать теплое с мягким. У китайцев свои кодовые страницы ANSI и куча народу в китае пишет на VB6 и к примеру комменты в коде пишут на китайском.
Ну а вообще - это твое дело.

Сообщение от Quiet Snow Vivaldi браузер, с которого читаю форум ничего не знает про эти смайлы.

Это не браузер, это форум режет. Браузер корректно отображает.

Сообщение от Quiet Snow Я так понял эти знаки вопроса - ты поставил несколько смайлов.

1 смайл.

1

Сообщение от The trick Инлайн асм штука вообще довольно спорная, правильней делать так - если кому-то нужен код на ассемблере - компилируйте его там и используйте.

Почему же, бывает полезной. Например пишем DLL и внедряем в другой процесс где перехватываем некоторые функции. Без асма будет сложно. Зачем отдельный модуль есть можно написать в коде на бейсике?

Сообщение от The trick Второй момент это то что прежде чем писать многопоточную программу нужно правильно это уметь делать.

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

Сообщение от The trick Вон из плюсов тоже убрали его.

Приходится мне писать на GCC для ARM микроконтроллеров и что-то я не заметил чтобы асм исчез в текущих версиях компиляторов.

1

Сообщение от locm Почему же, бывает полезной. Например пишем DLL и внедряем в другой процесс где перехватываем некоторые функции. Без асма будет сложно. Зачем отдельный модуль есть можно написать в коде на бейсике?

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

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

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

1

Сообщение от locm Приходится мне писать на GCC для ARM микроконтроллеров и что-то я не заметил чтобы асм исчез в текущих версиях компиляторов.

Не писал под ARM, поэтому не скажу. Я про студию, в которой нельзя использовать асм при компиляции 64 битных приложений.

Миниатюры

 

0

Видимо в микрософте программисты обленились, потому что не вижу проблем мешающих добавлению асм вставок в x64 код.

0

Сообщение от locm Видимо в микрософте программисты обленились, потому что не вижу проблем мешающих добавлению асм вставок в x64 код.

Я уже написал. Голый асм ухудшает переносимость кода. Если нужен асм - юзай интринсики. Куча ЯВУ в которых нет инлайн асма и это никого не смущает.

0

Сообщение от The trick Захочешь ты потом перехватывать под x64, хотя код на бейсике будет валидный, код на ассемблере уже не будет работать.

В большинстве случаев это решается заменой E регистров на R, т. е. к примеру EAX на RAX. Реже нужно править асм код. В любом случае была бы возможность, а применение асму всегда найдется.

Еще один пример когда нужен асм, это инструкция CPUID. Вот к примеру код, работающий на x86 и x64.

0

Сообщение от Quiet Snow Пока нет полной 100% унификации так будет всегда.

Уже есть, называется: юникод.

Сообщение от Quiet Snow Не согласен, ты крепишь BloatWare к неюникодным функциям, хотя этот аспект на скорость работы и отожранность вообще никак не влияет

Ещё как влияет.
Вот простое и несложное доказательство, что вызов неюникодной функции — это BloatWare. Разберём на примере SendMessageA, но вообще так работает ЛЮБАЯ неюникодная функция.

Итак, программист вызывает неюникодную функцию, напимер, SendMessageA с параметром WM_SETTEXT:

1. SendMessageA вызывает MultiByteToWideChar чтобы получить длину будущей юникодной строки (бац! — лишний вызов измерения длины строки).
2. SendMessageA выделяет память для хранения юникодной строки (бац! — лишний вызов выделения памяти, которой может не хватить).
3. SendMessageA конветирует строку в юникод через MultiByteToWideChar, с потерей информации ?сли неюн?кодная ст?ока б?ла не в кодировк? CP_ACP (бац! — лишние такты процессора для конвертации).
4. SendMessageA вызывает свой юникодный аналог SendMessageW с параметрами и ждёт результата (бац! — лишний прыжок в другой участок памяти, кеш процессора может быть нарушен).
5. Приходит результат юникодной функции.
6. SendMessageA освобождает память (бац! — лишний вызов уничтожителя памяти).
7. Возвращает результат.

Сообщение от Quiet Snow Это если у тебя фиксированная байтовая кодировка. А если байты плавающие - то это жопа.

Я использую WString, это родной юникод для Шindows, фиксированная байтовая кодировка юникода в виде UTF-16 LE с суррогатными парами (UCS-2). Никаких конвертаций.

Сообщение от Quiet Snow А в чём? Тебе нужны иероглифы? Русским людям нужны иероглифы? Может немцам нужны? Или англичанам, французам, итальянцам? Нет. Ну коли нет - этот вопрос идеально решает расширенный ASCII

Да, мне нужен ять ѣ. В какую кодировку мне запихнуть ять? А ещё мне нужны фита, ижица, и‐десятеричное, тире, дефис, стрелочки, ударение, многоточие, кривые и косые рожи.
И вообще, не вижу смысла себя ограничивать диапазоном 31-255 символов.

Сообщение от Quiet Snow чего нет на твоей клавиатуре(что это даже и напечатать не сможешь, без ворда с его "вставкой символа" или таблиц в интернете).

Ворд не нужен, я его не устанавливал. Есть редактор раскладок клавиатуры от корпорации Микрософт. Рекомендую ознакомиться, а то и причаститься:
https://www.microsoft.com/en-u... x?id=22339

Сообщение от Quiet Snow Во-вторых ты завязываешь это всё на натив, выйдет новая винда, введут новую кодировку и всё

Ну вот когда выйдет, тогда и поговорим (спойлер: не выйдет).

Вообще это мне напомнило: «А как же перфокарты? Что ты будешь делать когда отменят перфоркарты?!»

Сообщение от Quiet Snow Если я захочу открыть файл со 100% гарантией - могу воспользоваться системным диалогом.

Как со 100% гарантией? Даже если этот диалог выдаст юникодную строку, то она будет запихнута в неюникодную строку с потерей ??????????, появятся ????? вопроса и ???????? FILE_NOT_FOUND.

DATA EXPUNGED

1

Сообщение от locm В большинстве случаев это решается заменой E регистров на R, т. е. к примеру EAX на RAX. Реже нужно править асм код. В любом случае была бы возможность, а применение асму всегда найдется.

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

Сообщение от locm Еще один пример когда нужен асм, это инструкция CPUID. Вот к примеру код, работающий на x86 и x64.

Тот же самый код, в C/C++ решается через интринсик __cpuid(ex) без всякого инлайн асма. Замечу что кода гораздо меньше.

0

Сообщение от Замабувараев Итак, программист вызывает неюникодную функцию, например, SendMessageA с параметром WM_SETTEXT:

А если запускают x86 приложение в x64 системе, накладных расходов будет еще больше.
Прекращаем компилировать x86 приложения и полностью переходим на x64 (ведь x86 систем осталось не много, т. к. ограничение на объем ОЗУ)?

Сообщение от The trick Тот же самый код, в C/C++ решается через интринсик __cpuid(ex).

Мы вроде бейсик обсуждаем.

Сообщение от The trick Замечу что кода гораздо меньше.

Ну так его тоже можно сократить если отказаться от сохранения регистров.На работоспособность это не повлияло.

0

Сообщение от The trick Можешь и дальше писать "для себя", я не против.

Вот это было некрасиво.


Ладно пойду. Делов полно, тут слишком дикая и жаркая дискуссия для моих старых мозгов.

0

Сообщение от locm А если запускают x86 приложение в x64 системе, накладных расходов будет еще больше. Прекращаем компилировать x86 приложения и полностью переходим на x64 (ведь x86 систем осталось не много, т. к. ограничение на объем ОЗУ)?

Я не знаю. Но мне точно не надо замедлять свою программу пустопорожним гонением строк из ANSI в UTF-16 и обратно.

0

Сообщение от locm Прекращаем компилировать x86 приложения и полностью переходим на x64 (ведь x86 систем осталось не много, т. к. ограничение на объем ОЗУ)?

64 битное приложение не будет работать на 32 битных системах коих немало на данный момент. Использование же юникода - не влияет на работу приложения, только на совсем уже древних системах.

Сообщение от locm Мы вроде бейсик обсуждаем.

Ну я вообще-то писал о том что в VC++ его выпилили и показал что можно обойтись без него. Хуже от этого не стало. Использование интринсиков вместо асма - ничуть не хуже, а если нужен именно асм - пожалуйста, компилируйте в асме и линкуйте.

Сообщение от locm Ну так его тоже можно сократить если отказаться от сохранения регистров.

Дело не в этом. Такой же код можно и на VB6 написать. Я объясняю почему инлайн асм спорная штука в языке высокого уровня. Вон в студии юзай готовые интринсике - всего одна строчка, уже все готово. Нужно SSE/AVX - интринсики. Не устраивает - пиши на асме и линкуй. Почему? Потому что это несовместимо. Нужно под другую архитектуру писать - и весь асм полетит к чертям.

Сообщение от Quiet Snow Вот это было некрасиво.

Не хотел обидеть, но это так и выглядит. Ты же пишешь - "с какого фига я должен под них подстраиваться", "Мне просто не охота", "Господи, мне ещё думать как угодить туркам и арабам." и т.п. Такое ощущение что ты "для себя" и пишешь, не зря в кавычках же написал. Без обид.

1

Сообщение от The trick 64 битное приложение не будет работать на 32 битных системах коих немало на данный момент.

Обычно x86 систему ставят если меньше 4 ГБ ОЗУ, иначе не будет использована вся память. PAE не всегда является выходом из этой ситуации.
А поскольку в современных компах обычно больше 4 ГБ, значит уже очень многие перешли на x64. Как вариант можно компилировать для x86 и x64 и запускать приложение соответствующее разрядности системы. Я обычно так поступаю когда выкладываю приложения в сеть.

1

Сообщение от locm Обычно x86 систему ставят если меньше 4 ГБ ОЗУ, иначе не будет использована вся память. PAE не всегда является выходом из этой ситуации. А поскольку в современных компах обычно больше 4 ГБ, значит уже очень многие перешли на x64. Как вариант можно компилировать для x86 и x64 и запускать приложение соответствующее разрядности системы. Я обычно так поступаю когда выкладываю приложения в сеть.

Скажи это государственным организациям. Там до сих пор XP 32 разрядные стоят с 512 МБ оперативки. Зачем иметь 2 приложения если первое гарантированно работает на обеих? И при чем тут юникод вобще? Я пояснил уже что сравнение некорректное.

1

Сообщение от locm Если установите убунду 10-ти летней давности, может быть, но современные версии такие же требовательные к железу как Windows 10. В этом плане Windows XP намного лучше.

Проблема в том, что я разрабатываю проги на современном компе с Win_10, но при этом некоторые из них предназначены для прогона на стареньком нетбуке. "Штатная" операционка там именно Windows XP, но проблема в том, что я недавно использовал в своей программе одну полезную функцию WinAPI, которая поддерживается только начиная с семёрки. Ну и разумеется, на Windows XP моя программа уже не запустилась. Пришлось с большим трудом "впихнуть" на тот нетбук семёрку. Но там частота процессора всего 900Мгц, "тяжёлый софт" уже не потянет, хотя надо испытывать, конечно, но сейчас руки до него не доходят по разным причинам.
Но за информацию о том, что современные линукс-системы стали тяжёлыми, в любом случае, спасибо. Очень широко распространено мнение, что линукс гораздо "легче" винды. Буду теперь в курсе, что это не всегда так.

Сообщение от locm Что мешает используя скажем ACM функции кодировать WAV в MP3 в реальном времени? Это требует совсем немного процессорного времени (меньше процента вместе с записью в файл), но в системе должен быть установлен MP3 кодек. Проще всего установить пакет K-Lite Codec Pack.

Мешает то, что всё это надо знать. Вот вы бы не сказали, я бы и не знал, что существует такая возможность.
На данный момент у меня задумано так, что "конечный продукт" - файл WAV - сбрасывается на диск, а там его подхватывает бесплатная сторонняя утилита, которая конвертирует его в формат MP3.
А K-Lite Codec Pack у меня, разумеется, установлен уже очень давно и постоянно обновляется, как, думаю, почти у всех в наше время. Очень популярная программа.

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

Вот именно от такого подхода мне и хочется уйти. Во-первых, для ускорения работы проги, а во-вторых, чтобы не "мордовать" SSD лишний раз

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

Сообщение от Quiet Snow Последние linux-ы которые я ставил в прошлом году(mint lxde) вызвали у меня чувство глубочайшего стыда за разработчиков

Ну значит на линуксах ставлю жирный крест!

Сообщение от Quiet Snow Сообщение от Power_Basic Не надо ожидать слишком многого от продвинутой домохозяйки Расскажите про ваши проекты, у меня есть предположение, что домохозяйка тут некоторых расфуфыренных "типа прогеров" вполне себе раскатает. Можно и в ЛС, я так чисто по братски интересуюсь, не в том формате в котором обычно это вынужден делать

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

0