1 week newbie-want PB source in a lib-include creates bloat

[John R. Sowden]

I have been writing in xbase for 35 years for my internal use, Foxpro for the last 20. I am able to have external procedure files, written in Foxpro source that are only called into the tokenized executable (.fxp) if they are used. Therefore I have a very few libraries, 1 common and the others for special types of programs. I have been reviewing the doc and some outside doc, and it seems that the only way that I can have a called library is if I write and compile it in asm or c. If I could write in C efficiently, I would not have purchased PB. Include seems to bring in all of the code, whether it will be used or not.

Q1: If I "include" 1000 lines of PB source code, and only about 33% are called by the program, will the unused procedures be compiled and added to the executable, or will they only be added if they are called? I primarily use Linux, but is this issue O/S agnostic?

Q2: Is there another was to solve this issue?

John

[IdeasVacuum]

Have you seen the exe files that PB compiles? They are tiny! You can write a lib (include file, module, tailbite, call it what you like) in PB. It is simply the case that PB also has the ability to use libs written in C, which is handy because there are a lot of C libs out there.

If you only have 2 or 3 thousand lines of code to consider, I would not worry at all about redundant Procedures, it isn't an issue. In fact all though I have written some 'big' apps in PB, I have never worried about that - the final exe is always relatively small and fast.

[sys64802]

Q1: If I "include" 1000 lines of PB source code, and only about 33% are called by the program, will the unused procedures be compiled and added to the executable, or will they only be added if they are called? I primarily use Linux, but is this issue O/S agnostic?

It's OS agnostic. For the answer read these

http://www.purebasic.fr/english/viewtop ... =7&t=39174
http://www.purebasic.fr/english/viewtop ... =3&t=56680

[John R. Sowden]

I went to the messages re: this subject. They were extensive. That tells me that this is an issue that others have considered, and I'm not doin' the newbie thing. Secondly, those messages were written in 2009. Combining user interest and the 9 years, it is possible that this issue has been resolved. The elephant in the room though, is that the last doc I read says this is a one pass compiler, therefore it probably doesn't go back and get rid of all of the dead ends. It would be nice if it did.

Re: this forum, other than Fred (I don't know him, that is just how he is referenced), and the coders, all of whose time when coding is precious, are there people intimately knowledgeable of the current version and its history who can give us answers to some of these more internal questions? How do we know who they are? (Am I reading an opinion or a cold hard fact?)

A solution to this is to copy the include files to a special file name relating to the program you are currently writing, then after compiling writing, testing and debugging, go through the include text, looking for each procedure in the main program, and delete it from the include file associated with that program. This would make modifications in the future a bear, in addition to modifying the main program to take advantage of new procedures that I have added to my "source code libraries". That I have done many times over the years as I learn more. This in my opinion is a perfect job for a computer, not a fallible human.

John

[John R. Sowden]

correction 7 years.

[DontTalkToMe]

I went to the messages re: this subject. They were extensive. That tells me that this is an issue that others have considered, and I'm not doin' the newbie thing. Secondly, those messages were written in 2009. Combining user interest and the 7 years, it is possible that this issue has been resolved.

I believe nothing has changed, but it's easy to check, the link you followed explained it well with the asm output, anyone can check it again.
I don't have the desire to do it right now but it's relatively easy, see the /commented option for the command line compiler.

The elephant in the room though, is that the last doc I read says this is a one pass compiler, therefore it probably doesn't go back and get rid of all of the dead ends. It would be nice if it did.

It's still a one pass compiler, but I don't think a multiple pass compiler should be required to discard the procedures not actually called though.

http://www.purebasic.fr/english/viewtop ... 93#p366893

http://www.purebasic.fr/english/viewtop ... 21#p366921

Re: this forum, other than Fred (I don't know him, that is just how he is referenced), and the coders, all of whose time when coding is precious, are there people intimately knowledgeable of the current version and its history who can give us answers to some of these more internal questions? How do we know who they are? (Am I reading an opinion or a cold hard fact?)

Only Fred and Freak can speak about PB internals, most of us can guess just by looking at the compiler behavior, but case in point the link you followed was not just guessing, since it was showing the actual asm output. So you can confirm it by yourself as a fact or if you can point out an error then your version becomes a fact.
But I'm not sure to understand what's your problem. Do you want to know more about PB internals ? Just ask as you did here, or search in the forum, I don't think there is a better solution. Sometimes, rarely, Fred reply to those kind of questions too.

A solution to this is to copy the include files to a special file name relating to the program you are currently writing, then after compiling writing, testing and debugging, go through the include text, looking for each procedure in the main program, and delete it from the include file associated with that program. This would make modifications in the future a bear, in addition to modifying the main program to take advantage of new procedures that I have added to my "source code libraries". That I have done many times over the years as I learn more. This in my opinion is a perfect job for a computer, not a fallible human.

Sure it's a job for the compiler, it's strange it's not already there, I agree with you.
Anyway, unless you need to write really small programs for some reason, I don't see the kind of "bloat" introduced by PB as a real problem. It's minimal most of the time and decreasing (in %) as the program becomes larger.
But conceptually, sure it's a waste when your program contain stuff not useful the compiler could have removed and should be rectified.

correction 7 years.

You can edit your posts.