Nope, just C++. I realize that references just a cleaner way of passing addresses than a pointer. I guess I'm just more comfortable managing the memory myself, and pointers usually force you to explicitly allocate either on the stack (pointer to a locally declared variable, the way most Win32 calls advise doing it) or on the heap (new variable in memory). As with your string examples, the compiler will sometimes help you out --but this is generally rarer than the automation seen with references.
Apparently FB programmers like their references. Far be it from me to persuade you otherwise. Like I said in my previous email, although this seems error-prone to me, I've already moved on to the "it's a valid style, just not my style" mindset. So.... no need to start calling each other Java programmers. (Kidding!) -->Seth On Tue, Sep 14, 2010 at 6:09 PM, Mike <[email protected]> wrote: > ....? Have you been programming Java recently? Is that what's going on? > > We've established that passing BYREF is equivalent to passing pointer, and > that if there is no variable to point to FB makes one up. > > Global variables work exactly the same as they always have. BYREF arguments > are totally unrelated to them. Therefore, copying a variable (or a constant, > or dereferencing a pointer to a made up variable) still works like you would > expect. There's no magic addressing or referencing going on. > -- > Mike Caron > > -----Original Message----- > From: Seth Hetu <[email protected]> > Sender: [email protected] > Date: Tue, 14 Sep 2010 17:59:22 > To: <[email protected]> > Reply-To: [email protected] > Subject: Re: [Ohrrpgce] BYREF > >> Or, looking at it from a different angle, why are you NOT surprised that you >> can do this in C? >> >> myfunction("Literal string: omg no variable!"); > > Hmm... a good concise example. Thanks, Mike. :) > > > >>> I'm just curious how FB manages this without corrupting memory. It >>> seems like such a weird design choice. >> >> Consider this. In QB, everything was BYREF by default. So, this had to be >> legal: >> >> sub mysub(myparam as integer) >> REM whatever >> end sub >> >> mysub 1 >> >> If it weren't legal, you'd get an error on a seemingly standard BASIC >> program. > > I can appreciate that "that's the way it's always been", and I'm sure > that it's much easier to use once you're used to it. > > But it still makes me feel uneasy. What if you save that variable into > some global variable, then exit the function? The copy on the stack no > longer exists, so the global var is now pointing to random stack data. > (I realize that copying the VALUE into the global var fixes this in > the simple case.) If I see "BYREF", I'd like to think that data exists > somewhere non-transient. > > That last paragraph is really just my own feelings on design; I'm > otherwise convinced that BYREF on constant data is reasonable. :) > > -->Seth > _______________________________________________ > Ohrrpgce mailing list > [email protected] > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > _______________________________________________ > Ohrrpgce mailing list > [email protected] > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
