Needed : Conversationtool PureBASIC2PowerBASIC

[newtheogott]

I am used to the Powerbasic string-lenght of 2000 E6.

So long the string-lenght problem in Purebasic is not solved,
all the nice 3 D Features cannot make me to switch to a more C-like Syntax.

Its now a long time that i am a licenced Purebasic-userm, but when I need to write a quick Programm, I find myself using Powerbasic,
and watching my decision carefully, the most important point is the string length.

Since my old Atari 400 times, I store data in strings, thats BASIC .
In Purebasic I have to use AllocMem etc. and I cannot use the string-operations on this memory.

So I'll carefully watch the Purebasic developement, maybe one day there is a good reason to change. However it wont be the support for a new 3D_API, it must be a quick look in an empty "Bug-Forum" and there should be a support for BASIC-Strings longer then 16 bit.

Lastly, any discussion if Pure or Powerbasic is faster is nonsense. Of course if I have only 16 bit strings they can be implemented faster then if I have to support a string-length of 32 bit (2E9).

Both compilers are really fast, diffrences loose in the tolerances of new CPU-features (bigger caches, otehr optimizations).

Besides for people who like the "more C-Style programming" of Purebasic. the fact that the Visual Designer IS Included and that ALL UPDATES ARE INCLUDED makes it to a "Price-tip" par excellence.

[Edwin Knoppert]

I agree.

But why do people not resort to simple BSTR creation for long variables?

The ONLY drawback is that the var won't be released when getting out of scope.
(The only scope is your app)

Passing the BSTR to any Windows API is 100% ok..

[dmoc]

I'd bet a lot more people would be interested in a C2PB conversion tool

PS: Is this topic for real... or is it a troll... and why isn't there an emoticon for a troll... and how come other forums have a much wider choice of emoticons, huh? It's making PB'er's look a little shallow and 2 dimensional... grunt, grunt

[newtheogott]

Thats really a taste question and therefore I would never say "Its like that!". My taste is far from C/Java like syntax.

I'd prefer Assembly-mactos before using C. Thats personal. I thin Purebasic itself is written in C in parts.

Yes, maybe some people would do that, they like the C-Syntax.

For me, the question is "Use C? Or stay with Basic?"

As I decided to stay with Basic, I had some reasons (shorter code, less errors, easier to read syntax) of course there may be dissadvantages (interface to API ?, C is more popular etc.).

[fsw]

For such stuff like BIG STRINGS I use XBlite (Windows only / for Linux you have to use XBasic - both free ).
One string can have 2147483647 characters 8O

[dmoc]

Yeah, XB is great, just slow developing and won't accept the need for pointers. Me being of the mind that high level languages exist solely for the convenience of programmers, I had to abandon it (likewise with Euphoria which wouldn't accept the need for "goto"... and before anyone starts a purist rant my argument is if you don't like a feature then don't use it *but* don't impose your view on others). I'd still advise anyone to go have a look-see at XB and I would also bet on renewed interest now that 64bit cpu's are entering the consumer domain. Imagine a language written from the ground up to handle 64bits running on a 64 bit cpu - speeedy!

[Paul Dwyer]

Hi Edwin,

See you a lot on the Powerbasic Forum too!

This string thing is getting at me and I'm just wondering what people do. Generally 64kb strings are fine for what I do but in powerbasic strings are used for loading files which are often larger that 64k.

I notice that in purebasic you load to a pointer, would it be easier to a byte array for files (like back inthe old VB days?). Still very new new to purebasic, so I'm not sure how you dim the array over the location of the pointer...

With types in general the help files says to use mystr.s for declaring a string but in the consol.pb example files they use name$ etc, in purebasic does name$ decare the var as a string or is this the same as just using say "SName" ? Would Name$.s be correct or is that declaring twice? the docs are very small with regards to types etc

Thanks

[freak]

Name$ and Name.s both are strings. Internally, there is no difference
between them. Some people like the one better, some the other, that is
just a question of taste. ($ is basic syntax, that's why it's there)

You just have to know, that when using Name$, you always have to add the $,
and when using .s, you can drop the extension after the first use, because
then the compiler knows the type of the variable. The best is, not to mix
them.

Timo

[Andre]

Name$ and Name.s both are strings. Internally, there is no difference
between them. Some people like the one better, some the other, that is
just a question of taste. ($ is basic syntax, that's why it's there)

You just have to know, that when using Name$, you always have to add the $,
and when using .s, you can drop the extension after the first use, because
then the compiler knows the type of the variable. The best is, not to mix
them.

I will add something like this description to the manual, soon...

[Paul Dwyer]

I agree.

But why do people not resort to simple BSTR creation for long variables?

The ONLY drawback is that the var won't be released when getting out of scope.
(The only scope is your app)

Passing the BSTR to any Windows API is 100% ok..

Edwin, What APIs should I be looking up to use BSTRs? Are BSTRs OLE Strings? or are they different again?

Thanks

[Edwin Knoppert]

SysAllocStringByteLen()
SysStringByteLen()
SysFreeString()

These are the ANSI versions.
PowerBASIC for example, returns the ansi version if you exported a function as String ( ....blah blah ) AS String )

The CALLER (PureBasic) should release the BSTR.

You can use BSTR in PureBasic directly, i was actually pointing out that BSTR's would be the best option in future Purebasic versions.
Since they are used with com and exchanged between apps.

At this moment i don't see a big reason to use it as pointer.
Only if you need a large buffer, HeapAlloc() is also fine.

However, SysStringByteLen() returns the desired size set during creation.