Ales Katona wrote:
> I think that pascal typesystem requires a bit overhaul when it comes to
> integers.
>
> First of all Integer should be size independent, that is, xy bits
> depending on the platform. All others should be specific.
I agree with an application wide integer/cardinal type, but t
Linuxer Wang wrote:
>
> Hello,
>
> Can anybody tell me how can I know which specific type an instance of
> class is?
Check the ClassType or ClassName.
> The "is" operator seems weird when interface is used.
Add a GetObject method to your interfaces, that returns the object that
implements the
"Yury B." wrote:
> Two RTLs should be for Win32, one compiled for ANSI/DBCS and the other for
> UNICODE UCS-2 (WinNT), where a special type,
> say TUniString is AnsiString in the first version and
> UnicodeString in the second version.
> What do you think of it?
IMO there exis
Tomas Hajny wrote:
> The main problem is that there's a lot platform independent
> functionality in Crt unit which is re-implemented for every
> platform again and again. The best solution would be to throw all
> the individual implementations away completely and implement
> cross-platform Crt uni
Marco van de Voort wrote:
> > Do you mean that only one level of dependencies must be checked with
> > "uses", whereas even the indirectly #included files must be checked for
> > changes?
>
> You always have to do the #include. Always. Pre-compiled headers are
> possible, not trivial, since it re
Michael Van Canneyt wrote:
>
> On Sun, 27 Mar 2005, DrDiettrich wrote:
>
> > A friend of mine just has tested my archiver, with the following results
> > for an TAR with a million of files:
> >
> > PowerArchiver: 530 minutes.
> > My Unarch: 160 minutes.
A friend of mine just has tested my archiver, with the following results
for an TAR with a million of files:
PowerArchiver: 530 minutes.
My Unarch: 160 minutes.
I hope to get the original .tgz archive soon, in order to test it with
GNU gzip and tar as well. The time may decrease again when the lo
Marco van de Voort wrote:
> > The definitions of templates, inline procedures or macros do not
> > immediately contribute to the size of a compiled module, only when they
> > are *used* in code modules.
>
> That goes for all routines.
I'm not sure what you mean. A global procedure, exported in t
Micha Nelissen wrote:
> > Perhaps you missed that in C/C++ the preprocessor is typically (99.999%)
> > used to include header files, not source files. This is comparable to
> > Pascal "uses", not to {$Include}!
>
> What's the difference between a 'header' file, and a source file ? Header >
> fil
Florian Klaempfl wrote:
> >>C++ creates one monster module in this case as well.
> >
> >
> > I disagree. Neither the declarations (interface, header files) nor the
> > definitions (implementation, code modules) must reside in one file.
>
> How the sources are splitted doesn't matter. The compiler
Micha Nelissen wrote:
> The real question is: was the design of the code ok ?
Some dependencies cannot be removed by a redesign :-(
In some cases interfaces instead of classes can help, because they don't
need implementation in the same unit. But then the classes have to be
implemented as well.
Florian Klaempfl wrote:
> C++ creates one monster module in this case as well.
I disagree. Neither the declarations (interface, header files) nor the
definitions (implementation, code modules) must reside in one file. C
header files can #include each other, and some more or less advanced
techniqu
Michael Van Canneyt wrote:
> sorry, but I fail to see the problem ? The above makes all protected
> members of a class visible. This is normal, that is why they are
> protected. If you want to avoid that, make the members private. Then
> they are visible only in the same unit, even for other class
Ales Katona wrote:
> C++ requires "friend" only because it lacks the idea of modularity.
> Since all classes are "apart" they need some way to tell each other "I
> can use you"
> In pascal you simply put them into 1 unit.
That's why the C++ model is better, there exists no requirement to
implemen
Jonas Maebe wrote:
> > Couldn't the framepointer be last parameter in all modes ?
>
> That would still require some ugly hacks inside the parameter passing
> code, because of the fact that on x86 the callee removes the parameters
> from the stack and not the caller (so you'd still need a check
>
Michael Van Canneyt wrote:
> > type TFriendClass = class(TNotMyClass);
>
> This is a simple descendent.
Yes and no. The only purpose of this declaration is to get access to the
protected members of the class, not to extend the class in any way.
> > 3) What alternatives could be used, so that no
[EMAIL PROTECTED] wrote:
>
> > Let me add some more thoughts about procedural types:
> >
> > - I like the ability to declare procedural types, the ISO convention
> > looks like one of the many incredible C hacks to me :-(
>
> But it is standard pascal. And we need to support those zillion lines o
I just came about code that uses protected members of other classes,
defined in other units. In Delphi this possible by a declaration like:
type TFriendClass = class(TNotMyClass);
After this declaration the protected (and private?) members of
TNotMyClass are accessible, using TFriendClass as an t
Michael Van Canneyt wrote:
> 1. What happens if f would use a variable from somefun, and f is called
> when somefun is no longer executed ?
This can not happen when the function parameter cannot be stored
anywhere.
> 2. I see no difference whatsoever between typ_fun and iso_fun, except
>
Uberto Barbini wrote:
> Using natively utf-8 I think is impossible, because the encoding.
Support might be implmemented like/in MBCS support.
> Please note that at every Borland conference there is someone asking for
> Unicode support since Delphi2...
Not only for Delphi ;-)
> There are severa
peter green wrote:
> surely this also means
>
> 1: there has to be rtti for every field in every class so the compiler can
> follow the paths from the class
That's almost required, not only for classes but for all data types that
contain references (pointers) to managed objects.
It's not necess
Jamie McCracken wrote:
> A GC needs to trace an object's references to see if anything still
> points to it. How else can it decide whether an object is no longer in use?
GC starts from known alive object references, in static or local
variables, and follows the references in these objects to fur
Jamie McCracken wrote:
> A GC needs to trace an object's references to see if anything still
> points to it. How else can it decide whether an object is no longer in use?
GC starts from known alive object references, in static or local
variables, and follows the references in these objects to fur
Jamie McCracken wrote:
> A GC needs to trace an object's references to see if anything still
> points to it. How else can it decide whether an object is no longer in use?
GC starts from known alive object references, in static or local
variables, and follows the references in these objects to fur
Jamie McCracken wrote:
> Rather than continuing the GC stuff which seems fruitless I thought it
> might be better to improve what we have with ref counting (whilst taking
> a leaf out of the GC book as well).
A reasonable attempt.
> 2) Have a single linked list that contains references to all m
Uberto Barbini wrote:
> > You already have them in Iunknown, ansistrings and variants. Its all a
> > question of making them faster cause they are dog slow atm.
>
> I wish them "NOT" managed, you cannot free a interface in Delphi.
You can finalize it, so that it releases all private resources. T
Peter Vreman wrote:
> Why are you looking at GC/Refcounting when the problem is the try..finally?
> It is better to rewrite the try..finally code using the C++ ABI for
> exception handling.
Where do you see improvements in the C++ ABI? Or even differences?
Windows implements this ABI, and every
peter green wrote:
> one thing i have heared (i don't use garbage collected languages much so
> i've never seen this myself) is that the GC gets some CPU time and starts
> causing stuff to be swapped in. This slows other threads down which gives
> the GC more CPU and causes more stuff to be swappe
Jamie McCracken wrote:
> The problem with GC is the lifetime of (dead) objects is significantly
> extended under GC. This means it hogs more memory for much longer.
> Memory allocation is also potentially slowed as a result of more objects
> remaining allocated on the heap so less chance of holes
[EMAIL PROTECTED] wrote:
> At work, we have a plugin system which cannot work unless packages are used.
Agreed.
> I also think that Lazarus would benefit from it.
Currently Lazarus must be rebuilt for the installation of custom
controls, which in Delphi can be loaded dynamically. If this behav
Jamie McCracken wrote:
> GC is very inefficient with memory and current implementations tend to
> cost a lot performance wise too.
I don't see how GC is inefficient with memory?
Reference counting and (mark/sweep) garbage collection have a different
runtime behaviour: Reference counting occurs wi
Jamie McCracken wrote:
> Just wandering if any of you are interested in modernising Pascal which
> is looking quite dated when compared to modern languages like Python. I
> note free pascal supports a variety of pascal dialects but none of them
> are particular modern.
I'd suggest Oberon or a sim
Alexey Barkovoy wrote:
> Delphi dowsn't allow sets with ordinal values larger than 255 too:
That's incorrect.
> Borland Delphi Version 13.0 Copyright (c) 1983,99 Inprise Corporation
> 1.pas(2) Error: Sets may have at most 256 elements
Sets are restricted to a maximum of 256 members, but the o
Marco van de Voort wrote:
>
> > > TShiftState is defined as TShiftState = set of (...);
> > >
> > > How can I iterate through the enums? If not, can we split and add an
> > > enum:
> > >
> > > TShiftStateEnum = (...)
> > > TShiftState = set of TShiftStateEnum;
> > >
> > > ?
> >
> > Of course that
Peter Vreman wrote:
> > 1) Properties for Object type.
>
> Since which Delphi version is a property allowed in an normal object?
I'm not sure, but at least D4 supports such properties.
> Currently FPC has special code that forbids property in objects for delphi
> mode.
Then it would be suffici
Marco van de Voort wrote:
>
> > 2) Sets with minimal size, at least with 1 and 2 bytes for replacement
> > of Byte and Word types.
> >
> > I consider both features as vital in translations from C to Pascal, and
> > in the detection and elimination of bugs. Will it be possible to add
> > these feat
Alexey Barkovoy wrote:
> PAnsiChar, PChar are just pointers and not garbage collected by compiler. But
> AnsiString and WideString are compiler managed types. So, as Peter mentioned,
> behaviour you are seeing is by design.
In Delphi WideString is not reference counted at all. The layout of the
st
After eliminating dozens of bugs now I have a working version of
Abbrevia for Delphi. Unfortunately this version is not usable with FPC,
primarily because FPC doesn't support properties for the Object type.
In my code I like to use Object for records with methods and properties,
which need no dyna
Michael Van Canneyt wrote:
> > FPC defines 1900-1-1 as the start date, whereas Delphi defines
> > 1899-12-30 as the start date - note: neither 1900 nor dec. 31!
> > This requires different constants for converting a Unix date into
> > TDateTime, or portable procedures. What's the suggested way for
Alexey Barkovoy wrote:
> Delphi is compatible at least with Borland C++ and MS VC++. And taking in
> accout
> how COM intefaces are implemented in C++ (I'm supposing here all C++ compilers
> support the same syntax) - each C++ compiler supporting MS way to declare COM
> interfaces has compatible
Michael Van Canneyt wrote:
> > What time stamps are in use on the various platforms?
>
> Too various. I suggest using simply TDateTime. It has microsecond
> resolution, which should be more than enough. It offers the additional
> advantage that no transformations are necessary for display & compa
Currently I'm trying to define an object for file dates. This object
shall allow to compare time stamps for files on disk and in archives,
and it also shall be usable to set time stamps for such files. Now I'm
undecided what unique internal date/time representation to use in such
an object.
For co
Has somebody ever tried to run the Abbrevia tests, in
Abbrevia/source/dunit, under Windows?
I got so many errors that I could not yet run the tests to completion
:-(
One obvious error was an attempt to copy and delete an file prior to
closing it, more errors may have similar reasons. In this case
peter green wrote:
> it should be noted that pascal classes are really not suited to doing
> strings.
IMO we should distinguish Strings, as containers, from Text as an
interpretation of data as, ahem, text of some language, in some
encoding, possibly with attributes...
> to do strings with clas
Jonas Maebe wrote:
>
> On 6 jan 2005, at 22:21, DrDiettrich wrote:
>
> >> The FPC baseunix/unix units mimic more or less the POSIX standard
> >
> > As already mentioned, I couldn't find these units :-(
>
> They only exist for unix-like OS'es. The
Florian Klaempfl wrote:
> > The only universal international representation for strings is Unicode
> > (currently 32 bit), that doesn't require any conversions.
>
> That's not true. E.g. the german umlauts can be represented by 2 chars
> when using UTF-32 (the char and the two dots), same apply t
Jonas Maebe wrote:
> Why? There are cvs clients for pretty much any OS out there. Or does
> your working OS not have a network connection?
I have a network connection, that I use rarely when I need to access
some device built into my old computer. Everything else goes over the
phone line.
But pe
Peter Vreman wrote:
> >> If no major bugs are found, version 2.0 will be released in a short
> >> timeframe.
Only one major problem so far. Congratulations! :-)
> > So let me list the problems I encountered with a preceding version:
> >
> > - Mouse buttons inoperative (W2K, no menu selection...
peter green wrote:
>
> ok i see a MAJOR problem with the semantics of those functions.
>
> they assume that one widechar is equivilent to one ansichar (that is the
> source count of widechars will equal the destination count of ansichars or
> the source count of widechars will equal the destinati
Marco van de Voort wrote:
> You might also want to have a look at
>
> http://www.stack.nl/~marcov/porting.pdf
A very fine document, I'll have to study it in detail :-)
At the first glance I found some more or less important errors in this
document. Do you want an according list? How to refer to
Florian Klaempfl wrote:
> >>- easier navigation in editors
> >
> > Definitely NO, with regards to include files! (May miss your point?)
>
> Probably yes, you can easily open two editor windows viewing e.g.
> declaration and definition at once. Using splitted view is always a mess
> and requires m
Michael Van Canneyt wrote:
> > method allows to enumerate all contained DirectoryItems.
...
> On the condition that you also implement by default also a method returning
> a TList or TStringList with TDirectoryItems. Not everyone is comfortable
> with callbacks. The TList/TStringlist method should
Tomas Hajny wrote:
> > I only don't know how to implement or check the other branches - is the
> > Windows version of FPC equipped for crosscompilation?
>
> The compiler itself can compile for all platforms listed in help pages
The problem is that the installed FPC doesn't show any help - no fil
Michael Van Canneyt wrote:
> POSIX says nothing about pascal, it's basically a C interface.
To me POSIX means primarily the very different file handling, with
regards to devices, path separators, owner/group/world access rights
etc. This is what bites not only me when porting GNU software to
Wind
Tomas Hajny wrote:
> You can always download just the needed parts from
> ftp://ftp.freepascal.org/pub/fpc/beta/i386-win32-1.9.6/separate/ (for win32).
> You should always get install.exe and install.dat, then base.i386-win32.zip
> which contains the compiler and RTL. Whatever else is up to you
Michael Van Canneyt wrote:
> The FPC units are not POSIX, hence, UNIX.
> (long threads have already been spent on that, and it is a done deal)
I don't want to resurrect a discussion, but can somebody give me an idea
how UNIX and POSIX are different, with regards to FPC?
> > Question: What's pref
Marco van de Voort wrote:
> You might also want to have a look at
>
> http://www.stack.nl/~marcov/porting.pdf
>
> and
>
> http://www.stack.nl/~marcov/unixrtl.pdf
Ah, thanks :-)
> There are 4 cases for Unix:
>
> 1 Kylix
> 2 FPC/Linux/x86 reusing Kylix libc code.
> 3 FPC/Linux/x86 using genera
Michael Van Canneyt wrote:
> > Question: What's preferrable, a direct port of the Abbrevia library, or
> > a new and better portable design instead, that interfaces with the not
> > otherwise available worker classes as implemented in Abbrevia?
>
> Second option.
Here's my general idea of an Abb
Tomas Hajny wrote:
> > {$ifndef unix}
> > {$i abiuwin.inc} // more to follow later: e.g. Mac OS, Netware etc.
> > {$else}
> > {$i abiulin.inc}
> > {$endif}
>
> There's at least one (IMHO not worse at least) alternative to that (already
> used in FPC itself among others) - keep the include file na
Florian Klaempfl wrote:
> Not everything is a matter of OS. It could be also a matter of toolkit,
> database, word size of the cpu or whatever. Further smaller files are
> usually easier to handle:
> - cvs works much better with small files
Hmm...
> - easier navigation in editors
Definitely NO, w
[EMAIL PROTECTED] wrote:
> If no major bugs are found, version 2.0 will be released in a short
> timeframe.
I would like to test the Win32 distribution, but the archives are too
big for an download (narrow band) :-(
So let me list the problems I encountered with a preceding version:
- Mouse but
Michael Van Canneyt wrote:
> > I'm willing to demonstrate my ideas in a redesign and extension of
> > Abbrevia, so that we have a concreter base for further discussions. But
> > before starting with that work I would like to hear some encouraging
> > opinions or suggestions.
>
> I think you can
Michael Van Canneyt wrote:
> > 1) Target Dependencies
> Agreed 100%.
> In general, a component suite should have all os-dependent code in a single
> unit, presenting the rest of the suite with a uniform API.
Fine :-)
But how should that code be implemented? For various target platforms?
> > 2)
Nico Aragón wrote:
> > > IIRC, any non-zero value is evaluated as "True" for a Boolean variable.
> >
> > You should not guess about any implementation.
>
> I don't. Do I?
Yes, you do. How can you know what bit pattern is stored in a boolean
variable? Using typecasts may result in silent type co
Nico Aragón wrote:
> ¡Serás melón!
Could you please help me to improve my rudimentary Spanish? ;-)
(Eierkopf? ;-)
> ¡Feliz año, torpedo! :-)
(Blindgänger? ;-)
Feliz año, Bonne Année, Happy New Year, Gelukkige Nieuwe Jaar, und ein
Gutes Neues Jahr allerseits!
DoDi
_
In the meantime I downloaded the Abbrevia package from SourceForge, and
came across several unpleasent constructs. Please let me introduce my
preferred programming model for portable code.
1) Target Dependencies
I don't accept any OS or machine specific conditional compilation in
code, except in d
[EMAIL PROTECTED] wrote:
> > E.g.: gzip.xyz, is this based on a gzip unit or a gzip variable or...
>
> Does this matter to you ?
>
> Normally one never uses a fully qualified identifier.
And that can become a problem, when a variable and a unit has the same
name. That's why I do not only prefer
[EMAIL PROTECTED] wrote:
> Naming a unit with 'u' standard does not seem useful to me, but this is
> a matter of taste.
...
> All other files are assumed to be units.
> (projects/packages have distinct extensions anyway)
No problem at the directory level, but how to distinguish names of
units, ty
Marco van de Voort wrote:
> Better have a separate way. Otherwise you can't set e.g. a compressionlevel
> for that stream, _or_ you have to have lots of different constructors.
Compressors can require any kind and number of arguments, that must be
reflected somewhere, e.g. in the specific constru
peter green wrote:
>
> I think the old saying goes garbage in garbage out.
100%
> range checking should probablly catch this sort of stuff but that has a high
> performance penalty and is therefore usually disabled.
IIRC range checking occurs on assignments, not on using the values, just
to red
Nico Aragón wrote:
> IIRC, any non-zero value is evaluated as "True" for a Boolean variable.
You should not guess about any implementation. Forcing out-of-range
values into strictly typed variables is a user bug, at the full risk of
(and shame on) that user.
Who's to blame when somebody applies
Hi there,
I'm new to this list and want to introduce myself and my intended
contributions to FreePascal.
My name is Dr. Hans-Peter Diettrich, and I live in Flensburg (Germany).
For brevity I use to sign my messages as DoDi. My main interests are
decompilers and (tools for) porting code. Usually I
72 matches
Mail list logo
