[fpc-pascal] Why isn’t SizeOf() allowed in generic arrays?
Hi, Could somebody explain why SizeOf() cannot be used in the definition of generic arrays? I know this is a current limitation of Delphi, but will it be possible to have this feature in Free Pascal first? -- Best Regards, J.-c. Chu ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why isn’t SizeOf() allowed in generic arrays?
type TBytesOverlayT = array [0..SizeOf(T) - 1] of Byte On March 29, 2012, Sven Barth wrote: Am 29.03.2012 10:14, schrieb J.-c. Chu: Hi, Could somebody explain why SizeOf() cannot be used in the definition of generic arrays? I know this is a current limitation of Delphi, but will it be possible to have this feature in Free Pascal first? Can you give a concrete example what you want to achieve, please? Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal -- Best Regards, J.-c. Chu ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why isn’t SizeOf() allowed in generic arrays?
Bug report filed at http://bugs.freepascal.org/view.php?id=21592. Also, another, possibly related bug has been filed at http://bugs.freepascal.org/view.php?id=21593. On March 29, 2012, Sven Barth wrote: Your code should work as well, as e.g. TBytesOverlayLongInt should result in the above code. So please report this as a bug. -- Best Regards, J.-c. Chu ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generics Compile Error, 2.4.2 vs 2.6.0
If you are compiling the unit in Delphi mode, you’ll need to use the
syntax of Delphi.
* Generics are defined without the GENERIC keyword.
* Generics are specialized without the SPECIALIZE keyword.
* To define class-local types and variables, visibility specifiers need
to be placed before the TYPE and VAR keywords.
* Implementations of the methods of a generic class must include the
type parameters of the class.
Please check if the attached file works.
On February 14, 2012, David Copeland wrote:
Under FPC 2.4.2 I have been using RBTree unit that uses generics. With
2.6.0 it fails to compile. I know that there have been changes for 2.6.0
but I have checked the syntax in the 2.6.0 Language Reference and cannot
see why the error is occurring. I have also looked in Mantis but don't
know if anything there relates to my problem. I have excerpted the code
below and attached the complete unit.
==
unit FOS_REDBLACKTREE_GEN;
// (c) Copyright FirmOS Business Solutions GmbH
// Author Helmut Hartl, Franz Schober
}
//{$MODE OBJFPC}
{$MODE DELPHI}
{$H+}
interface
type
TRB_NodeColor=(R,B);
{ TGFOS_RBTree }
{$B-}
generic TGFOS_RBTree_TKey,_TStore = class(TInterfacedObject)
*** The error occurs at the line above.
Free Pascal Compiler version 2.6.0 [2012/02/08] for x86_64
Copyright (c) 1993-2011 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling FOS_REDBLACKTREE_GEN.pas
FOS_REDBLACKTREE_GEN.pas(48,11) Fatal: Syntax error, = expected but
identifier TGFOS_RBTREE found
Fatal: Compilation aborted
type public
PFOS_RB_NodeG=^TFOS_RB_NodeG;
_PStore =^_TStore;
TFOS_RB_NodeG = packed record
k: _TKey;
left, right, parent: PFOS_RB_NodeG;
col: TRB_NodeColor;
val:_TStore;
end;
TCompareKeys = function (const Item1, Item2: _TKey):
Integer;
TGUndefined = function :_Tstore;
TGUndefinedKey = function :_TKey;
TGFOS_RB_OnItem = procedure (const Item:_TStore) of object;
TGFOS_RB_OnItemN = procedure (const Item:_TStore);
==
Thanks for any help.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
--
Best Regards,
J.-c. Chu
unit FOS_REDBLACKTREE_GEN;
// (c) Copyright FirmOS Business Solutions GmbH
// Author Helmut Hartl, Franz Schober
{ // New Style BSD Licence (OSI)
Copyright (c) 2001-2009, FirmOS Business Solutions GmbH
All rights reserved.
Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
* Neither the name of the FirmOS Business Solutions GmbH nor the names
of its contributors may be used to endorse or promote products derived
from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
}
//{$MODE OBJFPC}
{$MODE DELPHI}
{$H+}
interface
type
TRB_NodeColor=(R,B);
{ TGFOS_RBTree }
{$B-}
TGFOS_RBTree_TKey,_TStore = class(TInterfacedObject)
public
type
PFOS_RB_NodeG=^TFOS_RB_NodeG;
_PStore =^_TStore;
TFOS_RB_NodeG = packed record
k: _TKey;
left, right, parent: PFOS_RB_NodeG;
col: TRB_NodeColor;
val:_TStore;
end;
TCompareKeys = function (const Item1, Item2: _TKey): Integer;
TGUndefined = function :_Tstore;
TGUndefinedKey = function :_TKey;
TGFOS_RB_OnItem = procedure (const Item:_TStore) of object;
TGFOS_RB_OnItemN = procedure (const Item:_TStore);
private
var
_Count:QWord;
_Compare: TCompareKeys;
_Undef:TGUndefined;
_UndefKey: TGUndefinedKey;
root: PFOS_RB_NodeG
Re: [fpc-pascal] Advanced Records - Why not available by default?
Frankly, every new feature will be a mere increase of complexity if you reject learning about it. There is a listing, despite not up-to-date, of new language features since Delphi 7, at http://edn.embarcadero.com/article/34324. Not all of them are currently implemented in FPC. Could you point out which of them is “nonsense” or “only saves some keystrokes”? On January 15, 2012, Jürgen Hestermann wrote: Lars schrieb: Personally, I'm getting sick of all the new features added to delphi that don't add anything meaningful, and just add complexity to the compiler. why didn't borland just make people use old borland objects with methods instead of new advanced records? Old borland objects are advanced records.. Ticking me off more: why do we even have objects and classes? what is an object? what are classes? I would have preferred if borland would have just called old borland objects Extended records from day one. Now we have this feature overload in the language and it's becoming more and more complex of a language (needlessly). Objects, Classes, records.. aren't they all the same thing? I don't even personally buy the idea that objects even exist.. i think they are just extended records. What is an object? an instance of a class? if so, why did borland call the type definition object if it was supposed to be a class? Ugh. Ugly language - it is becoming - sorry to say! I agree wholeheartly with you!! Lots of nonsense is added that is already available otherwise (or only saves some keystrokes). In the past Pascal was an easy to learn (still powerfull) language. Today the direction goes into increased complexity as all the other languages and nobody realy understands it anymore so programmers code in a suboptimal manner more and more. Some may say: You don't have to use it. That's true. But I am also no longer able to read foreign code (i.e. Lazarus program code) because all these strange concepts are used there. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal -- Best Regards, J.-c. Chu ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Advanced Records - Why not available by default?
class abstract? On January 15, 2012, Marco van de Voort wrote: Which ones aren't? -- Best Regards, J.-c. Chu ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Advanced Records - Why not available by default?
The attached file does not compile in my trunk-version compiler.
On January 16, 2012, Sven Barth wrote:
On 15.01.2012 16:55, J.-c. Chu wrote:
class abstract?
On January 15, 2012, Marco van de Voort wrote:
Which ones aren't?
Implemented since 2.4.2 or 2.4.4 AFAIK.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
--
Best Regards,
J.-c. Chu
{$MODE delphi}
type
TTestClass = class abstract
procedure TestMethod;
end;
begin
end.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Advanced Records - Why not available by default?
For one thing, class variables, class methods, and class properties are subject to visibility controls and inheritance. So you can, for example, have a private class variable initialized with class constructor (which avoids code in the INITIALIZATION section) and accessed via a read-only class property (which is impossible with unit-level variables). These “advanced” features are there to provide better encapsulation. And if you don’t need object-oriented programming, I don’t think they’re going to harm you or your programs, either. On January 15, 2012, Daniel Gaspary wrote: On Sat, Jan 14, 2012 at 21:59, Lars nore...@z505.com wrote: Personally, I'm getting sick of all the new features added to delphi that don't add anything meaningful, and just add complexity to the compiler. I agrre with you. I like some features of advanced records. But a lot of things seems a big redundancy. The possibility of class vars specially surprised me ? For What purpose that could be good for ? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal -- Best Regards, J.-c. Chu smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
