Does using modules have any advantages?

For other topics related to the FreeBASIC project or its community.
Galeon
Posts: 563
Joined: Apr 08, 2009 5:30
Location: Philippines
Contact:

Does using modules have any advantages?

Postby Galeon » Oct 22, 2009 11:20

I want to know what you think about this subject...
BigBaddie
Posts: 40
Joined: Oct 10, 2009 10:08
Location: Space
Contact:

Postby BigBaddie » Oct 22, 2009 12:57

less headaches, less trouble of searching an entire big (!) program, less
time to spend for creating your program if you accidently deleted a file,
and alot more. yes, it has ALOT OF ADVANTAGES! :)
TheMG
Posts: 376
Joined: Feb 08, 2006 16:58

Postby TheMG » Oct 22, 2009 15:51

Faster compilation.
rdc
Posts: 1725
Joined: May 27, 2005 17:22
Location: Texas, USA
Contact:

Postby rdc » Oct 22, 2009 18:34

It depends on what you mean by modules. Strictly speaking a module is a separate bas file with its own scope. If that is what you are referring to, then I would say no (except for the fact that you can organize the program code, which can be done using Includes). In fact it unnecessarily complicates things. The supposed benefit of faster compilation is only true if you have hundreds of modules, which most people don't have. We are not under the 64k memory limit anymore, so there is no need for dozens of bas files.

If you are meaning breaking up your program into Include files, then yes, it has a lot of benefits. It is always easier to create and maintain your code if it has some organization to it, and includes are a good method of organizing your code. If you look at any of my programs, you will always see 1 bas file and a set of include files. The bas file is the main program code, with all the supporting code in includes. And if you use FBEdit, you can create a project file and manage it all quite easily.
marcov
Posts: 3074
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Postby marcov » Oct 22, 2009 21:18

I only know Wirthian module systems, but some of the things I like about them:

- faster compilation (no infinite reparsing). Note that precompiled headers (like in commercial C compilers) can provide this too, but at substantially more work, and without the other benefits.

- Compiler generates errors when compilation units don't match. compilation units don't meet only at the linker. The compiler has more information and an earlier opportunity to generate a decent error msg. (Undefined symbol "XX". Well ok, but why and where!??!)

- If you support nested scopes, the unit level (and importing in general) is just another one. The unit typically also provides a namespace. (*)

- Decentralized initialization and finalization code.

- The name mangling allows to have global variables in different modules with the same name. No endless renaming anymore if you piece code out of various origins together.

- the compiler has knowledge about what module are used. This means that the compiler can autobuild and -link without much additional info. This reduces the need for makefiles and/or additional building information (FPC only needs to know what the main program is, and can compile the program by just "compiler <mainprogram>", and figures out the rest itself)

(*) Assume you have a module A and B, both exporting symbol X. If you import both into the main program, the order of importing will govern which X and Y are used. But you can always access individual implementations via A.X and B.X. Similarly for Y

Note that my experience with all of this is in a virtually macroless environment. How modules combine with non-trivial preprocessing (which is roughly ifdef/else/endif/define for conditionals only) is something I have no experience with. Specially for substitution macro's. (the so called hygienic macros are not macros at all afaik, but more something like inline generic procedures)[url][/url]
Last edited by marcov on Oct 23, 2009 10:10, edited 1 time in total.
1000101
Posts: 2556
Joined: Jun 13, 2005 23:14
Location: SK, Canada

Postby 1000101 » Oct 22, 2009 22:44

With the exception of "what" a module is, basically the exact opposite of rdc's post. Remind me never to download anything rdc codes, btw.
Galeon
Posts: 563
Joined: Apr 08, 2009 5:30
Location: Philippines
Contact:

Postby Galeon » Oct 22, 2009 23:37

From what I have read in some websites, include should not contain any code, so puting them include files is not good, and the use of #include's is to include a header file, not a source file.
Eponasoft
Posts: 264
Joined: Jul 26, 2007 2:40

Postby Eponasoft » Oct 23, 2009 0:06

When you #include source files, they get compiled along with the file you're #including them from. So in essence, no advantage is gained. Of course, aside from FB itself, I don't think many people here have written any source code that really needs to be split into modules for the benefit of reduced compilation time...and anyways, what's the difference? You might gain a second of compile time, whoopteedoo. You're not compiling QT4 here...
BastetFurry
Posts: 255
Joined: Jan 05, 2006 0:56

Postby BastetFurry » Oct 23, 2009 7:58

Serf City 3 (Die Siedler 3) from BlueByte is only 2 sourcefiles big and it worked, so much for that.

OTOH, as nobody realy explains it most people will fall over the thing that you will have two instances of, for example, an UDT when youre not initializing your stuff right.

Lets say you have:
main.bas

Code: Select all

#include "foo.bi"

Foo.DoSomething


foo.bas

Code: Select all

type footype
  declare sub DoSomething()
end type

sub footype.DoSomething()
  'Whatever...
end sub


How should foo.bi look like so that you dont have two versions of footype in memory?
marcov
Posts: 3074
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Postby marcov » Oct 23, 2009 10:06

Galeon wrote:From what I have read in some websites, include should not contain any code, so puting them include files is not good, and the use of #include's is to include a header file, not a source file.


#Include can be used for both code and headers. These are fundamentally two different uses though:

- #includes for headers are typically included multiple times in programs.
- #includes for code typically are not, and are just to break up very large source files. (or to share pieces of code between different projects)

Btw:
Headers can include code on C/C++ like systems, like e.g. inlined routines.
The bigger control over importing that modules give, allow Pascal/Delphi/Modula2 alikes to have the inlined routines in the implementation. There are problems with that though (due to importing order issues there is a small chance that routines might not be inlined), but there are ways to deal with that. (have the compiler generate a warning when it happens, allowing you to rearrange the import order)

Note that Pascal/Delphi etc fully allow the header principle include (it is like level zero everywhere). It is just used a lot less, because the unit/module system is way more save and it is easier to keep overview.
marcov
Posts: 3074
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Postby marcov » Oct 23, 2009 10:12

BastetFurry wrote:Serf City 3 (Die Siedler 3) from BlueByte is only 2 sourcefiles big and it worked, so much for that.


Some people dig gigantic holes with a toothpick. It doesn't mean I should.

IOW, the fact that something is possible, doesn't mean it is the easiest, most reproducable or safe way.

For more information about crazy ways to achieve something in dangerous ways and waste time consult your local Guiness book of records.
OTOH, as nobody realy explains it most people will fall over the thing that you will have two instances of, for example, an UDT when youre not initializing your stuff right.

Lets say you have:
main.bas

Code: Select all

#include "foo.bi"

Foo.DoSomething


foo.bas

Code: Select all

type footype
  declare sub DoSomething()
end type

sub footype.DoSomething()
  'Whatever...
end sub


How should foo.bi look like so that you dont have two versions of footype in memory?


I think your example is a bit to terse. I don't get it. Could you expand the example?
Last edited by marcov on Oct 23, 2009 10:47, edited 1 time in total.
marcov
Posts: 3074
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Postby marcov » Oct 23, 2009 10:46

rdc wrote:It depends on what you mean by modules. Strictly speaking a module is a separate bas file with its own scope.


That is part of it yes. A namespace, a well defined way of importing that is transparent to the compiler.

If that is what you are referring to, then I would say no (except for the fact that you can organize the program code, which can be done using Includes). In fact it unnecessarily complicates things. The supposed benefit of faster compilation is only true if you have hundreds of modules, which most people don't have. We are not under the 64k memory limit anymore, so there is no need for dozens of bas files.


This is not true. The speed bit is also very noticable for small programs that include large headers (like windows API, SDL etc).

Keep in mind that headers count as lines to be compiled/processed too.

This is also true for the module system, but there the stuff in header like modules is loaded predigested from a binary file (*), which is easily 10-20 times faster.

If you are meaning breaking up your program into Include files, then yes, it has a lot of benefits. It is always easier to create and maintain your code if it has some organization to it, and includes are a good method of organizing your code.


The problem is that this is manual, and the compiler has no knowledge about it. I don't agree that includes are a good way. It is the way the simplest to implement (but the hardest to expand) (*)

If you look at any of my programs, you will always see 1 bas file and a set of include files. The bas file is the main program code, with all the supporting code in includes. And if you use FBEdit, you can create a project file and manage it all quite easily.


And how do you reuse code between various projects? If you acquire more projects/code you'll start get identifier naming issues because of the single namespace.

(*) include file are rock bottom. The sagacity of it can be worked around by rigourous discipline and lots of debugging on the users behalf, and (very,very) labourous implementation of compiled headers on the compiler builders part.

C/C++ went this way because their standards were fixed before this problem was tackled, and the commercial vendors really wanted precompiled headers to speed compilation up. Note that only the big-vendor C compilers (BCB, MSVC) suppor this, most open source and smaller compilers (like gcc) do not, and are notoriously slow.

Slowliness of C compiler is mostly a result of this, though there are other reasons too (mostly the splitting of the compilation process over multiple passes in different binaries (make/cpp/gcc/collect/as/ar/ld), and reloading/saving state inbetween.
rdc
Posts: 1725
Joined: May 27, 2005 17:22
Location: Texas, USA
Contact:

Postby rdc » Oct 23, 2009 13:37

1000101 wrote:With the exception of "what" a module is, basically the exact opposite of rdc's post. Remind me never to download anything rdc codes, btw.


Go #%$@ yourself.
rdc
Posts: 1725
Joined: May 27, 2005 17:22
Location: Texas, USA
Contact:

Postby rdc » Oct 23, 2009 13:54

marcov wrote:
rdc wrote:It depends on what you mean by modules. Strictly speaking a module is a separate bas file with its own scope.


Modules, as they relate to FB, are a hold over from QB where you had to split your program up to fit into 64k memory space. They are essentially separate programs that the compiler would overlay parts of into memory. This is a module, not what you are talking about. This is why FB has implemented module specific commands like Common.

What you are talking about are include files in relation to FB. In C/C++ include file are both header and code files. In Pascal they are Unit which are simply scoped code files. You can do the same thing with FB.

And I reuse code all the time. I structure it that way. Modules don't facilitate code reuse, good programming does despite what some ignorant a-hole may say (not you marcov) that talk a lot but produce zero code to show for it. Talk is cheap.
stylin
Posts: 1253
Joined: Nov 06, 2005 5:19

Postby stylin » Oct 23, 2009 14:14

The biggest disadvantage for including *.bas files is the compilation times, particularly if you have >10,000LOC. Also, it is more difficult to allow others that don't want to deal with these increased compilations times to reuse your code (package it in a library).

Many users are also concerned with object file sizes, and including full source files prohibits the linker from optimizing unused code away--if I only need a single function from a source file, I still have to lug around all of the other code from the source file, whether it's necessary or not.

It is quick and easy to include code this way, but there are much more cons than pros, IMHO.

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 6 guests