At 07:31 PM 12/10/2004, Tonko Juricic wrote: >--- "William A. Rowe, Jr." <[EMAIL PROTECTED]> >wrote: > >> You realize we missed the turn? >... >> So one is left with the question; what is c++ 2003 >> trying to accomplish, anyways? > >Huh? I think I am as confused as is C++ 2003 compiler, >trying to explain this to myself! > >This is partly due to (I think) confusing terminology >or (my) confusing use of terminology. > >In particular, terms 'unmanaged' and 'managed', when >applied to data, can mean data residing in managed or >unmanaged memory, which then implies marshalling on >transitions between managed and unmanaged code. > >It can also mean that data type is unmanaged, in the >sense of data type not corresponding directly to any >of standard CLR types, which again implies marshalling >in the sense of tranformation between data types. > >All in all, I agree with you that: > >request_rec __nogc *rr; > >clearly does not reside in managed memory so native >call: > >apr_table_setn(rr->headers_out, >response_headers_c[index], poolval); > >is a transition from unmanaged memory to unmanaged >memory and no marshalling of any sort is needed. > >I guess that compiler is not able to determine that >when it encounters apr_table_setn() prototype. > >It may be just a bug, since previous versions caused >no such issues. > >I'm just guessing... probably again confusing myself >and anybody reading this.
I understood you perfectly :) Can you pinpoint anywhere that we actually reference the unmanaged data from managed code (forcing some marshalling), or have we successfully kept all of the unmanaged data references within the context of unmanaged code? Yes, I'm familiar with the transition issues, and tried to keep clear boundaries between managed and unmanaged code and data to avoid excessive marshalling. Bill
