Sergei Gorelkin schreef:
Hello,
Here is the next portion of my patches to XML stuff:
dom.pp:
- Removed unneeded TDOMNode.FNodeName/FNodeValue fields to reduce
memory requirements;
- finished TDOMElement.GetElementsByTagName;
- Implemented TDOMNode.TextContent property;
- Implemented attribute v
On Tue, 3 Oct 2006, Vincent Snijders wrote:
> Sergei Gorelkin schreef:
> > Hello,
> >
> > Here is the next portion of my patches to XML stuff:
> >
> > dom.pp:
> > - Removed unneeded TDOMNode.FNodeName/FNodeValue fields to reduce
> > memory requirements;
> > - finished TDOMElement.GetElementsBy
On Monday 02 October 2006 17:16, Micha Nelissen wrote:
> Chris Cheney wrote:
> >> I'm pretty sure he means that no can no longer, for example, copy
> >> a function from one class to another, without risking having to
> >> rewrite all the parameter names.
> >
> > You have understood me correctly - I
> On 10/2/06, Marco van de Voort <[EMAIL PROTECTED]> wrote:
> > The type of a is secure in the second part, and it is faster. Keep in mind
> > that more elaborate syntax increases the chance of copying/referencecount
> > changing etc etc.
> >
> > E.g. the standard example is printf. There the firs
On Tue, 3 Oct 2006, Marco van de Voort wrote:
> > But the response is not correct.
> > For example, I do not like the fact in VB that I must use "," without
> > parameter if I "don't' want to use" this parameters.
>
> But probably there will be a reason. Some form of disambiguation that this
>
Sergei Gorelkin schreef:
Hello,
Here is the next portion of my patches to XML stuff:
dom.pp:
- Removed unneeded TDOMNode.FNodeName/FNodeValue fields to reduce
memory requirements;
- finished TDOMElement.GetElementsByTagName;
- Implemented TDOMNode.TextContent property;
- Implemented attribute v
On Tue, Oct 03, 2006 at 07:36:11AM +, Vinzent Hoefler wrote:
> On Monday 02 October 2006 17:16, Micha Nelissen wrote:
> > Ok, so enforcing different names is good then, that makes code more
> > context insensitive, since identifiers won't suddenly "resolve" to
> > parameters with the same name.
On Tuesday 03 October 2006 11:15, Micha Nelissen wrote:
> On Tue, Oct 03, 2006 at 07:36:11AM +, Vinzent Hoefler wrote:
> > On Monday 02 October 2006 17:16, Micha Nelissen wrote:
> > > Ok, so enforcing different names is good then, that makes code
> > > more context insensitive, since identifier
On 10/2/06, Daniël Mantione <[EMAIL PROTECTED]> wrote:
Op Mon, 2 Oct 2006, schreef ik:
> > Well, I think that this is also a functional thing.
> >
> > >
> > > * Syntactically, both methods can be safe.
> > > * Syntactically, the FPC/Delphi one is more powerfull.
> >
> > Well take a look at the
On 10/3/06, Marco van de Voort <[EMAIL PROTECTED]> wrote:
> On 10/2/06, Marco van de Voort <[EMAIL PROTECTED]> wrote:
> > The type of a is secure in the second part, and it is faster. Keep in mind
> > that more elaborate syntax increases the chance of copying/referencecount
> > changing etc etc.
Mattias Gaertner schreef:
On Fri, 29 Sep 2006 16:32:23 +0200 (CEST)
Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
On Fri, 29 Sep 2006, Vincent Snijders wrote:
Michael Van Canneyt schreef:
On Fri, 29 Sep 2006, Vincent Snijders wrote:
Hi,
The LCL contains the non-visual unit LCLMemManager
Hi,
Attached patch modifies compiler to enable typed addresses ({$T+}) for
fpc and objfpc modes by default. It fixes the rtl and compiler to
compile again. Most of these fixes are simple pointer to array vs.
pointer to element of array changes, but some reveal ugly code IMHO ;-).
Anyway, any opin
On Tue, 3 Oct 2006, Vincent Snijders wrote:
> > > > What about TMemoryPool and TNonFreeMemoryPool?
> > > Don't you think the word MemoryManager (MM) should be in it ?
> >
> > This could cause confusion with TMemoryManager.
> >
> >
> > > like pooledmm ? (and class TPooledMemoryManager) ?
>
>
> There's a reason, I always write "self.Identifier" and I also refuse to
> revert back to the so called Hungarian notation (like AParameter). Even
> if there is *no* parameter and/or field with that name it's always
> clear which part is meant.
This is not Hungarian notation. Hungarian is to pre
Michael Van Canneyt wrote:
On Tue, 3 Oct 2006, Vincent Snijders wrote:
What about TMemoryPool and TNonFreeMemoryPool?
Don't you think the word MemoryManager (MM) should be in it ?
This could cause confusion with TMemoryManager.
like pooledmm ? (and class TPooledMemoryManager) ?
I ag
On Tue, 3 Oct 2006, Vincent Snijders wrote:
> Michael Van Canneyt wrote:
> >
> > On Tue, 3 Oct 2006, Vincent Snijders wrote:
> >
> >
> > > > > >What about TMemoryPool and TNonFreeMemoryPool?
> > > > >
> > > > >Don't you think the word MemoryManager (MM) should be in it ?
> > > >
> > > >This c
Micha Nelissen wrote:
Marco van de Voort wrote:
Changing type to something which is not a descendant (and thus
incompatible) seems useless and always dangerous to me, so should be
forbidden if possible.
I also considered it that way. But maybe the "absolute" keyword is then a
bit badly chosen,
> On 10/3/06, Marco van de Voort <[EMAIL PROTECTED]> wrote:
> > >
> > > I agree here, but as I said (I hope), you need some sort of compiler
> > > directive to enable such thing. By default it should accept only []. I
> > > agree with that. And as I said before, this is a petty thing only.
> >
> >
Hi,
psrc:[EMAIL PROTECTED], is this correct ? Shouldn't it be FList^, since FList
is a pointer to an array of pointers ?
Micha
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Micha Nelissen wrote:
> Hi,
>
> psrc:[EMAIL PROTECTED], is this correct ? Shouldn't it be FList^, since FList
> is a pointer to an array of pointers ?
Sorry, fpc 2.1.1, compiler/cclasses.pas. Same story for TFPHashList.Pack
btw.
Micha
___
fpc-devel mai
On Tuesday 03 October 2006 16:26, Flávio Etrusco wrote:
> At my workplace we've standardized on using three "scope prefixes":
> p_ for function parameter, m_ for members/fields, and g_ for global.
I know that discussion, I lost it at work already, but apart from C
where every identifier is sort
21 matches
Mail list logo
