That's why I work with different onesFred wrote: Every languages have its pro and con, just fit with the one which fits your needs now, not in a few months or year.
Purpose of PureBasic
and we all know fred will appreciate our interests and comments...
<slime mode off>
now, where was that wishlist...
<slime mode off>
now, where was that wishlist...
( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB - upgrade incoming...)
( The path to enlightenment and the PureBasic Survival Guide right here... )
( The path to enlightenment and the PureBasic Survival Guide right here... )
I think C strings are faster in general and above all when we have to deal with WinAPI as the language itself must not do silly conversions (WinAPI functions need always a string pointer to be passed). Personally I'm fine with using memory banks even for storing strings, but I think it'd be easy to do a PB-Lib or functions to handle strings in memory banks as if they were normal strings. If I am not wrong, there is also a system DLL for things like large arrays and strings.
PS: Large strings or variant type like used by VB can be nice, but depending of what you're doing, you could need much more work. For example some time ago I had to write a DLL (in C) for a VB program (not done by me) and the VB application had to pass some text to my DLL.
Of course it couldn't pass VB strings (as they've a weird format) , so the only fast way was to pass a buffer of an array ( -> buf(0) ). That is annoying as the VB application had to read all the values from buffer and
then storing them in a string and vice-versa, each time it had to call my fucntion. 8O
PS: Large strings or variant type like used by VB can be nice, but depending of what you're doing, you could need much more work. For example some time ago I had to write a DLL (in C) for a VB program (not done by me) and the VB application had to pass some text to my DLL.
Of course it couldn't pass VB strings (as they've a weird format) , so the only fast way was to pass a buffer of an array ( -> buf(0) ). That is annoying as the VB application had to read all the values from buffer and
then storing them in a string and vice-versa, each time it had to call my fucntion. 8O
-
Edwin Knoppert
- Addict
- Posts: 1073
- Joined: Fri Apr 25, 2003 11:13 pm
- Location: Netherlands
- Contact:
VB does not have a 'weird' format, MS simply implemented BSTR's .
The only odd part to this is that VB is in unicode but passes strings converted to ANSI.
If you speak about weird, C is weird since no compatible string version is present (AFAIK) and a BSTR wrapper must be implemented.
I urge program languages like PureBasic to implement strings as BSTR.
They are useful since they contain info about there real length.
Not some mod length.
They can be used with VB transparent, if you create dll's having functions AS STRING (VB will delete the passed BSTR)
And a limit of 64k is imo a very odd limit, BSTR can be as large as Windows offers.
If PureBasic holds the memory in scope, it can do exactly the same with BSTR handles.
The only odd part to this is that VB is in unicode but passes strings converted to ANSI.
If you speak about weird, C is weird since no compatible string version is present (AFAIK) and a BSTR wrapper must be implemented.
I urge program languages like PureBasic to implement strings as BSTR.
They are useful since they contain info about there real length.
Not some mod length.
They can be used with VB transparent, if you create dll's having functions AS STRING (VB will delete the passed BSTR)
And a limit of 64k is imo a very odd limit, BSTR can be as large as Windows offers.
If PureBasic holds the memory in scope, it can do exactly the same with BSTR handles.
10-4!Rings wrote:confirm !Fred wrote:I read all the comments and early time users can confirm than a lot have been implemented. Still a lot missing, but hey, it's coming.
AMD Athlon XP2400, 512 MB RAM, Hercules 3D Prophet 9600 256MB RAM, WinXP
PIII 800MHz, 320 MB RAM, Nvidia Riva Tnt 2 Mach 64 (32MB), WinXP + Linux
17" iMac, 1.8 GHz G5, 512 MB DDR-RAM, 80 GB HD, 64 MB Geforce FX 5200, SuperDrive, OSX
Fred, I agree with everything you say except this bit: 
Maybe, as a learning exercise, or a bit of fun writing a simple game.
But not if you want to use the application long term.
I have several megabytes of source code comprising about 30 applications written over many years. I cannot re-write all this stuff every few months, and I don't want to re-write it every time Microsoft changes the OS.
Thus my ideal compiler would:
1) Allow the application to be written in high level language.
2) Not require unsupported 3rd party functions.
3) Be similar to comparable languages to allow easy conversion.
Fred cannot be expected to include the entire Windows API in PureBasic, it's just too large. But the fundamental stuff should be included by now. For example, I don't expect to need an API function to draw a 2 pixel wide line in 2D graphics. I don't expect to require 3rd party functions to do accurate arithmetic. I'd like to access the computer's ports using simple PB commands. These things you could do on a primitive machine with a Basic interpreter in a 16k ROM !!
If software only has a lifetime of a few months is it worth the effort?Fred wrote:just fit with the (language) which fits your needs now, not in a few months or year.
Maybe, as a learning exercise, or a bit of fun writing a simple game.
But not if you want to use the application long term.
I have several megabytes of source code comprising about 30 applications written over many years. I cannot re-write all this stuff every few months, and I don't want to re-write it every time Microsoft changes the OS.
Thus my ideal compiler would:
1) Allow the application to be written in high level language.
2) Not require unsupported 3rd party functions.
3) Be similar to comparable languages to allow easy conversion.
Fred cannot be expected to include the entire Windows API in PureBasic, it's just too large. But the fundamental stuff should be included by now. For example, I don't expect to need an API function to draw a 2 pixel wide line in 2D graphics. I don't expect to require 3rd party functions to do accurate arithmetic. I'd like to access the computer's ports using simple PB commands. These things you could do on a primitive machine with a Basic interpreter in a 16k ROM !!
@Edwin:
What's weird on a C string ? It's a simple pointer to a NULL terminated sequence of bytes. Most WinAPI calls need such a pointer.
VB has its own format to handle strings, have you ever tried to get a pointer to the 1st character of a string in VB ? Well.. good luck ! That is something you could need if you aren't just an ugly database programmer in VB.
You could easily develop your own string type and set of fucntions in PureBasic to handle strings larger than 64KB if you need. Though strings are not meant for that, so I prefer the fast C way as default.
What's weird on a C string ? It's a simple pointer to a NULL terminated sequence of bytes. Most WinAPI calls need such a pointer.
VB has its own format to handle strings, have you ever tried to get a pointer to the 1st character of a string in VB ? Well.. good luck ! That is something you could need if you aren't just an ugly database programmer in VB.
You could easily develop your own string type and set of fucntions in PureBasic to handle strings larger than 64KB if you need. Though strings are not meant for that, so I prefer the fast C way as default.
-
Edwin Knoppert
- Addict
- Posts: 1073
- Joined: Fri Apr 25, 2003 11:13 pm
- Location: Netherlands
- Contact:
I also mentioned some benefits.
VB internally uses BSTR but in unicode format (that's the answer on your string pointer)
During passing BSTR to API's it's converting the strings to ANSI.
If PureBasic supports BSTR, it can simply use the ANSI format, i have tested this already.
The BSTR is exchangable between VB and PB then.
In the near future, when you mess a little bit more with com interfaces you'll see that BSTR is required either.
So why keep struggling with other types?
Imo, it would be a serious error not to use BSTR for Strings as return value in (exported) functions.
For PureBasic internally it's just another type of handle.
VB internally uses BSTR but in unicode format (that's the answer on your string pointer)
During passing BSTR to API's it's converting the strings to ANSI.
If PureBasic supports BSTR, it can simply use the ANSI format, i have tested this already.
The BSTR is exchangable between VB and PB then.
In the near future, when you mess a little bit more with com interfaces you'll see that BSTR is required either.
So why keep struggling with other types?
Imo, it would be a serious error not to use BSTR for Strings as return value in (exported) functions.
For PureBasic internally it's just another type of handle.
-
Edwin Knoppert
- Addict
- Posts: 1073
- Joined: Fri Apr 25, 2003 11:13 pm
- Location: Netherlands
- Contact:
Your remark about 0-terminated strings has no concern.
ANY type of memory in Windows adds one or more padding zeros.
I mentioned the exact length determination since a good api is available for that.
HeapAlloc() and HeapSize() do not return desired length but a length including some added characters.
That's the difference.
ANY type of memory in Windows adds one or more padding zeros.
I mentioned the exact length determination since a good api is available for that.
HeapAlloc() and HeapSize() do not return desired length but a length including some added characters.
That's the difference.
right on!Kale wrote:Agreed!TronDoc wrote:dittoLarsG wrote:10-4!Rings wrote:confirm !Fred wrote:I read all the comments and early time users can confirm than a lot have been implemented. Still a lot missing, but hey, it's coming.
( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB - upgrade incoming...)
( The path to enlightenment and the PureBasic Survival Guide right here... )
( The path to enlightenment and the PureBasic Survival Guide right here... )
Yup.blueznl wrote:right on!Kale wrote:Agreed!TronDoc wrote:dittoLarsG wrote:10-4!Rings wrote:confirm !Fred wrote:I read all the comments and early time users can confirm than a lot have been implemented. Still a lot missing, but hey, it's coming.
... this is getting weired
Timo
quidquid Latine dictum sit altum videtur