PureBasic Forums - English

ricardo wrote:Yes, we are only giving our humilde opinion

Agreed. This is all good stuff. All opinions are worthwhile. Mine especially

* donates a virtual 1,024 bytes to PB for NOT, SGN, and logical results from logical operators within expressions *

Perhaps a separate Dialog library could be added that is almost identical to the window library except it can only produce non-resizable windows.

ie. OpenDialog would be just like OpenWindow except the #PB_Window_Resizable flag would not be available.

It wouldn't take much development, just remove functionality from the Window Library, and would allow small footprint apps for those that require them.

ricardo wrote:Can't be into a separated lib the resize stuff?

No, as it's in the core of the event process. Better, it makes the apps behave the same on Linux and Windows, so this time, it's unavoidable. I always split the code when necessary, and try to optimize the libraries for size when speed isn't critical. So don't be afraid, it won't ever turn into a bloated language.

GedB: the Dialog idea is great, I will see.

You guys really need to get the bigger picture here.

PB is not a lowlevel programming language, which means, that it does stuff
for you, to make YOUR life easier. And that comes at the cost of a little
filesize.

If really every byte counts, the you'll have to use a language like
ASM, where you really can optimize every bit to do only what you need.

And improvements to the language bring increase in filesize. If you don't
like that, stay with the old version. But then you won't get new features... that's life.

New features usually are added in splitted form, which means, if you don't
use them, they are not included. (We are all optimisation freaks, you know )
However, in this case, that is just not possible.

Don't get me wrong here. I'm all for small executables, but you have to think
in the right dimensions. 3k is nothing, even 30k are nothing. If you want your
program to actually DO something, it will have to have some code inside, and
that needs some diskspace. There is no way around that.


And please, consider this:
Even though PB adds some extra stuff like those 3k, it still produces
increddibly small executables compared to other languages.

Here are some examples:

Open an empty window in PB and wait for the close event -> 12 Kb.
12 Kb!! Do you realize how small that is? Even an EMPTY Word document is bigger. (19 Kb)

Now do the same thing with Delphi: you get 277 Kb
Just to put that into the right context:
Compile the whole PB IDE with PB, (which is nearly 10000 lines of code),
and you get only 176 Kb.

So please, think a bit about the dimensions, before you complain about
a library growing by less of the size of a simple icon file.

Now that's my humble opinion.

Timo

Fred wrote:

ricardo wrote:Can't be into a separated lib the resize stuff?

No, as it's in the core of the event process. Better, it makes the apps behave the same on Linux and Windows, so this time, it's unavoidable. I always split the code when necessary, and try to optimize the libraries for size when speed isn't critical. So don't be afraid, it won't ever turn into a bloated language.

GedB: the Dialog idea is great, I will see.

Fred,

Thanks for the explanation!!

Kale wrote:I agree too, but i think we can let Fred get away with 3k this time!

I can understand it from a developers point of view, but I hope it doesn't become a habit...

Would hate to see the executables with a 5 meg runtime module stuck to it...

Fred wrote:No, as it's in the core of the event process. Better, it makes the apps behave the same on Linux and Windows, so this time, it's unavoidable. I always split the code when necessary, and try to optimize the libraries for size when speed isn't critical. So don't be afraid, it won't ever turn into a bloated language.

Ohhh - missed that...

Thanks Fred - now I can sleep again...

Fred wrote:Better, it makes the apps behave the same on Linux and Windows, so this time, it's unavoidable.

My 2 cents: this 3K increase is not just unavoidable, it's downright desirable. To me, being able to compile an identical source base on all supported platforms and getting identical behavior on all platforms is worth much much more than a whopping 3K increase of the binary.

Heck, if the entire command set were supported identically across all platforms (including all GUI stuff), I would gladly accept a 300K increase!

It will never have a 300k increase !

c'est tres bien comme ca! A donf, Fred!

300k increase sounds like bloating 8O

Whatever. I think you should look at the dialog idea. Its a very good idea!

i'd even take 300k if it would include all the things i can dream up

I would only change .exe size increment for speed increment

Hiya Psychophanta.

Check out commercial programs. As a general rule:

Bigger program = higher cost.

Therefore bigger program = more profit.

Therefore bigger program = quicker capital accumulation.

Therefore bigger program = Fast track to faster Ferrari.

Therefore bigger program = more speed.



Bloat = Life in the fast lane!

in fact you're right

Sadly...
Therefore, people who pay more for compilers which generate bigger programs (most masses of people and companies) = silly people.

Merchants are mostly, absolutely deceit entities which besides of to be a deceit in itselves, they prostitute ALL itselves, not only flesh. At least, mostly of prostitutes are honest, not deceit, and only prostitute his/her flesh, nothing more.

Fred, are you a vocational programer who enjoy and play, or an obscure prostitute merchant??