To summarize: From the language/compiler point of view, large files are
no problem. We already concluded that, and in some cases the language
even forces you to use large files.
But, from a personal - human point of view, large files are not always
nice. At least, some people think so. They
Martin wrote:
{$region}
{$endregion}
Perfect !
I feel this should solve much the OP's problem with big source files.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Wed, 2010-01-06 at 16:56 +0300, Nikolai ZHUBR wrote:
Wednesday, January 06, 2010, 2:47:24 PM, Juha Manninen wrote:
On keskiviikko, 6. tammikuuta 2010 13:14:18 Michael Van Canneyt wrote:
Why ? Every class in 1 file is perfectly possible with include files, and 1
big unit file.
Ok,
Nikolai ZHUBR schrieb:
Wednesday, January 06, 2010, 2:47:24 PM, Juha Manninen wrote:
On keskiviikko, 6. tammikuuta 2010 13:14:18 Michael Van Canneyt wrote:
Why ? Every class in 1 file is perfectly possible with include files, and 1
big unit file.
Ok, include files seem to solve this
2010/1/6 Vincent Snijders vsnijd...@vodafonevast.nl:
You are getting old:
http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg13343.html
Ah, but that would explain why I don't use it. I never develop in
delphi mode, only objfpc mode - unless I work with projects like tiOPF
where both
Graeme Geldenhuys schrieb:
2010/1/6 Vincent Snijders vsnijd...@vodafonevast.nl:
You are getting old:
http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg13343.html
Ah, but that would explain why I don't use it. I never develop in
delphi mode, only objfpc mode - unless I work with
Nikolai ZHUBR schrieb:
Tuesday, January 05, 2010, 11:08:37 PM, Juha Manninen wrote:
On tiistai, 5. tammikuuta 2010 20:06:42 Florian Klaempfl wrote:
Then do the same as in C++ and put it in different include files.
Right, include files could solve this problem at least partly. They seem to
On keskiviikko, 6. tammikuuta 2010 03:08:35 Nikolai ZHUBR wrote:
Tuesday, January 05, 2010, 11:08:37 PM, Juha Manninen wrote:
On tiistai, 5. tammikuuta 2010 20:06:42 Florian Klaempfl wrote:
Then do the same as in C++ and put it in different include files.
Right, include files could solve
On keskiviikko, 6. tammikuuta 2010 10:59:36 Florian Klaempfl wrote:
Indeed, there are multiple ways to prevent the hell of circular class
references between units:
- abstract base classes
- interfases
- include files
- big units
- type casting (in the worst case)
- ...
The right choice
On 5 Jan 2010, at 22:40, Graeme Geldenhuys graemeg.li...@gmail.com
wrote:
I must say, I agree with the original poster - it would be very
useful. I have had many battles to try and overcome circular reference
issues, and I do take care in my class designs.
I would also agree. I used to use
In our previous episode, Juha Manninen said:
- big units
- type casting (in the worst case)
- ...
The right choice depends on the application.
Abstract base classes and interfaces are recommended by many but actual
projects end up copying everything into one file. Surprising... :-)
On 06 Jan 2010, at 11:14, Juha Manninen wrote:
I must try include files for this problem sometimes. Does FPC really
treat
them differently than Delphi.
No. {$i xxx} is exactly the same as copy/pasting the contents of xxx
into the current file at that point.
Jonas
On Wed, 6 Jan 2010, Marco van de Voort wrote:
In our previous episode, Juha Manninen said:
- big units
- type casting (in the worst case)
- ...
The right choice depends on the application.
Abstract base classes and interfaces are recommended by many but actual
projects end up copying
Juha Manninen schrieb:
Still, best solution has been to put everything into one big file. And still,
I don't like that compiler forces such a thing.
The compiler forces you many other things. Still, I don't get what's the
problem with a large unit if it's really needed (and nothing like
In our previous episode, Michael Van Canneyt said:
projects end up copying everything into one file. Surprising... :-)
I never do this, there is no need. Probably similar to the fact that 90% of
the Delphi programs have all important code in event handlers of the GUI
components. That
In our previous episode, Florian Klaempfl said:
Still, best solution has been to put everything into one big file. And
still,
I don't like that compiler forces such a thing.
The compiler forces you many other things. Still, I don't get what's the
problem with a large unit if it's
Florian Klaempfl schrieb:
Juha Manninen schrieb:
Still, best solution has been to put everything into one big file. And
still,
I don't like that compiler forces such a thing.
The compiler forces you many other things. Still, I don't get what's the
problem with a large unit if it's really
Marco van de Voort schrieb:
In our previous episode, Florian Klaempfl said:
Still, best solution has been to put everything into one big file. And
still,
I don't like that compiler forces such a thing.
The compiler forces you many other things. Still, I don't get what's the
problem with a
Juha Manninen wrote:
IMO, the compiler should not force a programmer to make a 34 000 lines source
file (like VirtualTreeView has). Programmer should have a choice to split it
if he wants.
What about include files (used a lot in Lazarus LCL) ? You can e.g.
separate the interface part from
In our previous episode, Florian Klaempfl said:
cannot test a unit with external circular class references without the
other involved units. So why should the stuff be separated?
I don't like extremely large ( few thousand lines) units from an overview
perspective.
One can also say a
In our previous episode, Michael Schnell said:
I use a C compiler (for 8 Bit PICs) that can't link at all. Here you do
a kind of linking manually by using a main file that includes
everything else.
Which is that then? Afaik the microchip own, and the Hitech compilers can do
so perfectly?
Marco van de Voort schrieb:
(remember the people to complain about the huge amount of files of the
fpc rtl :)?).
The point is that they are right from a birds-eye general application
development view.
I wanted only to point out that there pros and cons for small/large
units and if a design
On keskiviikko, 6. tammikuuta 2010 12:42:23 Florian Klaempfl wrote:
Juha Manninen schrieb:
Still, best solution has been to put everything into one big file. And
still, I don't like that compiler forces such a thing.
The compiler forces you many other things. Still, I don't get what's the
Florian Klaempfl schrieb:
Marco van de Voort schrieb:
(remember the people to complain about the huge amount of files of the
fpc rtl :)?).
The point is that they are right from a birds-eye general application
development view.
I wanted only to point out that there pros and cons for
Marco van de Voort wrote:
Which is that then? Afaik the microchip own, and the Hitech compilers can do
so perfectly?
CCS
Same had been the cheapest option for a C compiler to try out the PICs.
I never switched to something else, as I am abandoning the 8 bit PICs
for the 16 Bit ones that are
In our previous episode, Juha Manninen said:
Other programming languages have different cultures. See the comment from my
original post in this thread. It was from a professional programmer and I
understand it. Some development teams want to put every class into its own
file. C and C++ even
On Wed, 6 Jan 2010, Juha Manninen wrote:
On keskiviikko, 6. tammikuuta 2010 12:42:23 Florian Klaempfl wrote:
Juha Manninen schrieb:
Still, best solution has been to put everything into one big file. And
still, I don't like that compiler forces such a thing.
The compiler forces you many
Juha Manninen schrieb:
Other programming languages have different cultures. See the comment from my
original post in this thread. It was from a professional programmer and I
understand it. Some development teams want to put every class into its own
file.
Different languages, different
In our previous episode, Michael Schnell said:
Which is that then? Afaik the microchip own, and the Hitech compilers can do
so perfectly?
CCS
Same had been the cheapest option for a C compiler to try out the PICs.
Well, the microchip one academic option is free. So CCS gives money with
Juha Manninen wrote:
OOT I hope Lazarus can soon edit parts of one file in many editor tabs.
/OOT
It can compress entities (e.g. Functions) to a single line. Seems
helpful on that behalf. Maybe this feature could be extended e.g. by
recognizing {$part xxx} comments or similar.
Maybe you
On keskiviikko, 6. tammikuuta 2010 13:14:18 Michael Van Canneyt wrote:
Why ? Every class in 1 file is perfectly possible with include files, and 1
big unit file.
Ok, include files seem to solve this problem.
I don't know why they are not commonly used in Delphi programs as source
files. It
Juha Manninen wrote:
Ok, include files seem to solve this problem.
I don't know why they are not commonly used in Delphi programs as source
files.
Maybe because (some old version of the) Delphi IDE's debugger could not
step into include files. AFAIK, the actual Lazarus can do this with no
Did you have a look at AVR?
They use GCC, although commercial compilers are also available should
you need it. I have used GCC-AVR for years without problems.
Marco van de Voort wrote:
In our previous episode, Michael Schnell said:
Which is that then? Afaik the microchip own, and the
On 06 Jan 2010, at 12:14, Florian Klaempfl wrote:
Different languages, different habits. I even consider putting every
class in its own header and implementation file as a bad habit.
There is
no reason to do anymore because modern C/C++ compiler can smartlink
on a
sub-object level which
Marco van de Voort wrote:
I already switched to 16-bit (33FJA128MC510 and -804) long ago, and am very
happy with them.
Same here (with PIC 24xx). A friend of mine uses the 33s very happily, too.
But I still use the PIC18F60j60 part since there is no
16-bit integrated ethernet part, and as
On Wed, 6 Jan 2010, Juha Manninen wrote:
On keskiviikko, 6. tammikuuta 2010 13:14:18 Michael Van Canneyt wrote:
Why ? Every class in 1 file is perfectly possible with include files, and 1
big unit file.
Ok, include files seem to solve this problem.
I don't know why they are not commonly
Jonas Maebe schrieb:
On 06 Jan 2010, at 12:14, Florian Klaempfl wrote:
Different languages, different habits. I even consider putting every
class in its own header and implementation file as a bad habit. There is
no reason to do anymore because modern C/C++ compiler can smartlink on a
Include files - just like conditional defines - totally mess up all
code tools.
Is this true for the newest versions of Delphi, too ? I seem to remember
rumors about lots of IDE improvements.
-Michael
___
fpc-devel maillist -
On Wed, 6 Jan 2010, Michael Schnell wrote:
Include files - just like conditional defines - totally mess up all
code tools.
Is this true for the newest versions of Delphi, too ? I seem to remember
rumors about lots of IDE improvements.
Well, not yet in D2009 as far as I remember, but I
In our previous episode, Michael Schnell said:
But I still use the PIC18F60j60 part since there is no
16-bit integrated ethernet part, and as spare replacement for legacy parts.
This fried uses the (quite new) Microchip Ethernet MAC/PHY chip
(including frame buffers, doing 100MBit) that
In our previous episode, Florian Klaempfl said:
memory, depending on the used compiler (and debug information or
optimization settings)
For single class c++ files, imo most of the time is spent into reading
the huge headers which are often even not needed and a complete mess
because
On 06 Jan 2010, at 13:04, Florian Klaempfl wrote:
Jonas Maebe schrieb:
Another reason is probably to speed up the compilation:
* (re)compiling huge source files can be slow and/or require lots of
memory, depending on the used compiler (and debug information or
optimization settings)
For
Jonas Maebe schrieb:
On 06 Jan 2010, at 13:04, Florian Klaempfl wrote:
Jonas Maebe schrieb:
Another reason is probably to speed up the compilation:
* (re)compiling huge source files can be slow and/or require lots of
memory, depending on the used compiler (and debug information or
In our previous episode, Wimpie Nortje said:
Did you have a look at AVR?
Yes, but from what I remember it was canceled because the amount of
periphery on the chip is poor. I also looked at ARM, but while there is more
choice there, it is fragmented over multiple vendors, with multiple
toolchains
Marco van de Voort schrieb:
In our previous episode, Wimpie Nortje said:
Did you have a look at AVR?
Yes, but from what I remember it was canceled because the amount of
periphery on the chip is poor. I also looked at ARM, but while there is more
choice there, it is fragmented over multiple
Marco van de Voort wrote:
I rather use FPC to substitute some of my 10-20 line programs on the
delphi side.
This is what I intend to get running before I retire :) : Have an
existing Delphi project of the size you mention run on NIOS/Linux.
-Michael
Marco van de Voort wrote:
Yes, but from what I remember it was canceled because the amount of
periphery on the chip is poor. I also looked at ARM, but while there is more
choice there, it is fragmented over multiple vendors, with multiple
toolchains (if a free one exists at all)
What was
Matt Emson wrote:
I would also agree. I used to use Interfaces or raise shared
classes/declarations to a new unit both could use to overcome this
issue myself. But I remember the Be GUI porters having loads of issues
mimicing the Be API header structure because there were so many
forward
Wednesday, January 06, 2010, 2:47:24 PM, Juha Manninen wrote:
On keskiviikko, 6. tammikuuta 2010 13:14:18 Michael Van Canneyt wrote:
Why ? Every class in 1 file is perfectly possible with include files, and 1
big unit file.
Ok, include files seem to solve this problem.
I don't know why
In our previous episode, Wimpie Nortje said:
Marco van de Voort wrote:
Yes, but from what I remember it was canceled because the amount of
periphery on the chip is poor. I also looked at ARM, but while there is more
choice there, it is fragmented over multiple vendors, with multiple
Wimpie Nortje wrote:
I don't want to start a AVR/PIC fight because it always ends up in a
religous war
We could just as well add Renesas and whatever other such archs :) . I
suppose each has it's pros and cons, otherwise it would already have
died out out taken the world.
-Michael
Jeff Wormsley wrote:
I would think any time you have two objects that need bidirectional
access of any sort that you would need to define an connector object
to make this link, so the data or functions that needs to be shared
between the two don't reside in either object, but in the connector
Michael Schnell wrote:
Juha Manninen wrote:
OOT I hope Lazarus can soon edit parts of one file in many editor tabs.
/OOT
http://www.lazarus.freepascal.org/index.php/topic,8304.msg39889.html#msg39889
http://lists.lazarus.freepascal.org/pipermail/lazarus/2009-November/046906.html
It can
Hello.
My proposal:
Please allow a forward declaration of a class which is defined in another
unit, maybe using a new syntax for the declaration.
Alternatively, allow circular references just like other programming languages
do.
Forbidden circular references is a major annoyance in Object
On 05 Jan 2010, at 17:07, Juha Manninen wrote:
Forward declaration of a class is allowed inside a unit. There can
be a
reference to a class before it is defined! Like:
TMyClass = class;
Why is it not allowed from another unit? They are conceptually the
same thing!
The reason that they
On tiistai, 5. tammikuuta 2010 18:07:38 Florian Klaempfl wrote:
Juha Manninen schrieb:
If I create a feature request issue for this, does it have any chance of
being implemented?
No.
Well thanks, that was a quick answer. According to timestamp you answered my
mail before I sent it!
In
Juha Manninen schrieb:
On tiistai, 5. tammikuuta 2010 18:07:38 Florian Klaempfl wrote:
Juha Manninen schrieb:
If I create a feature request issue for this, does it have any chance of
being implemented?
No.
Well thanks, that was a quick answer. According to timestamp you answered my
mail
On tiistai, 5. tammikuuta 2010 18:14:53 Jonas Maebe wrote:
On 05 Jan 2010, at 17:07, Juha Manninen wrote:
Forward declaration of a class is allowed inside a unit. There can
be a
reference to a class before it is defined! Like:
TMyClass = class;
Why is it not allowed from another
In our previous episode, Jonas Maebe said:
There might be other solutions (maybe some kind of class-specific
namespace support), but it would definitely require some more language
features rather than merely accepting anonymous class definitions
anywhere. Otherwise the type checking is
On tiistai, 5. tammikuuta 2010 18:39:21 Florian Klaempfl wrote:
I knew all the reasoning, but honestly, I don't see a point in it. I
used C++ for years professionally and I always avoided circular
references/implementing classes in different files than the header is
named so I see no need in
Juha Manninen schrieb:
On tiistai, 5. tammikuuta 2010 18:39:21 Florian Klaempfl wrote:
I knew all the reasoning, but honestly, I don't see a point in it. I
used C++ for years professionally and I always avoided circular
references/implementing classes in different files than the header is
named
El 05/01/2010 13:07, Juha Manninen escribió:
Why is it not allowed from another unit? They are conceptually the same thing!
The problem could be solved easily if there was a forward declaration saying:
TMyClass = class; defined in MyUnit.pas
I need this feature too, and I like this
On tiistai, 5. tammikuuta 2010 19:16:25 Florian Klaempfl wrote:
See e.g. the compiler, but how does a big source file hurt anyways?
Today, navigation is done by the IDE and cvs times are also gone when
big files were a problem to commit. I consider class reference refering
some external files
Juha Manninen schrieb:
On tiistai, 5. tammikuuta 2010 19:16:25 Florian Klaempfl wrote:
See e.g. the compiler, but how does a big source file hurt anyways?
Today, navigation is done by the IDE and cvs times are also gone when
big files were a problem to commit. I consider class reference
On 05 Jan 2010, at 17:45, Juha Manninen wrote:
On tiistai, 5. tammikuuta 2010 18:14:53 Jonas Maebe wrote:
The reason that they are conceptually not the same thing is that in
Pascal two different units can both declare a different class with the
same name (just like they can both have global
Jonas Maebe schrieb:
On 05 Jan 2010, at 17:45, Juha Manninen wrote:
On tiistai, 5. tammikuuta 2010 18:14:53 Jonas Maebe wrote:
The reason that they are conceptually not the same thing is that
in Pascal two different units can both declare a different class
with the same name (just like they
In our previous episode, Horacio Jamilis said:
I need this feature too, and I like this proposed syntax.
In my case, my classes are defined in a form unit, so I can not have
more than 1 class per file (this is a Lazarus project)...
It's perfectly possible to have more than 1 class per file.
Florian Klaempfl schreef:
Juha Manninen schrieb:
If I create a feature request issue for this, does it have any chance of being
implemented?
No.
I think it would be EASY to implement.
Then propose a patch.
It surely would prove how easy it would be to implement.
And if it was
El 05/01/2010 15:48, Marco van de Voort escribió:
In our previous episode, Horacio Jamilis said:
I need this feature too, and I like this proposed syntax.
In my case, my classes are defined in a form unit, so I can not have
more than 1 class per file (this is a Lazarus project)...
Hello Florian,
Tuesday, January 5, 2010, 7:06:42 PM, you wrote:
FK I never looked at VirtualTreeView but I doubt that the 34k line source
FK is a language problenm.
Programmer should have a choice to split it
FK Good languages prevent programms to do ugly things :)
if he wants.
This is not
On tiistai, 5. tammikuuta 2010 20:20:16 Jonas Maebe wrote:
It would have at least two consequences (there are undoubtedly more that
I'm not thinking of currently): a) all forward-declared types from the
interface would have to be resolved after the uses-clause in the
implementation has been
On tiistai, 5. tammikuuta 2010 20:58:11 Vincent Snijders wrote:
Florian Klaempfl schreef:
Juha Manninen schrieb:
I think it would be EASY to implement.
Then propose a patch.
It surely would prove how easy it would be to implement.
And if it was rejected, which I doubt, if it were
On tiistai, 5. tammikuuta 2010 20:06:42 Florian Klaempfl wrote:
Then do the same as in C++ and put it in different include files.
Right, include files could solve this problem at least partly. They seem to be
used for actual program code with FPC. Are they treated differently from
Delphi's
Hello,
On Tuesday 05 January 2010 20:44:06 JoshyFun wrote:
In the past I had some autogenerated pascal programs, but to include
them in another unit I must manually split the files in interface and
implementation. Would be possible to do something like:
interface
[...]
{$I InterfaceOnly
Martin Sucha schreef:
Hello,
On Tuesday 05 January 2010 20:44:06 JoshyFun wrote:
In the past I had some autogenerated pascal programs, but to include
them in another unit I must manually split the files in interface and
implementation. Would be possible to do something like:
An example is:
On tiistai, 5. tammikuuta 2010 19:48:39 Horacio Jamilis wrote:
In my case, my classes are defined in a form unit, so I can not have
more than 1 class per file (this is a Lazarus project)...
I know that I should have more divided the visible editing and the class
itself, and I did, with some
In our previous episode, Juha Manninen said:
You should try to separate user interface from program logic.
Do only strictly UI specific stuff in form class units. Keep program logic in
separate units (or one big separate unit :-)).
Then program logic unit can reference freely the form
On 05/01/2010, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
two different units can both declare a different class with the same name
(just like they can both have global variables and procedures/functions
And I would bitch-slap any developer in my team that tries that!
b) add some way to
On 05/01/2010, Marco van de Voort mar...@stack.nl wrote:
You can only not have multiple design forms in one class, but the
That's a limitation specific to Delphi and Lazarus. Remember a Form is
also a class. So if you can have multiple classes in a unit, why can't
you have multiple form class
In our previous episode, Graeme Geldenhuys said:
[ Charset UTF-8 unsupported, converting... ]
On 05/01/2010, Marco van de Voort mar...@stack.nl wrote:
You can only not have multiple design forms in one class, but the
That's a limitation specific to Delphi and Lazarus. Remember a Form is
On 05/01/2010, Martin Sucha anty...@gmail.com wrote:
You should be able to achieve that by putting some ifdefs around interface and
implementation (and other) parts of your autogenerated programs and then for
example
True and I have done this before. BIG problem is that class visibility
goes
Graeme Geldenhuys schrieb:
On 05/01/2010, Martin Sucha anty...@gmail.com wrote:
You should be able to achieve that by putting some ifdefs around interface
and
implementation (and other) parts of your autogenerated programs and then for
example
True and I have done this before. BIG
On 06/01/2010, Florian Klaempfl flor...@freepascal.org wrote:
That's why we've strict private/protected.
Since when is that available in FPC? I didn't know it was.
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
Tuesday, January 05, 2010, 11:08:37 PM, Juha Manninen wrote:
On tiistai, 5. tammikuuta 2010 20:06:42 Florian Klaempfl wrote:
Then do the same as in C++ and put it in different include files.
Right, include files could solve this problem at least partly. They seem to be
Curious enough, nobody
Graeme Geldenhuys schreef:
On 06/01/2010, Florian Klaempfl flor...@freepascal.org wrote:
That's why we've strict private/protected.
Since when is that available in FPC? I didn't know it was.
You are getting old:
http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg13343.html
Lance posted this in the Lazarus mailing list, and I think it is more
appropriate here...
Lance Collins wrote:
How can you avoid circular references with two modules that
interact with each other?
Basically it should be possible with a minor language change and not too
much effort from
On 14 Aug 2009, at 08:43, Graeme Geldenhuys wrote:
I can't agree more. Sometimes there is a valid design for something
like that. The compilers already handle forward declarations in the
same unit,
Actually, only in the same type block.
so why can that not be applied for multiple units
Graeme Geldenhuys wrote:
Lance posted this in the Lazarus mailing list, and I think it is more
appropriate here...
Lance Collins wrote:
How can you avoid circular references with two modules that
interact with each other?
Basically it should be possible with a minor language change and not
88 matches
Mail list logo
