On Mon, 15 Jul 2013, luciano de souza wrote:
hello all,
I want to compile a program with no visible screen, but at the same
time, with input and output enabled.
If I use $apptype gui, the screen is invisible, but there are not
input and output.
Correction: there is input and output, just not
Hi
I have a question about dynamic strings and memory allocation.
If you look at my example underneath, I depend on that a dynamic string always
is assigned
memory space in one connected block. But will that always be the case in
various operating
systems.
Carsten
Function Sum(p:pointer; le
On 07/16/2013 12:17 PM, Carsten Bager wrote:
If you look at my example underneath, I depend on that a dynamic string always
is assigned
memory space in one connected block.
As the compiler allows for assigning a string to a pchar, the strings
need to be compatible to C strings. Thus:
- The con
On Tue, 16 Jul 2013, Carsten Bager wrote:
Hi
I have a question about dynamic strings and memory allocation.
If you look at my example underneath, I depend on that a dynamic string always
is assigned
memory space in one connected block. But will that always be the case in
various operating
sy
Why not just skip all the encoding uncertainity of strings and use an
array of byte/char?
It'll probably be a lot faster too
Den 16-07-2013 12:17, Carsten Bager skrev:
Hi
I have a question about dynamic strings and memory allocation.
If you look at my example underneath, I depend on that a dyn
In our previous episode, Carsten Bager said:
> Function Sum(p:pointer; len:LongInt):LongInt;
> Type
> a_typ=array[0..pred(maxLongInt)] of byte;
> a=^a_typ;
> var
> i:LongInt;
> Begin
> result:=0;
> for i:=0 to len do
> result:=result+a(p)^[i];
> End;
0..len is len+1 items.
>
> Pro
> Of course the OS is free to use the mapped hardware RAM address in a way
> that for DMA the string content might come in separate chunks.
>
> Is this what you mean ?
>
> - Michael
Yes
Thanks
Carsten
___
fpc-pascal maillist - fpc-pascal@lists.fre
My code was just an example, to illustrate what I was aiming at. It is not
actually used.
But I think you have a point
Carsten
> Why not just skip all the encoding uncertainity of strings and use an
> array of byte/char?
>
> It'll probably be a lot faster too
_
On 15 July 2013 22:58, Kenneth Cochran wrote:
>
>
>
> I completely disagree. It is the code that is the primary expression of
> intent not the comments. This is mainly accomplished through sensible
> identifier naming. Comments exist to compensate for a developer's inability
> to express intent t
On 7/16/2013 17:56, vfclists . wrote:
I have 2 main concerns here, a comment for the component itself which is not
particularly important and a comment for the component when I add it to a form
or data module. When I create a method I can add a comment to the method. If I
create a component in co
On 2013-07-16 09:10, Michael Van Canneyt wrote:
>
> You should compile this app with $apptype GUI, and disable all diagnostic
> information
> (i.e. comment out all writeln statements)
Exactly what Michael said. You can also enable you app to start-up in
the system tray. Not showing the main for
11 matches
Mail list logo
