Создание раздела 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

locm, ну вообще проще использовать штатную многопоточность "из коробки" - ActiveX EXE. Если по какой-либо причине это не подходит то тогда уже можно использовать другие обходные варианты.
Прелесть COM в том что с COM объектами можно работать прозрачно. Сами объекты могут жить в разных потоках/процессах/машинах. Работа с ними от этого не меняется.

0

Сообщение от Power_Basic ну то есть под Win_64. Вот это и будет FreeBasic

Там уже давно по словам Стаса "разброд и шатание".
Вообще FB с одной стороны хорош, с другой нет. Например уже говорил про Linux-подобные
библиотеки с их экономным засовыванием не всего кода, привыкнуть можно, но неприятно.
Далее ассемблер, слава всем богам что он есть и что в FB коде он intel-о подобный, но мать
их всех за ногу, что сам ассемблер(результирующий код) GNU... со всеми вытекающими.
Там в их документации член сломаешь. Не FASM конечно...

Короче надо походу брать и перехерачивать этот компиль с нуля. Отрезать кучу гавна лишнего,
оставить QB базу но чтобы под винду всё работало и будет кошерно. Это конечно тянет за собой
хотя бы примитивный ассемблер, а он тянет за собой линковщик. Короче до пенсии будет чем заняться.

0

Сообщение от Power_Basic а мне хотелось бы приобрести ещё и отвёрточку "под крестик", ну то есть под Win_64.

Какое преимущество это даст лично вашим программам? Как инструмент может лежать в ящике, авось и пригодится. Я вот имею такую возможность (создавать x64) с того времени, как познакомился с PureBasic, но в практических целях ни разу не использовал. Нет, конечно ради спортивного интереса компилировал, но что бы вот прямо без этого не обойтись ни как - такого не случилось ни разу. То же самое скажу и про кроссплатформенность.
Для Андроид планшета могу порекомендовать Basic4Android
Basic для платформы Android - Basic4Android

0

Сообщение от Quiet Snow Я пользуюсь FBEdit-ом. Ничё не знаю про BOM не BOM. Пробовал блокнотом сохранять, пробовал Bred-ом 2-м сохранять - один фиг. Чё это за прога такая для которой нужен особенный текстовый редактор? Приложи свой текстовый файл, хоть посмотреть на него.

Во вложении исходный код.

В автоматизации (всё что унаследовано от IDispatch) все строки представлены в виде BSTR. Это юникодные строки.

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

Чтобы компилятор считал все строки юникодными надо сохранять исходник в одной из юникодных кодировок с указанием порядка байтов BOM. Для этого подходят кодировки UTF-8 с BOM и UTF-16 Litte Endian c BOM. Метка порядка байтов, она же BOM, — это указание в какой последовательности символы текста преобразовывать в байты на диске. Когда компилятор встречает BOM, то он считает этот файл юникодным, и все строковые литералы становятся юникодными. https://ru.wikipedia.org/wiki/... сти_байтов

Для FBEdit UTF-16 — это единственный известный мне способ заставить его понимать юникод, но файл всё равно придётся создавать внешним редактором, сам FBEdit делать этого не умеет.

Для UTF-8 есть опция, сохранять файл в голой UTF-8 или UTF-8 вместе с BOM. Для UTF-16 практически всегда редакторы автоматически вставляют BOM и используют Little Endian, поэтому обычно при указании UTF-16 фразы «BOM» и «Little Endian» опускают.

Блокнот из Windows XP может сохранять UTF-8 только вместе с BOM, а UTF-16 LE там названа загадочно «юникод»:
рис. 1: выбор кодировки в блокноте Windows XP

(Благодаря BOM размер пустого файла в кодировке UTF-8, созданного в блокноте WinXP, равен трём байтам, в «юникоде» — двум байтам, хотя символов текста в таком файле нет.)

Блокнот из Windows 10 называет все эти кодировки своими именами, тут есть UTF-8 и UTF-16 LE:
рис. 2: выбор кодировки в блокноте Windows 10


Истерическая справка.

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

Где‐то в 1970‐х стало понятно, что для представления всех символов не хватает диапазона не только 0-127, но и диапазона 0-255. Тогда придумали хитрый трюк: одно и то же число могло представлять разные символы в зависимости от кодовой таблицы (кодировки). Так появились кодировки типа 866 DOS, 1251 и прочие КОИ-8. До конца 1980‐ых этот трюк работал.

К 1990 накопилось столь много кодировок, что все они мешали международному общению. Собралось мировое сообщество, сказало, что отныне у нас будет одна универсальная кодировка, которая будет содержать все символы из всех языков мира, самопровозгласило себя консорциумом юникода и разработало ЮНИКОД.

Теперь для представления символов число может быть в любом диапазоне, например, от 0 до 65535 или даже больше. На практике зафиксирована верхняя граница числа 1112064, но в будущем она может быть увеличена. Такие большие числа не вмещается в один байт. Теперь для представления одного символа требуется не один байт, а несколько. В 1991 году мировая гармония «байт = символ» была уничтожена, а музыка сфер перестала звучать в сердцах несогласных.

Хранение в памяти чисел больше 255 можно представить несколькими способами: сначала старшие байты потом младшие (Big Endian, BE), или наоборот младшие байты, потом старшие (Little Endian, LE).

Юникод пытался уйти от кодировок, но парадокс в том, что для представления юникода требуются свои юникодные кодировки:
* UTF-7, но я её рассматривать не собираюсь;
* UTF-8: символ = от 1 до 6 байт;
* UTF-16: символ = 2 байта;
* UTF-16 с суррогатными парами (UCS-2): символ равен 2 или 4 байтам, в ядре Windows применяется именно это представление юникода;
* UTF-32: символ = 4 байтам, в жизни практически не встречается;
* UTF-32 с суррогатными парами (UCS-4): символ = 4 или 8 байт, теоретически возможна, но в жизни не встречается.

Байты в UTF-16 и UTF-32 могут быть записаны от старшего к младшему (получаем Big Endian) или от младшего к старшему (получаем Little Endian).

Вложения

SapiVoice.zip (2.9 Кб, 3 просмотров)

0

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

Тот что BOM кракозяблами в редакторе:

Компилируется, но не говорит.
Если заменить кракозяблы на нормальный английский текст, то говорит.
Тот что SapiVoice.UTF-16 LE выглядит правильно в редакторе, компилируется.
Но чтобы заговорил надо вставить английскую фразу, по-русски не понимает, а выбора движка нет у тебя.
Вот так нормально.

0

Сообщение от Pro_grammer Тот что BOM кракозяблами в редакторе:

Значит, ваш редактор не поддерживает юникод.

0

Сообщение от Замабувараев ваш редактор

Это не мой редактор, а популярный для FB - fbedit.exe

0

FBEdit может читать уже готовые файлы в UTF-16, но сам создавать такие файлы не умеет. Пичалька.

0

0

Сообщение от locm Разве он не открытыми исходными кодами? Что мешает доработать? Пользуясь бесплатными OpenSource проектами нужно быть готовым к тому что дорабатывать и исправлять ошибки придется часто и много. Потому что никто никому ничего не должен.

1. Мне лень.
2. Преимуществ перед тем же Notepad++ он не даёт.

0

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

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

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

Ну в принципе, да, понятно. Я это упустил из виду. Впрочем большинство моих программ обычно обходится без WinAPI. Хотя, конечно, язык будет новый, и я не уверен, что там буду так же часто обходиться без WinAPI как в Визуальном или в PowerBasic'е.
Ну да впрочем вот прямо сейчас мне эта кроссплатформенность вовсе не нужна. Её я рассматриваю исключительно как дополнительный бонус с прицелом на очень далёкое будущее.

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

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

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

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

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

Сообщение от Quiet Snow Фичи надо будет найти и освоить. Чудеса творит Анатолий, надо разницу понимать между ним и обычным смертным, т.е. захочешь ли ты расковыривать до атомов VB в отладчике и читать про самые нутра винды, чтобы как-то всё это понимать, что там было сделано и как оно в точности работает. Если да - то ну ok.

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

Сообщение от The trick Прелесть COM в том что с COM объектами можно работать прозрачно. Сами объекты могут жить в разных потоках/процессах/машинах. Работа с ними от этого не меняется.

Работать с ними, конечно, хорошо, но, к сожалению, совсем не просто

Сообщение от Quiet Snow Там уже давно по словам Стаса "разброд и шатание".

Поздно отговаривать, я уже сделал свой выбор

Сообщение от Quiet Snow Далее ассемблер, слава всем богам что он есть и что в FB коде он intel-о подобный

А вот это большой плюс.

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

Ну это же очень удобно, если, например, при создании той же аудиокниги у нас имеется возможность создавать "сырой" аудиопоток (а это WAV, который в 11 раз объёмнее чем MP3), не разрезая по частям исходный текст (а это, например, огромная толстенная книга), а "заряжать" всё содержимое целиком в память. Мне недавно подсказали здесь на форуме, что можно использовать File Mapping, но это опять же дополнительные, и причём, неслабые сложности.
Сейчас у меня 8 гигов оперативки, со временем планирую подкупить до 64. Сейчас не обидно, а вот когда из имеющихся 64 можно будет использовать только 3, тогда это, знаю наперёд, будет очень обидно.
Разумеется, можно выходить из положения, используя что-то вроде страниц. Но это же опять получается что-то вроде сегментации памяти в MS-DOS'е, ну каменный век какой-то

Сообщение от Pro_grammer Для Андроид планшета могу порекомендовать Basic4Android Basic для платформы Android - Basic4Android

Спасибо, что напомнили. Воистину, всё новое это хорошо забытое старое
Я эту прогу (или, наверно, точнее будет сказать, среду разработки) впервые обнаружил на сайте 4pda в 2016-ом году. Замучался её устанавливать. Она же платная. Установишь, сначала вроде бы всё в порядке, а потом через пару часов она начинает бастовать. Но потом один форумчанин поделился со мной уже точно работающей версией (5.50+full). Это была далеко уже не самая свежая версия на тот момент, но зато работала безотказно.
Но в конечном итоге я написал тогда всего лишь одну простую пробную программу, а потом снова полностью переключился на винду. Ну просто не было идей для андроида. Там же плей-маркет, бесплатные программы на любой вкус и под любую задачу. А чтобы написать свой "серьёзный" софт это же надо серьёзно вникать во все тонкости. Вы-то хоть тогда были увлечены идеей написать свой Блокнот, а у меня как-то и идей на тот момент для Андроида не нашлось, ну вот и забросил.
Спасибо, что напомнили. Кстати, она теперь бесплатной стала, оказывается. Так что все желающие скачивайте, не пожалеете!
https://www.b4x.com/

0

Сообщение от Power_Basic можно установить убанту, например. Тогда, по идее, будет "летать" как молодой

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

Сообщение от Power_Basic Ну это же очень удобно, если, например, при создании той же аудиокниги у нас имеется возможность создавать "сырой" аудиопоток (а это WAV, который в 11 раз объёмнее чем MP3)

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

Сообщение от Power_Basic а "заряжать" всё содержимое целиком в память.

Зачем если можно записывать в файл по мере получения данных?

1

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

Отказ от XP был хорошо спланированной акцией. Вместо того чтобы дорабатывать хорошо
написанную изначально ось они всей шайкой договорились с вендорами и решили срубить бабла.
Маркетологи их конечно поддержали. А линуксы - да, та ещё параша неповоротливая да и
не френдли(friendly fire ). Тенденции настигли линукс, когда в самой популярной убунте
зафигарили вот эту менюшку слева. Это был эпичнейший провал. Последние linux-ы которые
я ставил в прошлом году(mint lxde) вызвали у меня чувство глубочайшего стыда за разработчиков,
потому что на двух виртуалках оболочка не смогла себя отобразить со старта.

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

Скорость записи\чтения на обычный жёсткий диск около 100-200 Мб/с (200 у топовых дорогих,
слегка больше 100 - у бюджетных). Скорость доступа к памяти - десятки гигабайт в секунду.
При каком-либо редактировании или обработке - это более юзабельно. Есть мысли,
что небольшие файлы в 100-200 Мб можно и в памяти держать, не дёргая диск.
Скидывание на диск хорошо тем, что при вырубании электроэнергии - данные останутся.
Ну и если пользователь знает что ему надо единоразово записать - тогда тут вопросов вообще нет.

Сообщение от Power_Basic Не надо ожидать слишком многого от продвинутой домохозяйки

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

Сообщение от Замабувараев 2. Преимуществ перед тем же Notepad++ он не даёт.

Мне он чисто визуально и концептуально не понравился ещё давно, по сути обычный блокнот, но
из него сваяли инструмент для программиста, да ещё и для типа "любого" программиста, когда нужен просто
блокнот без лишнего гавна. Вообще если негласно - все исходники обычно распространяют в ASCII,
в не расширенном. Когда для работы исходника требуется, чтобы исходник был в какой-либо
кодировке - это уже нонсенс. Грамотный код сам преобразует всё в необходимый формат, либо
через системные функции, либо через самописные.
Более того, меня напрягает и FBEdit о чём не раз упоминал. И когда идёт речь о FB то имхо - нет каких-то
конкретных стандартов пока. Потому что в нормальных диалектах к компилятору идёт и IDE и всё
притёрто строго к одной кодировке. FB же оставили на откуп программистам. Каждый вертится как может.
Просто если ты хочешь чтобы твои исходники не работали у 95% прогеров, то да можно выставить им
требования к кодировке. Это воля каждого.
И если чтобы понять работу ASCII достаточно оглядеть 1 раз таблицу, то для юникодов там запудрили
всем мозги кучей каких-то преобразований и любая документация будет страниц на 5 минимум.
Вон Стас тогда писал свои версии LCASE, UCASE, потом поиск в строке, он замудохался, меня спросил
а я ему чё отвечу, всю жизнь на ASCII сижу, глянул документацию, просто опух от количества нюансов,
алгоритм словами описал, говорю: да фиг знает. Думал на асме пропишу, а хрен там пел. Просто понимаю
что оптимизировать то особо и нечего, т.е. не особо реально и будет не быстрее чем он написал
используя функции си.

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

Сообщение от Замабувараев Все эти конвертации — это путь bloatware. Я решил раз и навсегда хранить исходники в юникоде.

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

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

И где она эта универсальная? Они всем мозги запудрили стелясь под китайцев. Ты сам штук десять перечислил.
То была 1251 и OEM866, KOI я не рассматривал и никогда с ней не работал. Считай две популярные кодировки
под винду, а сейчас UTF-8, UTF-16, новый ещё подтянули UTF-32(на которую по-моему мировое сообщество
вообще забило, отложив в долгий ящик). Да ещё и BOM-ы эти, в гробу я их видал думать ещё
о последовательности бит, они совсем что-ли опупели.

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

1

Сообщение от Power_Basic Ну это же очень удобно, если, например, при создании той же аудиокниги у нас имеется возможность создавать "сырой" аудиопоток (а это WAV, который в 11 раз объёмнее чем MP3), не разрезая по частям исходный текст (а это, например, огромная толстенная книга), а "заряжать" всё содержимое целиком в память...а вот когда из имеющихся 64 можно будет использовать только 3, тогда это, знаю наперёд, будет очень обидно.

Это утопия.
Мало того, что хорошая mp3 книга всегда разделена на главы, так её удобно слушать, так ещё и технический аспект, для гарантийной совместимости, обычно карту памяти форматируют в FAT32, а это ~ 4 ГБ на файл макс.
И практический аспект состоит в том, что реально будет обидно, когда вся ваша работа по записи непрерывного файла пусть даже на 10 ГБ навернётся из за сбоя записи на диск или сбоя памяти. В случае с маленькими фалами вы теряете только один, а тут сразу всё.
Разрезать руками текст не надо. Надо программно делить текст на главы, это же не трудно сделать, они же отличаются визуально по многим признакам. Тогда процесс будет непрерывным, а книжка удобной и совместимой с любым носителем.

1

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

Дело же вообще не в этом, что там китайцы думают.

Дело в том, что в WinAPI функции которые строки принимают, они только в одном варианте существуют: в юникодном. А неюникодные функции — это лишь оболочка над юникодными, они просто гоняют байты из неюникода и обратно в юникод, внутри себя они ничего не делают, лишь вызывают юникодную версию функций.

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

0

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

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

Сообщение от Замабувараев Дело же вообще не в этом, что там китайцы думают.

А в чём? Тебе нужны иероглифы? Русским людям нужны иероглифы? Может немцам нужны?
Или англичанам, французам, итальянцам? Нет. Ну коли нет - этот вопрос идеально решает
расширенный ASCII. Ну разумеется если тебе не нужны какие-нибудь чёрточки, загагулины и прочее
фиг пойми что, чего нет на твоей клавиатуре(что это даже и напечатать не сможешь, без ворда
с его "вставкой символа" или таблиц в интернете).
Критичные аспекты в данном случае это всё что требует идентичности при конверсии строк,
например имена файлов(из-за того что туда можно насовать всякой юникодной фигни которой
попросту нет в ASCII, чем злоупотребляют "блондинко-юзеры"). Говорилке же абсолютно насрать,
она говорит буквами, которые будут в любой кодировке тут перевод 100% идентичный.

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

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

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

Да и пусть гоняют. Пока нет полной 100% унификации так будет всегда. Вот когда мировое сообщество
усадит свои нежные жопы в мягкие кресла переговоров, консолидирует стандарт, напишет грамотную,
качественную документацию со всеми нюансами, на понятном, человеческом языке - вот тогда я обдумаю
твоё предложение.
А так что ты хочешь меня пересадить на UTF? - Нет мне он неудобен, нахера мне тысячи символов,
я свой чарсет нарисовал из 255, мне хорошо и удобно. Всё быстро считается, всё быстро рисуется,
всё своё, зависимостей ноль. Если я захочу открыть файл со 100% гарантией - могу воспользоваться
системным диалогом. Или написать соотв. утилиту, которая будет делать всю эту грязную работу.
UTF-8 компилятор поддерживает нормально. Чё мне ещё надо? У меня всё работает, кому я код бы
не дал, у всех будет результат на 100% идентичный.
Хочешь меня пересадить на нотепад++ - так его я вообще в гробу видал, мне что нотепад, что FBEdit
терплю, пока терпится. Вот в QB был редактор, адово, невероятно удобный. А эти чушковые - далеки
от моих хотелок, да ещё шило на мыло менять. Нет, упаси "лоссось" от таких перемен.

Добавлено через 17 минут
И нет я не навязываю. Пользуйтесь чем хотите. Юникод всякий разный, FBEdit, Notepad++.
Сам пользуюсь тем, чем мне удобно и не навязываю. Для вас работает - хорошо.

Cвои проги буду писать со своим "уровнем совместимости", бояться мне не за что, потому что
всё тестируется многократно. Это новичкам если хотите прививайте, я это всё пишу просто
чтобы люди понимали суть и в частности то, что историю IT просто так не поменять, то что сделано - не выкинуть.
Вон PB, зафигачили ЯП, IDE, всё ПРЕКРАСНО работает на UTF-8, я когда кодил на нём НИ РАЗУ не
лез в API винды по кодировкам, вообще забыл что такое кодировки, просто решал задачи.

Путь указан. А пока всё как говорил Стас "разброд и шатание". И не будет по-другому,
потому что везде есть свои фишки, разная степень удобства с теми или иными вещами.

0

Сообщение от Power_Basic Да можно было и без ссылок, я же это уже видел (потому и упомянул), хотя и не особо глубоко вникал, конечно. Ну да, в наших языках (PureBasic и PowerBasic) ассемблер и многопоточность использовать одно удовольствие, я согласен, в них эти фичи уже изначально заложены "производителем". А там в блогах это, будем говорить, танцы с бубном. Но с другой стороны, если, например, какому-то любителю вроде меня сложно или просто лень изучать ещё один язык, но при этом он уже неплохо овладел Визуальным Бейсиком, тогда эти расширения могут ему очень сильно пригодиться, я думаю.

Ассемблер никак не согласуется с концепцией безопасности в VB6. Инлайн асм штука вообще довольно спорная, правильней делать так - если кому-то нужен код на ассемблере - компилируйте его там и используйте. Инлайн асм для этого не нужен. К примеру этот же инлайн асм убран из 64 битных студий. Если кому-то нужно - компилируйте в MASM64/FASM DLL или объектный файл и линкуйте. Альтернативно можно использовать интринсики, но это тоже не асм.

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

Сообщение от Power_Basic Работать с ними, конечно, хорошо, но, к сожалению, совсем не просто

В чем сложности? Работать с COM можно хоть из ассемблера, и это не так сложно. Что уж говорить про другие ЯП. Я говорю сейчас именно о работе с готовыми, а не создание COM компонентов.

Сообщение от Power_Basic Ну это же очень удобно, если, например, при создании той же аудиокниги у нас имеется возможность создавать "сырой" аудиопоток (а это WAV, который в 11 раз объёмнее чем MP3), не разрезая по частям исходный текст (а это, например, огромная толстенная книга), а "заряжать" всё содержимое целиком в память. Мне недавно подсказали здесь на форуме, что можно использовать File Mapping, но это опять же дополнительные, и причём, неслабые сложности. Сейчас у меня 8 гигов оперативки, со временем планирую подкупить до 64. Сейчас не обидно, а вот когда из имеющихся 64 можно будет использовать только 3, тогда это, знаю наперёд, будет очень обидно. Разумеется, можно выходить из положения, используя что-то вроде страниц. Но это же опять получается что-то вроде сегментации памяти в MS-DOS'е, ну каменный век какой-то

Это вообще неправильная концепция если у пользователя 64Г памяти это не значит что приложение должно отжирать все 64 гига. Вы когда смотрите 2 часовой фильм думаете все кадры из фильма разжимаются и висят в памяти? Это сколько же тогда нужно памяти! Использование FileMapping - это никакие не сложности когда нужен большой объем памяти, так работает ОС вообще. Ваша задача решается потоковым сжатием и записью в файл, тут вообще не нужно много памяти.

Сообщение от Quiet Snow И если чтобы понять работу ASCII достаточно оглядеть 1 раз таблицу, то для юникодов там запудрили всем мозги кучей каких-то преобразований и любая документация будет страниц на 5 минимум. Вон Стас тогда писал свои версии LCASE, UCASE, потом поиск в строке, он замудохался, меня спросил а я ему чё отвечу, всю жизнь на ASCII сижу, глянул документацию, просто опух от количества нюансов, алгоритм словами описал, говорю: да фиг знает. Думал на асме пропишу, а хрен там пел. Просто понимаю что оптимизировать то особо и нечего, т.е. не особо реально и будет не быстрее чем он написал используя функции си.

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

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

А причем тут китайцы вообще?

Сообщение от Quiet Snow И где она эта универсальная? Они всем мозги запудрили стелясь под китайцев. Ты сам штук десять перечислил. То была 1251 и OEM866, KOI я не рассматривал и никогда с ней не работал. Считай две популярные кодировки под винду, а сейчас UTF-8, UTF-16, новый ещё подтянули UTF-32(на которую по-моему мировое сообщество вообще забило, отложив в долгий ящик). Да ещё и BOM-ы эти, в гробу я их видал думать ещё о последовательности бит, они совсем что-ли опупели.

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

0

Сообщение от The trick А причем тут китайцы вообще?

Как при чём? Ключевое, зачем людям юникод - они хотят писать "взрослые программы для всего мира".
И если мы почему то такие добрые, хотим угодить и америкосам и китайцам, то и тем и другим на нас
плевать, причём на 100%, они пальцем ноги не шевельнут, чтобы даже на английский свои творения
перевести.
И вот до поры до времени, пока в дело не включились китайцы со своими 5000 иероглифами, людям вполне
хватало расширенного ASCII. Ну конечно если это не полиграфия. Для элементарного GUI - редко когда
нужны какие-либо нестандартные символы из этих самых таблиц юникода.

Сообщение от The trick Ну на ASCII нельзя использовать к примеру кирилличесике символы

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

0

Сообщение от Quiet Snow Это если у тебя фиксированная байтовая кодировка. А если байты плавающие - то это жопа. Большой вопрос где тратится больше ресурсов. Плюс когда ты обрабатываешь меньше информации, есть возможность написать более эффективные функции.

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

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

Это называется ANSI кодировка, которая является кодировкой с переменной длиной (многобайтовая). ASCII стандарт кодирует только нижние 128 символов.

Сообщение от Quiet Snow Во-первых юникод(с переменным кол-вом байт на символ) жрёт больше памяти, чем фиксированная байтовая кодировка.

В Windows не используются фиксированные кодировки. Тут либо многобайтовая кодировка, либо юникод, отсюда и название функций MultiByteToWideChar/WideCharToMultiByte.

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

Этого требует ANSI кодировка и это выполняется каждый раз кода используется ANSI кодировка. Windows работает с UTF-16.

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

Да нет. Юникода за глаза хватает - там еще полно свободного места.

Сообщение от Quiet Snow Да и пусть гоняют. Пока нет полной 100% унификации так будет всегда. Вот когда мировое сообщество усадит свои нежные жопы в мягкие кресла переговоров, консолидирует стандарт, напишет грамотную, качественную документацию со всеми нюансами, на понятном, человеческом языке - вот тогда я обдумаю твоё предложение.

Так уже давно написали.

Не могу понять противников Юникода. Сейчас по-моему все системы нативно поддерживают Юникод. Так в чем проблема - бери и используй. В чем потенциальный выигрыш от устаревшей ANSI? Ну ANSI это тот же урезанный UTF-8 с кучей проблем этих кодовых страниц. Зачем они вам?

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

Сообщение от Quiet Snow Как при чём? Ключевое, зачем людям юникод - они хотят писать "взрослые программы для всего мира". И если мы почему то такие добрые, хотим угодить и америкосам и китайцам, то и тем и другим на нас плевать, причём на 100%, они пальцем ноги не шевельнут, чтобы даже на английский свои творения перевести. И вот до поры до времени, пока в дело не включились китайцы со своими 5000 иероглифами, людям вполне хватало расширенного ASCII. Ну конечно если это не полиграфия. Для элементарного GUI - редко когда нужны какие-либо нестандартные символы из этих самых таблиц юникода.

Нет. Во-первых, мы (Россияне) не единственные на земле. И если к примеру тебе не хочется писать под китайцев, то тем же американцам возможно хочется и не только им. Во-вторых, китайцы тут вообще не причем. Посмотри сколько наборов символов существует и они несовместимы. Турки, арабы, греки, японцы и др. они тоже попадают под проблему ANSI кодировки. А еще emoji, всякие смайлы и т.п. штуки которые сейчас на каждом углу. Юникод решает эти проблемы. ASCII кроме латинского алфавита и некоторых символов ничего больше не предлагает и проблему никак не решает.

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

Это не ASCII, а ANSI. Про проблемы ANSI уже написали и я и Замабувараев.

1

Сообщение от The trick Зачем использовать кодовые страницы когда можно использовать юникод и иметь весь набор символов без всяких проблем?

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

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

Штука крайне нужная, крайне удобная. Требуется иногда даже по мелочи. Например недавно потребовалось
использовать ротацию битов. Городить код на бейсике - да ну нафиг. Врубил асм, одной инструкцией ROL \ ROR
фигакс - дело сделано. А там бы пришлось заводить переменную, выделять 7 бит, двигать его, потом двигать
то откуда взяли его, потом соединять через OR, а обратно двигать - так там другая последовательность,
опять мудрить. И ради этого открывать отдельную среду, делать модуль, потом руками его подключать - не дядь.

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

Сообщение от The trick MultiByteToWideChar/WideCharToMultiByte

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

Сообщение от The trick Турки, арабы, греки, японцы

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

Сообщение от The trick В чем потенциальный выигрыш от устаревшей ANSI?

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

Плюс на какой-нть OpenGL проще писать через ASCII свой шрифт. Большинству гуёв этого хватает позарез.
А где не хватает - там уже выхода нет.
Ну ещё скажу открыто мне не нравится эта тряхомудия с WString

Сообщение от Замабувараев Dim rgszNames(cNames - 1) As WString Ptr = {@"Speak"}

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

Добавлено через 3 минуты
Короче сойдёмся на том что квит уже стар для всего этого дерьма.

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

Сообщение от The trick А еще emoji

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

0