Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
BUG: return a new object by reference fire a C5 crash
Message
 
À
13/04/2004 13:09:28
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00893984
Message ID:
00894509
Vues:
13
>Hello Nick, I read this a while ago. After reading this it made me wonder more why people preface memory variable with the "m.". To me it just seem to be a preference by a developer more then anything. What about you, do you preface your variable with "m."?
>
>Maybe I'm missing something, I'll read it again tonight.
>
>Thanks Nick

Hi Bob,

I use Hungarian notation, always make sure that I do not use the same variable name as the field name, and try to avoid using reserved words as field names.

I try not to clutter the code with m.

However, there are cases when not using m. may impact the performance. For example, (you can find it in wiki article) if you do this in a big loop:

lcTarget = lcSource

that will be slower than

lcTarget = m.lcSource

in case if there are some table(s) open and the table(s) have many fields. It appears that VFP is trying to check if your lcSource is in fact a field in the open table and spends extra time for that. Imagine that you scan huge 10,000,000 records table, and for every record you execute the above mentioned line lcTarget = lcSource in your SCAN code, and you have 200 fields in the table. For every scanned record VFP will check 200 fields just to make sure that lcSource is not a field.
Nick Neklioudov
Universal Thread Consultant
3 times Microsoft MVP - Visual FoxPro

"I have not failed. I've just found 10,000 ways that don't work." - Thomas Edison
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform