>
> 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
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 s
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 fil
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
Michael Schnell wrote:
Juha Manninen wrote:
I hope Lazarus can soon edit parts of one file in many editor tabs.
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 compress
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
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
___
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
>
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 w
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 clas
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 can
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 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 mul
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
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 infor
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 sin
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
> becaus
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) t
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 don'
> 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 - fpc-devel@lists.free
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 o
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 us
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
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 th
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 Hit
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
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 m
Juha Manninen wrote:
> I hope Lazarus can soon edit parts of one file in many editor tabs.
>
>
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 could e
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 mone
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, differe
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 oth
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++ e
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 a
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 con
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'
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
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?
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
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
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
>> pr
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
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
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
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
abstr
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 every
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
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. Surpr
On 5 Jan 2010, at 22:40, Graeme Geldenhuys
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 Interfaces or raise sha
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 righ
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 cou
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 se
Graeme Geldenhuys schrieb:
> 2010/1/6 Vincent Snijders :
>> 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 tiOP
2010/1/6 Vincent Snijders :
>
> 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 compilers (Delphi and
Graeme Geldenhuys schreef:
On 06/01/2010, Florian Klaempfl 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
Vincent
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, nobo
On 06/01/2010, Florian Klaempfl 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
http://opensoft.homeip.n
Graeme Geldenhuys schrieb:
> On 05/01/2010, Martin Sucha 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 t
On 05/01/2010, Martin Sucha 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 out the window
In our previous episode, Graeme Geldenhuys said:
[ Charset UTF-8 unsupported, converting... ]
> On 05/01/2010, Marco van de Voort 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 c
On 05/01/2010, JoshyFun wrote:
>
> interface
> [...]
> {$I InterfaceOnly C:\.pas}
> [...]
> Implementation
> {$I ImplementationOnly C:\.pas}
> [...]
>
> I think it will not include a big penalty in the parser, or maybe I'm
> completly wrong ?
I have done with with 100's of inclu
On 05/01/2010, Marco van de Voort 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 a single un
On 05/01/2010, Jonas Maebe 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 specify the unit name in
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 u
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 som
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:
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 Interface
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 in
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,
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 b
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
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)...
It
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 rejected
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 fi
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 (ju
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 g
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 refering
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 fil
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 pro
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
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 i
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 i
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
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 answere
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!
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 a
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.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
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 Pasca
87 matches
Mail list logo
