Really Dumb question..

[Scott Turchin]

If I have a function like this:
If IsTrue Exist("SHORTCUT.DLL") Then Kill "SHORTCUTDLL"

And I use multiple copies of the string or asciiz as above, and then go to a string such as :
SCD = "SHORTCUT.DLL"

And then replace that SCD in the function above, am I saving any memory by doing this or does the compiler recognize the same string?

Thanks,

Scott


-------------
Scott Turchin

[Semen Matusovski]

Scott --
"does the compiler recognize the same string?"
I think so.
Try, for example, to compile
#Compile Exe
Function PbMain()

MsgBox "Hello"
MsgBox "Hello1"
MsgBox "Hello"

End Function

and open exe in hex-editor. You will find "Hello" (one time) and "Hello1".

[Raymond Penn]

Scott,

The compiler does a very good job optimizing string data. I have been able to reduce code size by using string constants.

When you assign it to a string to a variable, you create the overhead of storing it and accessing it. If it never changes, a constant is the best solution.

Hope that helps.

Ray

[Eric Pearson]

Scott --

Taking Semen's example a step further, if you do this...

MsgBox "Hello"
MsgBox "Hello" + "1"
MsgBox "Hello"

...then the compiler will simply add one "Hello" and one "1" to your code. With short strings like that it's really not worth it, because the extra code that is required to add the strings together would "cost" more than the efficient string storage would "save", but if you use large numbers of long strings it can result in a significant savings. A good example would be long hard-coded path/file strings, where the directory names are all the same and only the file names are different.

One more note... If size/speed is important (when isn't it?) then you're probably much better off using PowerBASIC string literals than "resource file string tables". Win32 resource files store strings in Unicode form, which require two bytes per character instead of one. And remember that that applies to all resource strings, not just string tables. Every time you type a string (like a label or a window title) into a resource file, you're using Unicode.

You can get most of the advantages of using a resource file string table (one file to edit, ease of translation, etc.) by creating your own "string function" that simply returns a string according to a "lookup number", but you'll avoid the Unicode overhead.

On the other hand, if you are writing an app that will need to display non-English text, Unicode has huge advantages that greatly outweigh the size penalty.

-- Eric

-------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[Semen Matusovski]

I fully agree that to use string constants is a good style.
But I disagree that usage of string constants reduces code size comparing with using string literals inside a program.
Really PB compiler is very clever.

I made following simple test:
1)
$Compile Exe
DefLng A-Z
Function PbMain()
   MsgBox "asjhhhhkkhjaksddddddq;wlekqwe2" <- repeats 50 times
End Function
2)
$Compile Exe
$Ch = "asjhhhhkkhjaksddddddq;wlekqwe2" 
DefLng A-Z
Function PbMain()
   MsgBox $Ch <- repeats 50 times
End Function

The sizes of both modules are the same.

[This message has been edited by Semen Matusovski (edited January 17, 2000).]

[Eric Pearson]

Semen --

I agree with your statement that string literals and string equates are equally efficient, but you have to be careful when testing for subtle size differences in PB/DLL and PB/CC modules. If you check the size of a PowerBASIC 32-bit module (EXE or DLL) you'll find that it is always a multiple of 512 bytes. So unless you make a change that removes enough code or data to cross the next 512-byte threshhold, your module will not shrink. Conversely, you can often add code to a module without making it larger, until you add one too many bytes and the size jumps up to the next multiple of 512.

So it's not easy to write a quick program to determine which of two techniques (such as literals vs. equates) is more size-efficient.

-- Eric

P.S. The 512-byte executable "block" size means that a PowerBASIC 32-bit module contains (on average) 256 bytes more than it absolutely has to, but because of the way hard drives allocate space for files in blocks, the effect on the actual amount of hard disk space that is taken up -- and on loading speed -- is virtually non-existent. And it has no effect whatsoever on the runtime memory that is used.


-------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[Semen Matusovski]

Eric --
not only sizes, compiled codes are equal (fc ... /b)

[Scott Turchin]

The nice thing about string's in the resource file is when foreign languages are being used, recompiling for a foreign language is just a matter of changing out the resource file generally.
I've seen the code that does that at work, rather impressive...

Scott

-------------
Scott Turchin

[Semen Matusovski]

Scott --
if you plan to include a possibility to translate a program to foreign languages, don't forget that English words are very short and you must be ready to accept strings of undefined length. Also could be another order of words.
One of the reason, why I like to use original - English - products, is truncated words (something like D.-U.Net. instead of Dial-Up Networking)