The problem now is that cracker classes can't be used in future anymore
because of the new class field ordering optimisation, so I dared to ask.
==
The guys, this point is important !
All the discussion members are right in their arguments (Martin's
the community impatience to
On 14/07/2012 20:46, Jonas Maebe wrote:
That may actually lead to quite some troubles: if someone recompiles the RTL without
optimizations, then your class crackers also have to change that setting. And there's no
way to detect how the RTL (or in general: units containing classes you are
On 21/07/2012 16:55, Ivanko B wrote:
The problem now is that cracker classes can't be used in future anymore
because of the new class field ordering optimisation, so I dared to ask.
So, is it possible to design the new feature in such way that to have
an option to proceed using cracker
Or an option:
{$ifdef nonLazarus}
protected
...
{$else}
private
...
{$endif}
Then MSEgui/FPgui/.. may be compiled with -DnonLazarus option
2012/7/21, Ivanko B ivankob4m...@gmail.com:
The problem now is that cracker classes can't be used in future anymore
because of the new class field
Am 21.07.2012 18:48, schrieb Martin:
On 21/07/2012 16:55, Ivanko B wrote:
The problem now is that cracker classes can't be used in future anymore
because of the new class field ordering optimisation, so I dared to
ask.
So, is it possible to design the new feature in such way that to
I don't see cracker classes as valid code.
=
Then the FPC team should eliminate the need in such crackers - via
either disabling (via licencing, prisoning etc) the impatient
[mainly because of impatient customers] non-mainstreams (non-Lazarus)
or meeting needs of the non-mainstreams (
Am 21.07.2012 20:47, schrieb Ivanko B:
I don't see cracker classes as valid code.
=
Then the FPC team should eliminate the need in such crackers - via
either disabling (via licencing, prisoning etc) the impatient
[mainly because of impatient customers] non-mainstreams
No, just reorder the fields so that they can be properly $IFDEFed as
protected for nonLAZARUS and left (private) as is otherwise. Sure not
every filed but those the non-mainstreams developers ask. This'll
allow the non-mainstreams to start fixing right now.
Florian, it's a huge headache for
Smth like the below:
type
TNonCrackableClass = class
private
fldPrivate1: integer;
fldPrivate2: styring;
{$ifndef nonLazarus}
fldPrivate3: real; // for LAZARUS
{$else}
protected
fldPrivate3: real; // for MSEgui/FPgui
{$endif}
protected
fldProtected1: string
public
[..]
end;
Am 21.07.2012 23:06, schrieb Ivanko B:
No, just reorder the fields so that they can be properly $IFDEFed as
protected for nonLAZARUS and left (private) as is otherwise.
Why should lazarus people have less chances to mess with private fields?
Either we make them public for all or for nobody. Of
Why should lazarus people have less chances to mess with private fields?
=
AFAIK, they haven't to use any crackers up to now and it is a normal
way for the mainstream - where complier IDE are maintained by same
team so fixing any bugs is much more urgent than for no-mainstream.
Either we
But for very base (not yet specialized) classes - a good idea.
2012/7/22, Ivanko B ivankob4m...@gmail.com:
Why should lazarus people have less chances to mess with private fields?
=
AFAIK, they haven't to use any crackers up to now and it is a normal
way for the mainstream - where
Hi,
There MoveChars* function (or similar) native on Free Pascal?
(*) -
http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/System_MoveChars.html
Thanks,
--
Silvio Clécio
My public projects - github.com/silvioprog
On Saturday 21 July 2012 23:57:50 Florian Klämpfl wrote:
Am 21.07.2012 23:06, schrieb Ivanko B:
No, just reorder the fields so that they can be properly $IFDEFed as
protected for nonLAZARUS and left (private) as is otherwise.
Why should lazarus people have less chances to mess with private
14 matches
Mail list logo
