Проект <<FreeBasic>>

tux пишет:А помоему бейсик всю жисть был процедурным языком, многих это в нем и привлекает (к примеру меня), а кому уж надо ООП, те и выбирают соответствующие языки

Полностью согласен и голосую "за" двумя руками

Вот именно это я и имел в виду, когда утверждал что ооп в freebasic не будет принят.
А копирование vb.net этого точно не будет.

Мне очень хочеться событий, причём желательно уже вчера.

Событие по таймеру.
on tymer

Может ещё какие-нибудь, более новые.

А также пользовательские.

Чтобы можно было создать своё событие и его инициировать.

А ещё чтобы можно было повесить функции на событие. Желательно в нутри класса.

Помните, как в vb6
sub form_load()
end sub

sub command1_onclick()
end sub

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

Хочеться, реализации потоков.

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

Потоки например есть при работе с консолью inkey, print и т.п.

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

Хотелось бы компиляцию с учётом текущей локализации О.С.

Если компильнуть исходник в utf-16 то выведуться нормальные национальные символы.
А если исходник бутет в ascii, то будут либо закарючки либо вопросики.

Я думаю, если учитывать текущую кодировку операционной системы и в соответствии с ней конвертировать ascii в unicode то не будет проблем с выводом национальных символов.

ShenZN пишет:
Это конечно хорошо, но а с другой стороны плохо. Не стоит копировать полностью С/С++, нужно брать из них лучшее. А то получится тот же С но с синтаксисом Basic. В ФБ уже намечается такая проблема, плюс еще реализовывается куча разных функций которые, заменимы и повторяют в какой то степени друг друга. На мой взгляд, язык программирования должен быть не перегружен различными функциями "на каждый день", а иметь весь минимальный набор средств для профессионального программирования. А дополнительные функции стоит реализовывать отдельно.

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

Но тут ещё нужно различать, какой это язык. Есть языки компилируемые и есть интерпретируемые.

Компилируемый язык должен иметь мощную структуру, удобный синтаксис и поддержку инлинеасм. Всё же остальное являеться наворотами. В т.ч. всякие print и cls. Это уже можно считать дополнениями, и спокойно подключать с библиотекой. Как сделано в c и c++.
На таком языке можно писать что угодно, от операционки, до игрушки.

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

Бэйсик же, находиться где-то посредине. Давайте возьмём наш фрибэйсик. Он был изначально задуман как компилятор программ сделаных на qbasic. Правильно ведь?
А кубасиц, точто так же как и его предшественники gwbasic и abasic, и ещё более ранние были именно интерпретаторами!
Весело получаеться! Компилятор интерпретируемого языка.
Впрочем уже сам qbasic в старших версиях умел компилить проги. А про visual basic я вообще молчу.

Так вот фича получилась такая, что необходимо делать компилятор, при этом закладывая в него функции. Как я понимаю pascal и delphi пошли тем же путём.
Ну чтож.. Остаёться лиш думать, куда поместить ту или иную функцию. А может быть вообще всё вынести в библиотеки, как сделано в c?


Ладно, теперь о синтаксисе. Я собственно открыл эту тему, желая высказаться по конкретному вопросу.
А хочу я ничто иное, как конструкцию switch. Именно ту которая в C. Хотя даже наверное лучше вариант из php, как более близкий к бэйсику.
Есть конечно конструкция select case, у неё есть свои плюсы и есть свои минусы. В прочем достаточно разветвлённое if ... then даёт многое. Но теперь вот смотрим такой код:

Код:


switch a
case 0
b = 10

case is 1 to 9
d = a
break

default
print "error"

end switch


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

Код:


do

if a = 0 then
b = 10
end if

if (a >= 0) and (a <= 9) then
c = a
exit do
end if

print "error!"
loop while 0


Я уже не раз пользовал такой фокус. Но ведь он далеко не всегда удобен. А разрыв петли exit do нельзя считать допустимым приёмом.

Помниться в qbasic был on goto (expr). Не помню точно. Но суть в том, что если условие выполняеться, то происходит переход на какую-то строку. Это было альтернативой switch.

А я вот сегодня портировал один сишный исходник, и наткнувшись на switch очень громко ругался матом. Потому, что пришлось ломать очень красивый код, в крайне нелепую конструкцию. Так что вот.

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

А чем не устраивает Select Case, чем она хуже Switch:

Код:

switch a
case 0
b = 10
break

case is 1 to 9
d = a
break

default
print "error"

end switch

Аналогичная функция ФБ:

Код:

Select Case a
Case 0
    b = 10
Case 1 To 9
    d = a
Case Else
    print "error"
End Select

Вот именно, что break. Ты добавил один и вся суть изменилась!
Твоя программа будет уже работать совсем не так как задумано.

switch
case 1

' код выполняеться пока не встретиться break или end switch.

А в бэйсике, пока не встретиться другое case или end select.


Повторюсь, всё это можно переложить на basic, но будет уже не то.


Я показывал пример, чтобы его переложить на basic нужно писать так:

Код:


select case a
case 0
b = 10
c = a

case 1 to 9
c = a


case else
print "Error!"

end select


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

А реализовать такой код на FreeBasic можно так
примерный код на c:
switch a
case 0
b = 10
break
case is 1 to 9
d = a
break

default
printf ("error")

end switch

код на FreeBasic:
dim a as integer
select case a
case 0
b = 10
exit select
case 1 to 9
d = a
exit select
case else
print "error"
end select

во FreeBasic уже давно есть ключевые слова
Exit Select
Exit While

поповоду реализации такой штуки как:
case 1 to 10
конечно оно удобно, в маленьких диапазонах, но на асме это FreeBasic выдает примерно так:
cnp a,1
jmp ppp
cmp a,2
jmp ppp
cmp a,3
jmp ppp
cmp a,4
jmp ppp
cmp a,5
jmp ppp
cmp a,6
jmp ppp
cmp a,7
jmp ppp
cmp a,8
jmp ppp
cmp a,9
jmp ppp

ppp:

как вы видите, идет проверка всех чисел от 1 до 9. представьте какой код получится если написать так:
case 1 to 10000

правильней будет такой код написать так:
dim a as integer
dim d as integer
input"enter number",a
select case a
case is < 10001 and a > 0
d = a
print d
case else
print"error"
end select
sleep

небойтесь экспериментировать, порой во FreeBasic можно извратиться.

ну я и обманьщик!!! развел тут демагогию по поводу:
case 1 to 10000
ведь сунулся специально посмотреть, а ведь разработчики не дураки, нет там 10000 тысячь жампов. видимо я спутал это вот с таким примером
case 1,21,69,47,888,58763
тут действительно будет так, несколько жампов.
прошу прощение за введение в заблуждение, можете писать хоть:
case 1 to 1000000
причем судя по асмовскому коду, это будет быстрее, чем то что я предложил в предыдущем примере.
теперь по поводу "exit select". вроде он тоже не нужен, тоесть нужен, но не в случае с нашим примером,
приведу примеры:
код на FreeBasic
dim a as integer
dim b as integer
dim d as integer
select case a
case 0
b = 10

case 1 to 9
d = a

case else
print "error"
end select

код фрибейсиковского ассемблера с переводом на FreeBasic:
mov dword ptr [ebp-8], 0 'dim a as integer
mov dword ptr [ebp-12], 0 'dim b as integer
mov dword ptr [ebp-16], 0 'dim d as integer
mov eax, dword ptr [ebp-8] 'запишем в регистр eax, переменную a
mov dword ptr [ebp-20], eax ' select case a
cmp dword ptr [ebp-20], 0 'case 0
jne .Lt_0005 'если неравно переходим на следующий case
.Lt_0006:
mov dword ptr [ebp-12], 10 'b = 10
jmp .Lt_0003 переходим не на следующий case a за end select
.Lt_0005: 'следующий case
cmp dword ptr [ebp-20], 1 'case 1
jl .Lt_0007 'если меньше 1, то переходим на следующий case, в данном случае case else
cmp dword ptr [ebp-20], 9 'to 9
jg .Lt_0007 'если больше 9, переходим на следующий case, в данном случае case елсе
.Lt_0008:
mov eax, dword ptr [ebp-8] 'запишем в регистр eax, переменную а
mov dword ptr [ebp-16], eax 'd = a
jmp .Lt_0003 'переходим на метку за end select
.Lt_0007: 'case else
push 1
push 5
push offset _Lt_000A
call _fb_StrAllocTempDescZEx@8
push eax
push 0
call _fb_PrintString@12 'выводим нашу строку с errorом
.Lt_0009: 'end select
.Lt_0003: 'метка после end select

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

Электрик... Ну ё-моё! Как раз нужен скочёк на следующую.
В том-то вся шутка, чтобы из select case выходил, тогда, когда хочу этого я, а не freebasic.
Он сейчас отрабатывает только один контейнер.
А в си, обрабатывает все пока не наткнётся на break. Там case ближе к асму. Можно сделать, хоть так

Код:


switch(oneChar)
{
case "0";
case "1";
case "2";
case "3";
case "4";
case "5";
case "6";
case "7";
case "8";
case "9";
case "a";
case "b";
case "c";
case "d";
case "e";
case "f";
printf( "от 0 до 9 или от a до f");
break;

default:
printf("недопустимый символ");

}


огромная просьба к народу общающимся с разработчиками FreeBasic.
очень бы хотелось поиметь препроцессор команды ключей компиляции. например:
#compile gui
#compile dos
или вот так:
#compile win, gui, dll, profile
#arch 586

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

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

да возможно, но мне это надо, чтоб батники не писать, мне проще
#compile gui, dll
а специфические параметры можно приподнести с командной строки.

еще хотелось бы расширенных макро команд уровня компилятора,чтоб продвинутый программер, мог тоньше оптимизировать свой код.
вот приведу пример из flatassemblerовского макроса
macro invoke proc,[arg] ; indirectly call STDCALL procedure
{ common
if ~ arg eq
reverse
pushd arg
common
end if
call [proc] }
этот макрос работает так, как мы работаем с FreeBasic функцией
test(a,b)
invoke test,a,b
тоесть он сканирует все введенные параметры командой reverse, и делает соответствующее действие в данном случае запихивает в стек параметры нашей функции, короче макрос принимающий нефиксированное число параметров.
такого во FreeBasic к сожлению нет.
также не хватает, проверка на тип данных, виртуальные функции, чтоб в процессе компиляции что-то расчитал, записал в переменную, а в бинарник эту функцию не компилил. парсер строк написанного кода, вобщем типа компилятора в компиляторе.

Я поддерживаю электрика.
Ключи в консоли это дополнительные проблемы.
Например подключение файла ресурсов, было бы проще через препроцессор.
#resource "dialog.rc"
или даже
#icon "app.ico"

Мне fasm понравился тем же. Там вообще ассемблеру нужно указать только исходник, а всю нужную инфу он возьмёт из самого кода.

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

А если я например в своей проге юзаю win api? то мою прогу только с ключом -s gui и можно компилить.


Опять же я уже писал, о том, что freebasic должен уметь читать исходники с национальными символами.
Почему бы не добавить ключ который будет указывать кодировку.
#encode "windows-1251"
И тогда символы в консоль будут уже коректно выводиться. А некоторым извращенцам не придёться исходники писать в кодировке cp866 (dos).
Опять же это идея не новая. Подобное кажеться есть в Python.

Дальше, как я понимаю, freebasic? в rtlib использует внутренний тип строк fbstring, и как я понял это wchar символы для linux и windows.
А значит можно зделать string с символами не 8-бит, а с поддержкой юникода.


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


Вот я создал объект или зарезервировал память в теле процедуры.

Код:


sub  mifunc()
dim obj1 as class1 ptr
obj1 = new class1()
...
end sub


Но мне эту память обязательно нужно высвободить.

Код:


...
delete obj1
end sub


Я же предлагаю позволить компилятору самому дописать. Или даже лучше пусть некая функция делает это автоматически.

Например организуеться три списка.
temp - для временных.
function - для функций и процедур.
object - для объектов.

В моём случае, указатель obj1 должен быть помещён в список для function.

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

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

ну незнаю, по мне проще написать make (в котором я все распишу, что как компилится) чем fbc -x proga src1.bas src2.bas src3.bas <и еще 35 файлов>
но ет лично мое мнение

В принципе да. Но где эта утилитка для freebasic'а?
Как её пользовать под windows?
Да и синтаксис самого makefile оставляет желать лучшего. Но на счёт чсинтаксиса нужно смериться, поскольку это уже стандарт.

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

Принимаются все пожелания и критика.

Я бы хотел наследование... А то как-то не врубаюсь, как в Фб сие действо происходит...

А наследования-то и нету. Также как нету и полиморфизма.
Хотя это можно сделать, но выйдет очень извращённо.
Я бы тоже хотел, чтобы fb был полностью объектноориентированным.

Eric-S пишет:А наследования-то и нету. Также как нету и полиморфизма.
Хотя это можно сделать, но выйдет очень извращённо.
Я бы тоже хотел, чтобы fb был полностью объектноориентированным.

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

ну после нового релиза(.22) проблему "чтоб case как в Си был" решить очень легко, благодаря вариадическим макросам... что-то типо этого:

Код:


#Macro __CASE( foo... )
Asm
   jmp 0f
End Asm
   Case foo
Asm
0:
End Asm
#EndMacro

Dim i As Integer = 10
Dim j As String = "hj"
   Select Case i
      Case 10
         ? i
      __CASE(9)
         Select Case j
            Case "hj"
               ? j
            __CASE("d")
               ? "d"
            __CASE(else)
               ? "else in 9"
         End Select
      __CASE(7)
         ? "7"
      __CASE(Else)
         ? "else"
   End Select

Sleep


и будет:
10
hj
d
else in 9
7
else

Минусы - необходимость скобок, и жестко меняется алгоритм проги... за это по головке могут и не погладить(вплоть до увольнения)..

Почему бы не добавить ключ который будет указывать кодировку.
#encode "windows-1251"

было бы совсем неплохо.. хотя и сохранение в уникоде никто не отменяет.. это было в питоне, а в перле.

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

Сборщик мусора можно и программно организовать.. да и в некоторых случаях, к примеру в критичных к времени, использование его будет во вред.. но для простых приложений это даа.. это надо.. к примеру не всегда знаешь, сколько реально использутся объектов, а сколько случайные копии и/или типо того. ЛУчше сделать в виде отдельной библиотеки или процедуры в RTL. Imho.

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

Ладно, вечером, может допишу..