Powerbasic Museum 2020-B

Webmaster: José Roca (PBWIN 10+/PBCC 6+) (SDK Forum) => Discussion => Topic started by: Theo Gottwald on January 23, 2012, 08:21:24 AM

Title: Wishlist for a new PB Version?
Post by: Theo Gottwald on January 23, 2012, 08:21:24 AM
While PB 10 is my absolute NR.1 programming tool, there are always some wishes open for a new version.
So why not start a new wishlist and/or opinion thread?  So here is a start from me.

PB 10 did a lot about COM Objects and UNICODE which was a milestone in the right direction.
The new PB-Editor is leapyears ahead of older versions.  And i believe that it got really good finally.

However the principles that all builtin commands are "as fast as possible" have come a little bit under the wheels,
when we talk about PowerCollections, LinkedLIsts, Stack, Que and such.

Their problem with actual version for me is that they are (very versatile) based on VARIANTS and on UNICODE (Ex-VB 6 programmers will love it that way),.
Which definitely makes them slower then dedicated datatypes. Because the conversion need time on any acess..

Stan Durham shows the right way with his high-speed datatypes (http://www.powerbasic.com/support/pbforums/showthread.php?t=49250) and Arrays. At least for my programming style.

This would also be a nice completion of the PB ARRAY-Functions:
PB-Forum Stan's Array-Macros (http://www.powerbasic.com/support/pbforums/showthread.php?t=49250)

We have now PowerArrays, is somebody here using them?
They also look like they are slower then the native PB Arrays.

Some Additions for the native PB-Arrays like Stans Macros  above ( the Redimming can be optimized), would be my idea of an improvement.

These datatytpe are less versatile but much faster. For me, new VARIANT Objects are not what i would need.
I prefer very fast low-lever things, which i can use to build whatever i need.

Then i would wish the new HSTRING datatype (best in a PB x64). And some expansions in MACRO abiilities.
And a bit more flexibility with the META-Statements #IF #ENDIF (higher possible nesting depth).

Also i believe that there are minor adjustments in the already fine Dead Code Removal possible.
When it comes to static variables.

And i beliefe that the Editor should be further imporoved. He's already a fine tool, but is also the place where the distance to competitors is still the largest.

Thats my PB 11 wishlist for now. Now what your opinion.
Title: Re: Wishlist for a new PB Version?
Post by: José Roca on January 23, 2012, 10:18:35 PM
Quote
We have now PowerArrays, is somebody here using them?

Yes. They are safe arrays, and like collections, are meant to be used with COM, not as substitutes of normal arrays. Safe arrays are used to pass/receive information to/from Automation languages that don't have the slightest idea of what a PB normal array is, and collections are meant to pass or receive several object references at once, not to build an indexed array of the words used in the bible. Use the tools correctly and don't expect a car to fly. If you need to fly, use a plane.
Title: Re: Wishlist for a new PB Version?
Post by: Peter Weis on January 23, 2012, 10:19:50 PM
Hello Theo
would wish me things like direct assignment of variables!

    Local x as integer = 7
    dim x as long = 5


in addition ASM blocks

Asm
    Mov ax, 2
    Mov bx, 3
end asm

to me breaks in however still much! But is enough only once!

Greet Peter

Title: Re: Wishlist for a new PB Version?
Post by: José Roca on January 23, 2012, 10:26:35 PM

in addition ASM blocks


You already have


PREFIX "ASM"
   Mov ax, 2
   Mov bx, 3
END PREFIX


Nobody reads the help file?
Title: Re: Wishlist for a new PB Version?
Post by: Peter Weis on January 23, 2012, 10:37:23 PM
Hello Jose,

I does not need thousand new instructions, which I will never take ago in my life! It may be already safe these instructions is safe, and the life to facilitate! Only one loses of it the overview! It would be whom for example power basic the pointer type not as DWORD to return beautifully would separate with the name then would give it also no problem hereby with transferred to 64 bits


type test1
    Var1 as integer
    Var2 as long
end to type

Function testxxx () as test1
    Local x as test1
    Function = x
end function



greetings Peter
Title: Re: Wishlist for a new PB Version?
Post by: José Roca on January 23, 2012, 11:09:59 PM
Quote
type test1
    Var1 as integer
    Var2 as long
end to type

Function testxxx () as test1
    Local x as test1
    Function = x
end function

Code like this would only work only with PB, and then you will complain that your DLL that has such function does not work with other compilers. It already happens with languages such C++, Delphi and GCC, and have to use structures passed by reference if they want to be compatible with other languages. Why? One makes the structure static and returns a pointer to it, but only if is more than 16 bytes long; otherwise, it returns the values into the stack; others use other ways, that are incompatible between them. PB can return an structure as the result of a method or property because COM sets the rules and a compiler that is COM compliant must follow them.

So, which of the three or more incompatible ways of returning an structure as a result of a function has to be implemented? And how to know which one is using the DLL written with another language? Or perhaps Mr. Zale has to use one that is incompatible with all the others?

If you need a workaroud for PB, here is one:


#COMPILE EXE
#DIM ALL

type test1
    Var1 as integer
    Var2 as long
end type

Function testxxx () as string
    Local x as test1
    x.Var1 = 123
    x.Var2 = 345
    Function = x
end function

FUNCTION PBMAIN

   LOCAL t AS test1
   TYPE SET t = testxxx
   ? STR$(t.Var1) & STR$(t.Var2)

END FUNCTION

Title: Re: Wishlist for a new PB Version?
Post by: Peter Weis on January 24, 2012, 10:43:05 AM
Hello Jose,
meant handing over byref! ," parses by ref" Und I was concerned about the dword! It is clear for me variable must on global Heab has to go! 

Example:


type test1
    Var1 as integer
    Var2 as long
    var3 as string * 20
end type

Global x as test

Function xyz() as dword
       x.Var1 = 10

       Function = varptr(x)   'parse by ref
End function



greetings Peter
Title: Re: Wishlist for a new PB Version?
Post by: José Roca on January 24, 2012, 10:52:54 AM
It looks like some people can't write anything without use globals. This example does not use any global variable.


#COMPILE EXE
#DIM ALL

type test
    Var1 as integer
    Var2 as long
    var3 as string * 20
end type

SUB xyz(BYREF x AS test)
   x.Var1 = 10
END SUB


FUNCTION PBMAIN

   LOCAL t AS test
   xyz(t)
   ? STR$(t.Var1)

END FUNCTION


Title: Re: Wishlist for a new PB Version?
Post by: José Roca on January 24, 2012, 10:57:50 AM
BTW have you tried my example on post #5? As strange as it looks, you can return an structure as the result of a function if you declare the result of a function AS STRING. And you can do it by simply using FUNCTION = <structure name>, without doing any conversion. Certainly, then you have to use TYPE SET to assign it to a new structure, but that's all.
Title: Re: Wishlist for a new PB Version?
Post by: Theo Gottwald on January 24, 2012, 11:34:57 AM
I always return structures from subs or functions, just have them BYREF as parameters.
About SafeArrays, you are of course right Jose. They are good for compatibility.
However i could imagine a addition for optional parameters:

SUB XYZ(OPT BYVAL A01=7 AS LONG)

or something liek that so i could give optional values a predefined value.
Title: Re: Wishlist for a new PB Version?
Post by: Charles Pegge on January 24, 2012, 12:27:11 PM

Developing default parameters for OxygenBasic I found it easier to adopt the C habit of placing the type before the parameter name. Then you get nice clean syntax for expressing default values:


function foo(string s="Hello", int *i=123)
print s+"   "+i
end function

'examples

foo
foo "Hi",1
foo s="Bye"
foo i=456
foo (i=789, s="Bye")



(note that 's' is passed Byval and i is passed Byref as indicated by '*i')

Charles
Title: Re: Wishlist for a new PB Version?
Post by: Edwin Knoppert on January 24, 2012, 02:27:24 PM
Local scope would nr #1 for me like:
Function Hello()

dim a as long

a = 100
{
    dim a as int
    a = 123
}

? a (=100)

--

Direct assignment of vars (as above mentioned)
dim a as long = 100

--

Removal of the naming conflicts, conflicts which seem to occure by hidden (PB) macro's or so..

--

Swap DDT for real SDK windows.
Title: Re: Wishlist for a new PB Version?
Post by: Peter Weis on January 24, 2012, 03:22:20 PM
Hello Jose,

I already read it! Are however function a fan! Me it goes however around larger structures which one no more than value returning can!
In all other respects the C, c++, knows and Freebasic also. Even with Visualbasic that can be done!

Greet Peter
Title: Re: Wishlist for a new PB Version?
Post by: Peter Weis on January 24, 2012, 03:57:27 PM
Hello Theo,
that was my idea. ;D


SUB XYZ(OPT BYVAL A01=7 AS LONG)

I would continue to go however still another step!


Sub xyz(opt byval x as long = 7, opt byval y as long = 10, opt byval z as dword)

end sub


xyz y:=5, x:=Var         ' Call



or


xyz y=5, x=Var


;D
Greet Peter

Title: Re: Wishlist for a new PB Version?
Post by: Paul Elliott on January 25, 2012, 07:47:31 PM
Something does not make sense with the way you are using Optional parameters.

If you are making a call that has optional parameters  WHY would you want to pass a default
value? If you are passing a variable or a value then that is what is passed and therefore
that parameter HAS a value and is not missing/optional for this particular call.

It is the procedure itself which should be assigning default values to optional parameters that
are not passed. If the procedure has defined the optional parameters as BYVAL then the only
way to tell if it is absent for numeric variables is if it is equal 0  or for strings if it is 0 len.
If the procedure has defined the optional parameters as BYREF then it needs to check for a
valid variable address BEFORE using it.

Title: Re: Wishlist for a new PB Version?
Post by: Peter Weis on January 25, 2012, 10:23:01 PM
Hello Paul,
Es stands in addition, who it is to only transfer the value to parameter list whom it in the call does not stand! Dan makes it already a sense!

sample:

sub testx(opt a byval x as long = 10)

end sub

call testx()

call testx(0)



The compiler can differentiate that with to compile.

Perhaps did it now understand?

Greet Peter
Title: Re: Wishlist for a new PB Version?
Post by: Paul Elliott on January 25, 2012, 11:36:28 PM
Peter,

I'm not sure I understand. But it seems that you are asking the compiler to do all the checking
that the programmer would have to do to figure out if an optional parameter is there or not.
And if not then to supply the requested default value.

If that is the case then you will never be able to over-ride any passed parameter. No more using
Byval or Byref on the Call statement. The compiler can not see every call at compile time. What if
the call happens between a main program and a dll?

It's much simpler if the programmer takes care of it all.

But if you want to ask for that then go ahead. As long as it is an option that can be turned OFF
so that the programmer can decide what to do.

Title: Re: Wishlist for a new PB Version?
Post by: José Roca on January 26, 2012, 12:08:38 AM
Paul,

Is much simpler than that.

For example:


SUB MySub (BYVAL x AS LONG, OPTIONAL BYVAL y AS LONG = 10, s AS STRING = "My string")


If you call it as MySub(x), it will be equivalent to calling it as MySub(x, 10, "My string")

It's useful for omiting default values when they are different to 0 or "". Many third party libraries written in C++, and also methods of COM servers, use it and in our translations to PB we have to made them not optional or write wrappers.
Title: Re: Wishlist for a new PB Version?
Post by: Theo Gottwald on January 26, 2012, 10:55:52 AM
Quote from: Edwin Knoppert on January 24, 2012, 02:27:24 PM
Local scope would nr #1 for me like:
Function Hello()

dim a as long

a = 100
{
    dim a as int
    a = 123
}

? a (=100)

--

Direct assignment of vars (as above mentioned)
dim a as long = 100

--

Removal of the naming conflicts, conflicts which seem to occure by hidden (PB) macro's or so..
Swap DDT for real SDK windows.


"Local scope " - a Sub inside a Sub?
As the concept is new to me, i have not really an idea what its good for, but i beliefe that this would be easy to do and sounds intresting.

Direct assignment of vars (as above mentioned)

Yes i think thats a good idea. If i remember it right, first steps into this direction have already been done with PB 10.
I think we can already assing some things ... just forgot which.

Removal of the naming conflicts, conflicts which seem to occure by hidden (PB) macro's or so..

Do you have an working example for that?

Swap DDT for real SDK windows.

If so i would prefer Jose's CWindows because its UNICODE and dpi-aware and has anything that a modern up-to-date concept needs.
And add Firefly 3.5 to the package :-). Oh no this will never happen ....  ;D
Title: Re: Wishlist for a new PB Version?
Post by: Peter Weis on January 26, 2012, 12:56:36 PM
Hello Theo,
peek there once. Perhaps it helps you!

SCOPE FreeBasic

http://www.freebasic-portal.de/befehlsreferenz/scope-362.html

greetings Peter
Title: Re: Wishlist for a new PB Version?
Post by: Paul Elliott on January 26, 2012, 01:28:00 PM
I think I'll stick with doing my own default assigns for optional parameters.
That way it is very clear exactly what is being done in every instance.

I don't really feel a need to force PB to be like some other language.
I easily move between several languages and am able to use the standards
of each.


Title: Re: Wishlist for a new PB Version?
Post by: Edwin Knoppert on January 26, 2012, 08:09:27 PM
Local scope is used in c languages

if(a==1)
{

}

Everything inside the {} is a scope.
In PB it could be very helpful with com objects, instead of releasing them manually (if needed for your function) you can let those out of *local* scope.
Imagne a common problem, instantiating a com interface in PBMain and then show a modal form.
The com interface may have not being needed at that point but is still alive.
Local scope could help/teach the programmer to program differently.

In .net there is using() which i also think works nice.
using(Interface1 x =  New Interface1())
{

}

Same stuff (besides the using invokes the dispose() method but that's extra.
I am talking about behaviour as well here.

>Removal of the naming conflicts
No but PB has nowadays much more internal keywords which conflict if you try to use the same one.
To me it lacks the relevance to have those (often obvious) keywords, the compiler should not care for me using keywords not being part of the PB BASIC language or winapi declares.
I heard these may be macro's, i don't care, get rid of those, i don't conflict with the language, the language conflicts with me!
Title: Re: Wishlist for a new PB Version?
Post by: Peter Weis on January 26, 2012, 08:37:01 PM
Hello,

the next that I gladly would like are pre-defined types

sample

type test
    a as long = 5
    b as string * 5 = "Test"
    c as dword
    e as long
end type



greetings Peter
Title: Re: Wishlist for a new PB Version?
Post by: Theo Gottwald on January 27, 2012, 10:01:03 PM
While PB 10 has it all (except x64, and maybe the ability to write Kernel drivers), you can do nearly anything with it.
Yet there is always something to improve. And think about a new version.
However, from my experiences in the past i assume that it wont be before 2015 when we get it :-(.
We will not pay it in EURO that time, maybe we'll pay it in GOLDMARK then.
Title: Re: Wishlist for a new PB Version?
Post by: José Roca on January 28, 2012, 09:08:55 AM
Angela has already destroyed the EU. She has spent years rejecting all kind of decisions only to accept them when it was already too late. All that remains in common in the eurozone is the euro, and only because we are all trapped in it.
Title: Re: Wishlist for a new PB Version?
Post by: Theo Gottwald on January 29, 2012, 10:46:20 AM
Jose,
Angela is not the reason of what you are facing. Long years before the plans for the end of the EURO (is in MID 2014) have already been made.
Most of those who knew the exact date have dissapeared.  ;D
Whatever Angela can do is far beyond what would have been necessary to save the EURO.
She can move around but the strikes on the euro come from over the atlantic.
One of these strikes was that they moved Greece into the euro, which was a false decision at any time.
It was only possible with the false certificates from G+S.
Next they prevent Greece from getting Oil from Iran (for credit), which strengthens the problems there.
Angela has a small country with people paying taxes up to 75%. What can she really do?
She has sold out already anything thats there.
And if she would have got the German GOLD (which is German only on the paper, and is in fact in USA for long time), she would have sold that also.

PS: Today good reaction times here.