Things Lazarus/FPC can do Delphi cannot?

[CaptBill]

I understand that, since the addition of advanced records, this means that most of codebase for practically everything needs to be changed from classes to advanced records, to take advantage of a fairly significant overhead/speed reduction in Delphi's case.

I don't understand the connection. Could you elaborate? Classes to advanced records is rarely a solution for anything, since advanced records only support static methods. (and not virtual ones).

The only benefit +/- is that in generics you can mass instantiate records by arranging them in an array and grow themwith setlength (with only one call to the heap manager for all instead of one each), but that effect won't be that big for records with dynamic types (like strings) in them.

And doesn't seem high on the priority list at Delphi from what I heard.

Is FPC/Lazarus ahead of the curve in this regard, I wonder? I would imagine. If so, then Lazarus should have an advantage here.

I don't understand what the "curve" is supposed to be.

My understanding is that an advanced record requires about half the resources of a class and there are many thousands of places where it could be implemented throughout the classes/components.  I assume they meant internal classes, like TList, that are used often inside many classes/components. Not as stand alone class replacements, but where they make sense.

By "curve" I mean, being in on-going development, any new feature can be incorporated into any new development in Lazarus vs Delphi which isn't as likely to "tweak" the base code as readily, being a commercial operation.

I was more curious where Lazarus stands in this regard.

[CaptBill]

@Snorkel: if he doesn't understand about not including debug info etc now after all these posts, he's probably a zombie

Hey, that is an unfair characterization of zombies!
Not cool!
You ought to know better, Big Chimp!

Hahahahaha

http://www.google.com/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&docid=QcONcCDhY4qO2M&tbnid=lPpVVkmCfIL1rM:&ved=0CAUQjRw&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FFile%3ADuccio_di_Buoninsegna_-_Resurrection_of_Lazarus_-_WGA06781.jpg&ei=Adj-UPjhOZLs9ATe5YDwCg&bvm=bv.41248874,d.eWU&psig=AFQjCNHlZFp_n18KWQca0u3NkVMOraADUQ&ust=1358965122253561

[BigChimp]

Nice image link

[CaptBill]

If my understanding is correct, advanced records are basically striped down classes. No object model, constructor, exception handling, etc. etc. So you must provide the functionality from scratch, mainly a constructor. Many times you don't need full blown classes, for instance, in an collection or a drawgrid, for example. If a record is all you need for the "contained" object, you are greatly optimizing the speed and size of the collection/grid.

This touches the "exe size" complaints too. You know, the one where C is better at making smaller compiled executables, yada yada. Sure, you CAN make smaller apps possibly, but that is assuming that you are a AAA+ rated C programmer. You still have to know how to set up the project in the C++ IDE for "bare metal" programming, I would assume. Of coarse C is technically the winner. But put an ace Lazarus programmer, who knows how to program "bare metal" vs. your average C programmer, and check size then. There is you reality check.

Same applies with Lazarus. The default settings are well thought out and set up for the "typical user", not to prove that it can go "bare metal". What advanced records throws into the mix is this...the concept of "bare metal OOP", where you can now build in OOP in a ground-up manner, providing only the OOP elements you need. So now the onus is no longer on Lazarus/Fpc's abilities, it is now solely the programmers OOP abilities.

Concerning Lazarus's advantage over Delphi in this regard is that we can look forward to seeing great improvements, very low in the object model, that will improve performance in the whole "object tree". I imagine it is just getting a handle on some good "best practices" techniques is all. You can improve the LCL in Lazarus, not so with Delphi.

[marcov]

If my understanding is correct, advanced records are basically striped down classes.

Not really, since they lack the main characteristic of objects/classes: polymorphism aka inheritance.

No object model, constructor, exception handling, etc. etc. So you must provide the functionality from scratch, mainly a constructor

Many times you don't need full blown classes, for instance, in an collection or a drawgrid, for example.

If you were really that memory tight, you probably didn't use LCL and collections to begin with and handcoded everything procedural. It really is unlikely
in this day and age where you may expect even something embedded to have 128MB of ram. This is all DOS talk.

Moreover, even if for some reason you already had such a problem, you probably already used records there, since advanced records doesn't change anything
except writing

instance.methodname(arg1,arg2,arg3)

instead of
 
methodname(instance,arg1,arg2,arg3)

If a record is all you need for the "contained" object, you are greatly optimizing the speed and size of the collection/grid.

It can be yes. But only if you use say VST, and that didn't allow classes in the first place, since when a grid isn't specially optimized
for this kind of memory tight behaviour, it will do several allocations for every cell anyway, making your savings (if any!) useless.

This touches the "exe size" complaints too. You know, the one where C is better at making smaller compiled executables, yada yada. Sure, you CAN make smaller apps possibly, but that is assuming that you are a AAA+ rated C programmer. You still have to know how to set up the project in the C++ IDE for "bare metal" programming, I would assume. Of coarse C is technically the winner. But put an ace Lazarus programmer, who knows how to program "bare metal" vs. your average C programmer, and check size then. There is you reality check.

This is a totally different discussion. Memory footprint and exe footprint are not directly correlated.

Same applies with Lazarus. The default settings are well thought out and set up for the "typical user", not to prove that it can go "bare metal". What advanced records throws into the mix is this...the concept of "bare metal OOP",

1 There is no such thing as "bare metal OOP"

2 advanced records is not OOP, it misses fundamental OOP concepts, most notably polymorphism.

 

[B4Z1l3]

I Come back to the initial topic after all those comments/countercomments

Float/Double properties with a default value are possible in FPC. In the last Delphi I've used for the production of a soft. (d2007), this was not possible.
There was a message saying someting like 'default value can only be set for Ordinal properties...'

Now I don't know if it's been implemented since XE3...but when I've encountered that (so with d2007) I just told myself...that's stupid because a single , from the cpu point of view, is just like any other value: a wide-long-register value....so the default value for a single or a double could be casted from a fp literal to a 4 bytes integer (source code to parser)  and in the program, the default single can be passed from a register to the FPU...You know what I mean ?

BTW, I've encountered a few monthes ago a special case where the default value of a FP property would have helped...so this is a +1 for Fpc.

Anyway, just tell me if since d2007 this has been implemented in Delphi, in this case my answer wouldn't be valid.

[teos]

The other way around: Delphi can use packages without taking 20 minutes to compile your IDE after your make a minor change or wanna add a new package.

And FPC can produce different results from different versions or different platforms. Well.. when Delphi has something irritating, it is at least consistent.

In FPC if i have a component with runtime event assignment, it's allready different when I compile the package or after that use the component in a project.

[B4Z1l3]

The other way around: Delphi can use packages without taking 20 minutes to compile your IDE after your make a minor change or wanna add a new package.

And FPC can produce different results from different versions or different platforms. Well.. when Delphi has something irritating, it is at least consistent.

In FPC if i have a component with runtime event assignment, it's allready different when I compile the package or after that use the component in a project.

first remark: This is true that packages in Laz are not dynamically linked, so you need to recompile everything...but this restriction can lead to better practices(such as not tesing each single change but rather puting assertions or protectors at the beg of a proc in DEBUG mode).
BTW It never tooks me 20 minutes to recompile Laz when developping a package, even if it's not as fast as in Delphi.

second remark: no comment...the RTL and LCL have some plateform-specific-limitations, your own source code should also have some compiler definitions depending on the target plateform...

third remark: I (really) don't understand what you mean. Maybe your Component is not well enough designed and an assignement made at the runtime clear the one made in the component (then in this case just make a system of 'multi-cast-event' with something like a list and a method such as AddEvent(), or review the component design: accessibility of your fields...)

[Blaazen]

@ The other way around: Delphi can use packages without taking 20 minutes to compile your IDE after your make a minor change or wanna add a new package.

I don't know what hardware you run.
On my 4 years old Core2Duo 2GHz it never takes 20 minutes. Even if you do "svn update" and "make clean all" it is much faster, less than 5 minutes. Adding or modifying package is even faster.

I just tested: rebuild whole IDE from Qt4 to GKT2 takes 85 seconds (another brake may be my 5400 rpm disk).

[Martin_fr]

packages without taking 20 minutes

Building times like this are likely to a combination of smart-linking, and low memory.

Smart-linking requires a lot of memory, and if that is not avail then you get heavy swap file usage. And in this case linking can take forever.

On the other hand: The IDE itself (lazarus.exe) does not really benefit from smart-linking. Due to the designer's need to be able ta access all components, the IDE must include all code anyway. Smartlinking may at best save a few bytes.

I recommend to build the IDE without smart linking.

You can still build the LCL, and all packages as smart-linkable (-CX). So your own projects can be smart linked.
But do not use smart-link (-XX) in the IDE build options (or anywhere where it will apply to the IDE build)

[marcov]

The other way around: Delphi can use packages without taking 20 minutes to compile your IDE after your make a minor change or wanna add a new package.

I didn't even have such lazarus compile times back on my P-I.

If you want to spread negative sentiment, at least use facts. 
 

[wjackson153]

I didnt think Lazarus went back that far
wow P-1 with lazarus now that would be a sight to see haha

[teos]

The other way around: Delphi can use packages without taking 20 minutes to compile your IDE after your make a minor change or wanna add a new package.

I didn't even have such lazarus compile times back on my P-I.

If you want to spread negative sentiment, at least use facts. 

I will. And I do. I have (or at least try to) deep respect for the Lazarus/Freepascal community and I am very well aware that negative sentiment will only harm myself and my creditability.

But I have to correct a few things: compile time is waaaay longer, but I have a virtual machine with Suse which has 1024 mb memory and what I build is the Codetyphon large IDE.
Similar with Codetyphon bigIDe on my Lenovo R500 (core 2 duo, 4 gig RAM), costs more than 20 minutes to build.

The "out of the box" Lazarus indeed compiles much faster. And yes, I can perfectly imagine that all the extra packages of the "bigIDE" of CodeTyphon are causing this.

And I know: these are "apples and pears".

For my other issue:
in the source i have something like:
button1.click := @dothebuttonclick;

in a package I have to remove the @ to install it, after installing Lazarus complains untill I add the @ again.

[Leledumbo]

Similar with Codetyphon bigIDe on my Lenovo R500 (core 2 duo, 4 gig RAM), costs more than 20 minutes to build.

The "out of the box" Lazarus indeed compiles much faster. And yes, I can perfectly imagine that all the extra packages of the "bigIDE" of CodeTyphon are causing this.

Indeed, I've tried CodeTyphon a couple of times and removing unneeded packages is the irritating part after installation (more packages, more memory, more time to build). So, I give up and instead to have Lazarus installed on a new machine I just generate from my current machine and copy because it already contains only components that I need. Really fast build, installing a package never takes more than 10 seconds (with static linking, smart linking takes about 1 minute).

in the source i have something like:
button1.click := @dothebuttonclick;

in a package I have to remove the @ to install it, after installing Lazarus complains untill I add the @ again.

Probably a compiler mode mix (objfpc vs delphi), either in source or command line option.

[Martin_fr]

If you want to spread negative sentiment, at least use facts. 

I will. And I do. I have (or at least try to) deep respect for the Lazarus/Freepascal community and I am very well aware that negative sentiment will only harm myself and my creditability.

There is no issue with describing a problem you experience. The question is the intend. It is all ok, if you are looking for a solution, or confirmation of it being a known (not yet solved) issue, or similar.

It is questionable, if you spread such negative issues with the intend to damage the project, or to rant, or similar. You would have the right to do so, but it would equally tell about your personality...

But I have to correct a few things: compile time is waaaay longer, but I have a virtual machine with Suse which has 1024 mb memory and what I build is the Codetyphon large IDE.
Similar with Codetyphon bigIDe on my Lenovo R500 (core 2 duo, 4 gig RAM), costs more than 20 minutes to build.

Did you check, if smart linking is causing this?
IIRC a default install requires between 700 and 800 MB for smart linking. So code typhon, with lots of extras may well need more.
But without smart linking, it should be much better.

For my other issue:
in the source i have something like:
button1.click := @dothebuttonclick;

in a package I have to remove the @ to install it, after installing Lazarus complains untill I add the @ again.

Check the package options ("Compiler options", "parsing"). Make sure it uses the same syntax mode, that you use in your project. Also check for "{$Mode}" in the source.