Re: [fpc-devel] Suggestion for change: Overly strict check
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 of global, there's absolutely no need for this: Writing this/self. removes the need for m_ and even adds some sort of safety, because that's one rule the compiler can actually check. - That's one. The difference between locals and paranetrized locals does not need to be mentioned at all, because inside the function they behave the same and have the same scope. - That' two. Globals should be forbidden. That's three. Hmm, ok, if really needed, you should prefix the unit name to ensure sudden name clashes (like my Break identifier) anyway, so globals are easily identified simply by being used already. - So, now that's three. I have used scope prefixes long before this/them and I as a somewhat-die-hard-Pascal-programmer had a hard time getting used to the underscores, which seems to divide the identifier and makes you code look like C, but I barely notice it now ;-) And it's very practical for code completion :-) Well, since my variable names tend to be longer than four chars, I always use underscores and my code sure does NOT look like C. ;) ItMakesIdentifiersMoreReadableBecauseTheUnderscoreIsAsCloseAsYouCanGetToNormalTextWithoutUsingWhitespace. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TFPList.Pack
Peter Vreman wrote: 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 ? It is correct. It is the address of the first pointer in the array of pointers. Conceptually, it is wrong. On the implementation level it may be correct. FList = ^(array[0..Max] of Pointer); FList[0] = (array[0..Max] of Pointer); @FList[0] = ^(array[0..Max] of Pointer) = FList; So address: (@FList[0])[1] = (ptrint(FList) + 1 * sizeof(array[0..Max] of Pointer))); Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Old sockets stuff and SSockets...
I'm currently about to fix certain issues with old sockets functions. I'm talking about Accept and Connect functions with Text parameters. These are currently only present in win32 sockets and are basicly a leftover from an old idea gone wrong. I want to remove them but if someone feels that that's a real requirement for them to stay (remember, currently they remain only in windows sockets) tell me. Secondly there's some new SSockets bugreps/feature requests come up. I understand MvC made SSockets right? Is the unit to be considered atleast viable? I didn't look much at it but from what I hear it's rather old. I'm not sure what to do about SSockets tbh (wether to update/accept user extentions and features or tell them it's deprecated or even delete the thing) Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Old sockets stuff and SSockets...
On Wed, 4 Oct 2006, Ales Katona wrote: I'm currently about to fix certain issues with old sockets functions. I'm talking about Accept and Connect functions with Text parameters. These are currently only present in win32 sockets and are basicly a leftover from an old idea gone wrong. I want to remove them but if someone feels that that's a real requirement for them to stay (remember, currently they remain only in windows sockets) tell me. For me you can remove them, if you fix the examples. Secondly there's some new SSockets bugreps/feature requests come up. I understand MvC made SSockets right? Yes. Is the unit to be considered atleast viable? I didn't look much at it but from what I hear it's rather old. Personally, I would be delighted to see the lnet stuff replace the ssockets in the FCL. I don't have time to maintain the ssockets any more. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Adding a unidirectional dataset to sqldb
Hi all, I have plans to add an unidirectional dataset/query to sqldb. Thus one that isn't inherited from TDataset. This to improve performance, for for example cgi-like programs, in which iterating back and forth through a database isn't necessary. But while working on this, I discovered that very much code from TSQLQuery could be exactly copied to this new class. Now I'm thinking about using an interface, to avoid double code. But I don't know what effect that has on run-time performance. I mean, the idea was to make if faster ... Any thoughts on this? regards, Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] va(r)_arg vs open array
For example: %d/%d/%d (dd/mm/) Hello %s(Mr). %s (Van Der Voot), Thank you for interesting in our %s(product). %s (Marco) we are more then happy to help you and give you additional information about %s (product). You can either call us at the phone number of 1234567890 extension %d (1) for customer support. You can also contact our sails department at phone number 1234567890 extension %d (666) for upgrading your %s (product), or just to ask additional questions. You can also contact our support team at the email of [EMAIL PROTECTED] (support/product name). Regards, Abraham Lincolen, Late US president. If this is really the case that cause you demand var_args feature, then obviously you have problem with your software design. I agree with Marco. :) I wrote a program to solve a problem exactly like this without need of var_args feature. Even though var_args is provided, I won't use it either, since -IMO- var_args isn't the correct way to solve this kind of problem. The above problem can be solved easily with a simple find-and-replace-like algorithm. IMO, basically this is a template filling. Just put a unique tags on every place that need to be filled with a value. Parse the template and replace every tag with appropriate value and format. Likely this must be done by a specialized class for this purpose. With this solution, my program can do the job very well with more than 200 kind of tags on more than 20 kind of templates (and increasing by the day). The users can even build their own template(s) through a template builder wizard from my application. I believe the wizard can't be easily build just using var_args. Your sample above, using my solution will become a template like this (less or more): For example: DATE:TODAY Hello CUSTOMER:TITLE. CUSTOMER:LAST_NAME, Thank you for interesting in our PRODUCT:NAME. CUSTOMER:FIRST_NAME we are more then happy to help you and give you additional information about PRODUCT:NAME. You can either call us at the phone number of 1234567890 extension PHONE_EXT:CUSTOMER_SUPPORT for customer support. You can also contact our sails department at phone number 1234567890 extension PHONE_EXT:PRODUCT_UPGRADE for upgrading your PRODUCT:NAME, or just to ask additional questions. You can also contact our support team at the email of PRODUCT:EMAIL. Regards, DIRECTOR:FULL_NAME, JOB_TITLE:DIRECTOR. Or am I missing something here? -Bee- has Bee.ography at: http://beeography.wordpress.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adding a unidirectional dataset to sqldb
On Thursday 05 October 2006 00.38, Joost van der Sluis wrote: Hi all, I have plans to add an unidirectional dataset/query to sqldb. Thus one that isn't inherited from TDataset. This to improve performance, for for example cgi-like programs, in which iterating back and forth through a database isn't necessary. It should inherit from TDatset but not from TBufDataset IMHO to allow to use the existing DB components in Lazarus and MSEgui (persistent fields, data display widgets, field-parameter link, calculated fields...). But while working on this, I discovered that very much code from TSQLQuery could be exactly copied to this new class. Now I'm thinking about using an interface, to avoid double code. But I don't know what effect that has on run-time performance. I mean, the idea was to make if faster ... A very good idea! It can then be implemented by a common worker class. TSQLConnection and TSQLTransaction should be independent of TSQLQuery and TSQLQuery should get its own unit. I use not reference counted (corba style) interfaces very often in MSEide+MSEgui and I am happy with them. I would even be more happy without Mantis 6036 and 6690... Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
