On 15 September 2010 14:25, Seth Hetu <[email protected]> wrote: > 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).
I wouldn't call local variables explicit allocation on the stack. alloca is explicit allocation on the stack. > 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 It's error prone, but not because of anything to do with the compiler implementation. Rather, defaulting to BYREF for everything is a really bad default. We are only human, and I can't think of any other language that passes integers by reference by default; so naturally we tend to write code that assumes integers are passed by value. Which is why I insist on littering our code with thousands of ugly BYVALs. > > > 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 > _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
