Re: [fpc-pascal] Pointer to a const char
On 11/04/2013 02:18 PM, Alexander wrote: How can I describe a "pointer to a constant char" in FreePascal? For example this C function: int some_func(const char *arg, ...); My guess in FreePascal is this(with ctypes unit): function some_func(const arg: pcchar): cint; cdecl; external; A constant argument to a function. I'm not sure, is it a "constant pointer to a char", or a "pointer to a constant char". In fact in c const "char *arg" does not mean a constant pointer to a character, but a pointer to a constant character, As in C you need to pass explicit pointers and in Pascal you can do this implicitly by using var or const, I suppose function some_fuc(const arg: char): cint; cdecl; external; should do this. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pointer to a const char
Le 04/11/2013 14:18, Alexander a écrit : How can I describe a "pointer to a constant char" in FreePascal? For example this C function: int some_func(const char *arg, ...); ... coulb be translated to some_proc(const arg: PChar, ...); where the argument cannot be changed in any way (the compiler complains) but the data to which the argument points can be freely changed, thus: (arg + offset)^ := #0; works I don't know a way to make the data pointed to, as being constant. Have a look at http://www.freepascal.org/docs-html/ref/refsu61.html#x160-1714.4.4 Antonio. My guess in FreePascal is this(with ctypes unit): function some_func(const arg: pcchar): cint; cdecl; external; A constant argument to a function. I'm not sure, is it a "constant pointer to a char", or a "pointer to a constant char". The first one applies. -- Alex ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal -- Antonio Fortuny Senior Software engineer 220, avenue de la Liberté L-4602 Niederkorn Tel.: +352 58 00 93 - 93 www.sitasoftware.lu ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support
On Mon, Nov 4, 2013 at 10:44 PM, Dmitry Boyarintsev wrote: > On Mon, Nov 4, 2013 at 6:07 PM, Marcos Douglas wrote: >> >> Sorry, but this is boring. >> Do you not agree that is much better propose a solution to be possible >> to use two -- or more -- units that have the same name but works >> together at the same project? > > Thought process is a boring thing in nature - it supposed to exhaust brain. =) > I definitely disagree on benefit of that. Since it opens door not bring a > unit name from a source to command-line. > You'll have a project of 10 Classes.pas and you'll define their actual name > in command line: > fpc -ALIAS/graphics/classes.pas Graphics -ALIAS/audio/classes.pas audio > -ALIAS/math/classes.pas > > On another project the same unit, might get another alias: > fpc -ALIAS/graphics/classes.pas Graph -ALIAS/audio/classes.pas sounds But in Java we have the "same" feature. A project can point to com.company.foo.lib.MyClass but another project can use only lib.MyClass. The packages are defined using directories. Is Java a mess too? IMHO, my proposal is more flexible than Java because we won't have a "hard code" for path like Java does. Only the compiler will know about it, not the sources. > So management of this kind of projects and libraries turns into a funny > process. The big difference is that we are talking about our projects, not 3rd-party libraries. You -- or the company where you works -- will decide what names will be better than others, etc. > From that point of view name spaces (as they're declared in sources) becomes > far more predictable. > > But again, back to namespaces, why people couldn't use underscores "_"? The > same domain pattern: > "org_douglas_marcos_classes.pas" > "org_mse_classes.pas" > With Delphi 2 the 8.3 file name limitation was removed and everybody could > start growing their domain libraries. We back again... The name collision continues! The problem is: We do not know all names used around the world. > Ok, nevermind. From what I see the biggest issue is linking and I guess RTTI > (eventually) I don't think so. Even the names of the units could be changed "on demand" by the compiler, using the ALIAS defined before. The linker would remain the same, without changes. Best regards, Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: [Bulk] Re: Namespaces Support
> The packages are defined using directories. Is Java a mess too? Yes, exactly, that's what makes Java package system messy. It makes refactoring (or restructurization) extremely difficult for deep package hierarchy. On Tuesday, November 5, 2013 6:37 PM, Marcos Douglas [via Free Pascal - General] wrote: On Mon, Nov 4, 2013 at 10:44 PM, Dmitry Boyarintsev ><[hidden email]> wrote: >> On Mon, Nov 4, 2013 at 6:07 PM, Marcos Douglas <[hidden email]> wrote: >>> >>> Sorry, but this is boring. >>> Do you not agree that is much better propose a solution to be possible >>> to use two -- or more -- units that have the same name but works >>> together at the same project? >> >> Thought process is a boring thing in nature - it supposed to exhaust brain. > >=) > >> I definitely disagree on benefit of that. Since it opens door not bring a >> unit name from a source to command-line. >> You'll have a project of 10 Classes.pas and you'll define their actual name >> in command line: >> fpc -ALIAS/graphics/classes.pas Graphics -ALIAS/audio/classes.pas audio >> -ALIAS/math/classes.pas >> >> On another project the same unit, might get another alias: >> fpc -ALIAS/graphics/classes.pas Graph -ALIAS/audio/classes.pas sounds > >But in Java we have the "same" feature. A project can point to >com.company.foo.lib.MyClass but another project can use only >lib.MyClass. >The packages are defined using directories. Is Java a mess too? > >IMHO, my proposal is more flexible than Java because we won't have a >"hard code" for path like Java does. Only the compiler will know about >it, not the sources. > >> So management of this kind of projects and libraries turns into a funny >> process. > >The big difference is that we are talking about our projects, not >3rd-party libraries. >You -- or the company where you works -- will decide what names will >be better than others, etc. > >> From that point of view name spaces (as they're declared in sources) becomes >> far more predictable. >> >> But again, back to namespaces, why people couldn't use underscores "_"? The >> same domain pattern: >> "org_douglas_marcos_classes.pas" >> "org_mse_classes.pas" >> With Delphi 2 the 8.3 file name limitation was removed and everybody could >> start growing their domain libraries. > >We back again... The name collision continues! >The problem is: We do not know all names used around the world. > >> Ok, nevermind. From what I see the biggest issue is linking and I guess RTTI >> (eventually) > >I don't think so. Even the names of the units could be changed "on >demand" by the compiler, using the ALIAS defined before. The linker >would remain the same, without changes. > >Best regards, >Marcos Douglas >___ >fpc-pascal maillist - [hidden email] >http://lists.freepascal.org/mailman/listinfo/fpc-pascal > > >> > >If you reply to this email, your message will be added to the discussion >below:http://free-pascal-general.1045716.n5.nabble.com/Namespaces-Support-tp5717153p5717420.html > >To unsubscribe from Namespaces Support, click here. >NAML > > -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Namespaces-Support-tp5717153p5717421.html Sent from the Free Pascal - General mailing list archive at Nabble.com.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support
On Tue, 5 Nov 2013 07:10:21 -0800 (PST) leledumbo wrote: > > The packages are defined using directories. Is Java a mess too? > > Yes, exactly, that's what makes Java package system messy. It makes > refactoring (or restructurization) extremely difficult for deep package > hierarchy. Java has no "package hierarchy" it's just names. It has no concept of sub-packages it's just folders. R. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: [Bulk] Re: Namespaces Support
On Tue, Nov 5, 2013 at 12:10 PM, leledumbo wrote: >> The packages are defined using directories. Is Java a mess too? > > Yes, exactly, that's what makes Java package system messy. It makes > refactoring (or restructurization) extremely difficult for deep package > hierarchy. So I proposed something better. ;-) Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pointer to a const char
On 05 Nov 2013, at 09:07, Antonio Fortuny wrote: > I don't know a way to make the data pointed to, as being constant. There is indeed no way to specify that in Pascal. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
