Re: Modifying through pointer-to-const

From: Russell Hanneken (rghanneken_at_pobox.com)
Date: 04/19/04 

Date: Mon, 19 Apr 2004 21:29:38 GMT

Dave wrote:
>
> In the code below, I am able to modify data through the pointer-to-const
> DynGapRec parameter. The last two lines show this.
> Is there any circumstance where this should be legal, or
> do I definitely have a compiler bug (VC++ 7.1)?
>
> void CInstrProcEngine::AggregateDynamicGapRecords(const CAccount*
> iAcct, const SingleInstr* pInstr,
> const int* evPoints,
> const CGapInt* pGap,
> const DynGap* DynGapRec,
> CDate forecastDate,
> int RateType,
> int startPd,
> int endPd)
> {
[. . .]
> DynGaRec->MvPeriod[index] = currentEvPt; // ILLEGAL!!!
> DynGapRec->GapInteval[index] = pGap->i_GapEndMt[gapRecCnt]; //
> ILLEGAL!!!

Dave,

This would be legal if MvPeriod and GapInteval are pointers to non-const
data. Assuming this is the case, you're changing the values of data being
pointed to, not the values of the pointers per se. Since the pointers are
members of DynGap, and the data being pointed to are not, the assignments
don't affect the state of DynGapRec (as far as the compiler is concerned,
anyway).

If this is not what you want, you might consider hiding MvPeriod and
GapInterval, and providing non-const member functions to alter the data they
point to. 

--
Russell Hanneken
rghanneken@pobox.com
Remove the 'g' from my address to send me mail.

Relevant Pages

  • Re: Modifying through pointer-to-const
    ... > Dave wrote: ... not the values of the pointers per se. ... > don't affect the state of DynGapRec (as far as the compiler is concerned, ... then the compiler will balk. ...
    (comp.lang.cpp)
  • Re: delay_check and check_subject problem
    ... Dave wrote: ... > Any pointers as to where i should be looking and what for would be most ... I am not clued up on programming so dont really want to go ... is too lazy to trim his article, and it's wasting the time of all readers. ...
    (comp.mail.sendmail)
  • Re: Storing a tree in a std::list<>
    ... Dave wrote: ... > tree where a vertex contain pointers to its parent / children. ... that the standard actually requires it. ... adding/removing elements do not ...
    (comp.lang.cpp)
  • Re: Is this good style of C++?
    ... > Dave O'Hearn wrote: ... >> does not solve the object ownership problem. ... This eliminates dangling pointers, ... a reference counted smart pointer, ...
    (comp.lang.cpp)