This is for a C program.

I have a function that takes pointers as an argument(lets call the arguement 'a'). I want to keep data their they point to as read-only, so I made them const. However, there is a certain condition which can happen that demands the data to be changed before being processed by the rest of the function, or else the rest of the function won't work properly. So, what I want to do is copy the data we get from the caller to a lcal variable, change it, then have that data instead be processed by the rest of the function.

void myfunc(const foo* a){
	if( itllKillMe(a) )
		/*we have a problem...*/;
	anotherFunc(a);/*...here, unless we change it*/
	superFunc(a);/*and here*/
	goFunc(a);/*and here*/
	morefunc(a);/*...(obvious)*/
}
/*my real code is alot more complex of course*/

Simple enough, but I'm in decision on how to actually have the new data be processed instead of the older one. I want to do this:

	...
	foo tmp;
	if( itllKillMe(a) ){
		tmp=*a;
		makeItNicer(&tmp);/*this changes it to make it good*/
		/*changing the const a, this is one way to do it*/
		foo** changer;
		changer=(foo**)&a;
		*changer=&tmp;
		/*now on, when a is used, it is really tmp*/
	}

But its pretty obvious what would be seen as the problem here. You might ask as well, "If you intend to change it, why make it constant in the first place?". Well, the real reason for const-ing it is that the data at 'a' isn't changed, not really what it points to should be changed, IOW, '*a' shouldn't be changed, but 'a' can. (this way, it can be safe in not altering the dereferenced data whether its the caller's orignal or my tmp)

I though of this too...

	...
	foo *b, tmp;
	if( itllKillMe(a) ){
		tmp=*a;
		makeItNicer(&tmp);
		b=&tmp
	}
	else
		b=a;
	/*now we use 'b' for the rest of the func instead of using 'a'*/
	anotherFunc(b);
	...

But I forgot the mention that this condition (itllKillMe(a)) isn't common, so for the most of the time, we just assign b to a, which is a little bit of a waste...although that could pass as okay, still, it reassigns 'a' to a non const variable, loosing the very purpose I const'd it in the first place.

so, is it okay to bend the rules just this time?

{2}rIng

P.S. thanx for reading, its pretty long, and thanx alot(although I know the majority won't...)

It is very difficult to answer your question without having access to the real code.

I'd say that your idea of copying into a temporary variable and using this (when you need to change the data) is fine. You shouldn'y worry about inefficiency, until you have actually experienced poor performance.

This message was edited by Gregry2 at 2007-1-29 3:12:26

---

: It is very difficult to answer your question without having access to the real code.
:
: I'd say that your idea of copying into a temporary variable and using this (when you need to change the data) is fine. You shouldn'y worry about inefficiency, until you have actually experienced poor performance.
:
:
:

Erg...sorry, I was too vague. Posting the real code would be too hard for me, since I'd have too much explaining to do. This mirrors my code enough. This was what my real question was about...

	/*changing the const a, this is one way to do it*/
		foo** changer;
		changer=(foo**)&a;
		*changer=&tmp;

'a' is the argument/parameter to the function. It is defined as

const foo* a

tmp is the temporary variable containing the changed data.

Now, to make the rest of the function use the my temporary variable when I use it, I changed the value of 'a' to the address of 'tmp'(the blue line), so that when this is executed...

	anotherFunc(a);
	superFunc(a);
	goFunc(a);
	morefunc(a);

...the temporary variable is used instead of the user's. Also, if I need not change the inputted data, the original data is used.

This is bad(I think), for it considered bad practice to change a const variable's value. So this is what my question is, whether I can still do this, though it is considered bad.

I gave my reason for choosing to still code it this way despite that: I wanted to keep it const to make sure I dont alter the data that the pointer points to.

Its exactly like this in my code. The const argument, the tmp, and changing the const variable.

I hope this makes more sense...I hope. If not...may be I'll just go ahead and change the const's value.
{2}rIng

: Erg...sorry, I was too vague. Posting the real code would be too hard for me, since I'd have too much explaining to do. This mirrors my code enough. This was what my real question was about...
:
:

: 	/*changing the const a, this is one way to do it*/
: 		foo** changer;
: 		changer=(foo**)&a;
: 		*changer=&tmp;
: 

:
: 'a' is the argument/parameter to the function. It is defined as
:
: const foo* a
:
: tmp is the temporary variable containing the changed data.
:
: Now, to make the rest of the function use the my temporary variable when I use it, I changed the value of 'a' to the address of 'tmp'(the blue line), so that when this is executed...
:

: 	anotherFunc(a);
: 	superFunc(a);
: 	goFunc(a);
: 	morefunc(a);
: 

: ...the temporary variable is used instead of the user's. Also, if I need not change the inputted data, the original data is used.
:
: This is bad(I think), for it considered bad practice to change a const variable's value. So this is what my question is, whether I can still do this, though it is considered bad.
:
: I gave my reason for choosing to still code it this way despite that: I wanted to keep it const to make sure I dont alter the data that the pointer points to.
:
: Its exactly like this in my code. The const argument, the tmp, and changing the const variable.
:
: I hope this makes more sense...I hope. If not...may be I'll just go ahead and change the const's value.
: {2}rIng
:

I don't quite understand. How exactly do you intend to change the constant variable? Shouldn't it yield an error. I don't think the compiler will allow you to change the value of the constant variable unless of course you remove the const property of the variable.
As for the problem, i just thought you might want to try creating a constant pointer, although I have no idea if that will work in C!!
Just a thought here. Haven't checked it out.

:
: : Erg...sorry, I was too vague. Posting the real code would be too hard for me, since I'd have too much explaining to do. This mirrors my code enough. This was what my real question was about...
: :
: :

: : 	/*changing the const a, this is one way to do it*/
: : 		foo** changer;
: : 		changer=(foo**)&a;
: : 		*changer=&tmp;
: : 

: :
: : 'a' is the argument/parameter to the function. It is defined as
: :
: : const foo* a
: :
: : tmp is the temporary variable containing the changed data.
: :
: : Now, to make the rest of the function use the my temporary variable when I use it, I changed the value of 'a' to the address of 'tmp'(the blue line), so that when this is executed...
: :

: : 	anotherFunc(a);
: : 	superFunc(a);
: : 	goFunc(a);
: : 	morefunc(a);
: : 

: : ...the temporary variable is used instead of the user's. Also, if I need not change the inputted data, the original data is used.
: :
: : This is bad(I think), for it considered bad practice to change a const variable's value. So this is what my question is, whether I can still do this, though it is considered bad.
: :
: : I gave my reason for choosing to still code it this way despite that: I wanted to keep it const to make sure I dont alter the data that the pointer points to.
: :
: : Its exactly like this in my code. The const argument, the tmp, and changing the const variable.
: :
: : I hope this makes more sense...I hope. If not...may be I'll just go ahead and change the const's value.
: : {2}rIng
: :
:
: I don't quite understand. How exactly do you intend to change the constant variable? Shouldn't it yield an error. I don't think the compiler will allow you to change the value of the constant variable unless of course you remove the const property of the variable.
: As for the problem, i just thought you might want to try creating a constant pointer, although I have no idea if that will work in C!!
: Just a thought here. Haven't checked it out.
:


C is flexible/unsafe and will allow things that C++ wouldn't. Even though this is concidered as bad programming, this will work perfectly fine in C:

#include <stdio.h>

int main()
{
  const int x=0;
  int* non_const_ptr = (void*)&x;
  *non_const_ptr = 5;
  printf("%d\n", x);
  return 0;
}

It gave the result 5 on both gcc and Borland. However, whether the code works or not is system-specific. On a RAM based system like a PC, it will likely work without problems.

: :
: : : Erg...sorry, I was too vague. Posting the real code would be too hard for me, since I'd have too much explaining to do. This mirrors my code enough. This was what my real question was about...
: : :
: : :

: : : 	/*changing the const a, this is one way to do it*/
: : : 		foo** changer;
: : : 		changer=(foo**)&a;
: : : 		*changer=&tmp;
: : : 

: : :
: : : 'a' is the argument/parameter to the function. It is defined as
: : :
: : : const foo* a
: : :
: : : tmp is the temporary variable containing the changed data.
: : :
: : : Now, to make the rest of the function use the my temporary variable when I use it, I changed the value of 'a' to the address of 'tmp'(the blue line), so that when this is executed...
: : :

: : : 	anotherFunc(a);
: : : 	superFunc(a);
: : : 	goFunc(a);
: : : 	morefunc(a);
: : : 

: : : ...the temporary variable is used instead of the user's. Also, if I need not change the inputted data, the original data is used.
: : :
: : : This is bad(I think), for it considered bad practice to change a const variable's value. So this is what my question is, whether I can still do this, though it is considered bad.
: : :
: : : I gave my reason for choosing to still code it this way despite that: I wanted to keep it const to make sure I dont alter the data that the pointer points to.
: : :
: : : Its exactly like this in my code. The const argument, the tmp, and changing the const variable.
: : :
: : : I hope this makes more sense...I hope. If not...may be I'll just go ahead and change the const's value.
: : : {2}rIng
: : :
: :
: : I don't quite understand. How exactly do you intend to change the constant variable? Shouldn't it yield an error. I don't think the compiler will allow you to change the value of the constant variable unless of course you remove the const property of the variable.
: : As for the problem, i just thought you might want to try creating a constant pointer, although I have no idea if that will work in C!!
: : Just a thought here. Haven't checked it out.
: :
:
:
: C is flexible/unsafe and will allow things that C++ wouldn't. Even though this is concidered as bad programming, this will work perfectly fine in C:
:
:

: #include <stdio.h>
: 
: int main()
: {
:   const int x=0;
:   int* non_const_ptr = (void*)&x;
:   *non_const_ptr = 5;
:   printf("%d\n", x);
:   return 0;
: }
: 

:
: It gave the result 5 on both gcc and Borland. However, whether the code works or not is system-specific. On a RAM based system like a PC, it will likely work without problems.
:

...What kind of systems wouldn't it work on?...systems that aren't RAM based, like they use some other form of saving memory or something in which we can't just pop things onto an address (like virtual memory in which its not allowed...)

{2}rIng

: : :
: : : : Erg...sorry, I was too vague. Posting the real code would be too hard for me, since I'd have too much explaining to do. This mirrors my code enough. This was what my real question was about...
: : : :
: : : :

: : : : 	/*changing the const a, this is one way to do it*/
: : : : 		foo** changer;
: : : : 		changer=(foo**)&a;
: : : : 		*changer=&tmp;
: : : : 

: : : :
: : : : 'a' is the argument/parameter to the function. It is defined as
: : : :
: : : : const foo* a
: : : :
: : : : tmp is the temporary variable containing the changed data.
: : : :
: : : : Now, to make the rest of the function use the my temporary variable when I use it, I changed the value of 'a' to the address of 'tmp'(the blue line), so that when this is executed...
: : : :

: : : : 	anotherFunc(a);
: : : : 	superFunc(a);
: : : : 	goFunc(a);
: : : : 	morefunc(a);
: : : : 

: : : : ...the temporary variable is used instead of the user's. Also, if I need not change the inputted data, the original data is used.
: : : :
: : : : This is bad(I think), for it considered bad practice to change a const variable's value. So this is what my question is, whether I can still do this, though it is considered bad.
: : : :
: : : : I gave my reason for choosing to still code it this way despite that: I wanted to keep it const to make sure I dont alter the data that the pointer points to.
: : : :
: : : : Its exactly like this in my code. The const argument, the tmp, and changing the const variable.
: : : :
: : : : I hope this makes more sense...I hope. If not...may be I'll just go ahead and change the const's value.
: : : : {2}rIng
: : : :
: : :
: : : I don't quite understand. How exactly do you intend to change the constant variable? Shouldn't it yield an error. I don't think the compiler will allow you to change the value of the constant variable unless of course you remove the const property of the variable.
: : : As for the problem, i just thought you might want to try creating a constant pointer, although I have no idea if that will work in C!!
: : : Just a thought here. Haven't checked it out.
: : :
: :
: :
: : C is flexible/unsafe and will allow things that C++ wouldn't. Even though this is concidered as bad programming, this will work perfectly fine in C:
: :
: :

: : #include <stdio.h>
: : 
: : int main()
: : {
: :   const int x=0;
: :   int* non_const_ptr = (void*)&x;
: :   *non_const_ptr = 5;
: :   printf("%d\n", x);
: :   return 0;
: : }
: : 

: :
: : It gave the result 5 on both gcc and Borland. However, whether the code works or not is system-specific. On a RAM based system like a PC, it will likely work without problems.
: :
:
: ...What kind of systems wouldn't it work on?...systems that aren't RAM based, like they use some other form of saving memory or something in which we can't just pop things onto an address (like virtual memory in which its not allowed...)
:
: {2}rIng
:


I'm actually surprised that it works on Windows, since it is supposed to do all kind of fancy virtual memory handling. But then, I don't know very much of what's going on behind the scenes in Windows.

It wouldn't work on ROM-based systems, since constant variables will be placed in ROM and not RAM. Examples are microcontrollers, DSPs, systems with external memory etc.

: : : :
: : : : : Erg...sorry, I was too vague. Posting the real code would be too hard for me, since I'd have too much explaining to do. This mirrors my code enough. This was what my real question was about...
: : : : :
: : : : :

: : : : : 	/*changing the const a, this is one way to do it*/
: : : : : 		foo** changer;
: : : : : 		changer=(foo**)&a;
: : : : : 		*changer=&tmp;
: : : : : 

: : : : :
: : : : : 'a' is the argument/parameter to the function. It is defined as
: : : : :
: : : : : const foo* a
: : : : :
: : : : : tmp is the temporary variable containing the changed data.
: : : : :
: : : : : Now, to make the rest of the function use the my temporary variable when I use it, I changed the value of 'a' to the address of 'tmp'(the blue line), so that when this is executed...
: : : : :

: : : : : 	anotherFunc(a);
: : : : : 	superFunc(a);
: : : : : 	goFunc(a);
: : : : : 	morefunc(a);
: : : : : 

: : : : : ...the temporary variable is used instead of the user's. Also, if I need not change the inputted data, the original data is used.
: : : : :
: : : : : This is bad(I think), for it considered bad practice to change a const variable's value. So this is what my question is, whether I can still do this, though it is considered bad.
: : : : :
: : : : : I gave my reason for choosing to still code it this way despite that: I wanted to keep it const to make sure I dont alter the data that the pointer points to.
: : : : :
: : : : : Its exactly like this in my code. The const argument, the tmp, and changing the const variable.
: : : : :
: : : : : I hope this makes more sense...I hope. If not...may be I'll just go ahead and change the const's value.
: : : : : {2}rIng
: : : : :
: : : :
: : : : I don't quite understand. How exactly do you intend to change the constant variable? Shouldn't it yield an error. I don't think the compiler will allow you to change the value of the constant variable unless of course you remove the const property of the variable.
: : : : As for the problem, i just thought you might want to try creating a constant pointer, although I have no idea if that will work in C!!
: : : : Just a thought here. Haven't checked it out.
: : : :
: : :
: : :
: : : C is flexible/unsafe and will allow things that C++ wouldn't. Even though this is concidered as bad programming, this will work perfectly fine in C:
: : :
: : :

: : : #include <stdio.h>
: : : 
: : : int main()
: : : {
: : :   const int x=0;
: : :   int* non_const_ptr = (void*)&x;
: : :   *non_const_ptr = 5;
: : :   printf("%d\n", x);
: : :   return 0;
: : : }
: : : 

: : :
: : : It gave the result 5 on both gcc and Borland. However, whether the code works or not is system-specific. On a RAM based system like a PC, it will likely work without problems.
: : :
: :
: : ...What kind of systems wouldn't it work on?...systems that aren't RAM based, like they use some other form of saving memory or something in which we can't just pop things onto an address (like virtual memory in which its not allowed...)
: :
: : {2}rIng
: :
:
:
: I'm actually surprised that it works on Windows, since it is supposed to do all kind of fancy virtual memory handling. But then, I don't know very much of what's going on behind the scenes in Windows.
:
: It wouldn't work on ROM-based systems, since constant variables will be placed in ROM and not RAM. Examples are microcontrollers, DSPs, systems with external memory etc.
:

Wait a sec, I forgot to mention something. The const pointer in my example(and in my code) really is a function argument/parameter...so it really ins't a const(unless the value passed is a const)...so it can't be in the ROM...

int theFunc(const foo* a);

since its a argument/parameter, it has to be variable...I guess on this one I can escape that...or do C compilers for these ROM-based systems treat the const keyword differently( ie. its only for real consts, and shouldn't be used as argument/parameter specifiers)

Or do I understand wrong...

{2}rIng

P.S. which should i use: argument or parameter (in these posts)? I more comfortable with the former...but for others it doesn't
seem the same...

: : : : :
: : : : : : Erg...sorry, I was too vague. Posting the real code would be too hard for me, since I'd have too much explaining to do. This mirrors my code enough. This was what my real question was about...
: : : : : :
: : : : : :

: : : : : : 	/*changing the const a, this is one way to do it*/
: : : : : : 		foo** changer;
: : : : : : 		changer=(foo**)&a;
: : : : : : 		*changer=&tmp;
: : : : : : 

: : : : : :
: : : : : : 'a' is the argument/parameter to the function. It is defined as
: : : : : :
: : : : : : const foo* a
: : : : : :
: : : : : : tmp is the temporary variable containing the changed data.
: : : : : :
: : : : : : Now, to make the rest of the function use the my temporary variable when I use it, I changed the value of 'a' to the address of 'tmp'(the blue line), so that when this is executed...
: : : : : :

: : : : : : 	anotherFunc(a);
: : : : : : 	superFunc(a);
: : : : : : 	goFunc(a);
: : : : : : 	morefunc(a);
: : : : : : 

: : : : : : ...the temporary variable is used instead of the user's. Also, if I need not change the inputted data, the original data is used.
: : : : : :
: : : : : : This is bad(I think), for it considered bad practice to change a const variable's value. So this is what my question is, whether I can still do this, though it is considered bad.
: : : : : :
: : : : : : I gave my reason for choosing to still code it this way despite that: I wanted to keep it const to make sure I dont alter the data that the pointer points to.
: : : : : :
: : : : : : Its exactly like this in my code. The const argument, the tmp, and changing the const variable.
: : : : : :
: : : : : : I hope this makes more sense...I hope. If not...may be I'll just go ahead and change the const's value.
: : : : : : {2}rIng
: : : : : :
: : : : :
: : : : : I don't quite understand. How exactly do you intend to change the constant variable? Shouldn't it yield an error. I don't think the compiler will allow you to change the value of the constant variable unless of course you remove the const property of the variable.
: : : : : As for the problem, i just thought you might want to try creating a constant pointer, although I have no idea if that will work in C!!
: : : : : Just a thought here. Haven't checked it out.
: : : : :
: : : :
: : : :
: : : : C is flexible/unsafe and will allow things that C++ wouldn't. Even though this is concidered as bad programming, this will work perfectly fine in C:
: : : :
: : : :

: : : : #include <stdio.h>
: : : : 
: : : : int main()
: : : : {
: : : :   const int x=0;
: : : :   int* non_const_ptr = (void*)&x;
: : : :   *non_const_ptr = 5;
: : : :   printf("%d\n", x);
: : : :   return 0;
: : : : }
: : : : 

: : : :
: : : : It gave the result 5 on both gcc and Borland. However, whether the code works or not is system-specific. On a RAM based system like a PC, it will likely work without problems.
: : : :
: : :
: : : ...What kind of systems wouldn't it work on?...systems that aren't RAM based, like they use some other form of saving memory or something in which we can't just pop things onto an address (like virtual memory in which its not allowed...)
: : :
: : : {2}rIng
: : :
: :
: :
: : I'm actually surprised that it works on Windows, since it is supposed to do all kind of fancy virtual memory handling. But then, I don't know very much of what's going on behind the scenes in Windows.
: :
: : It wouldn't work on ROM-based systems, since constant variables will be placed in ROM and not RAM. Examples are microcontrollers, DSPs, systems with external memory etc.
: :
:
: Wait a sec, I forgot to mention something. The const pointer in my example(and in my code) really is a function argument/parameter...so it really ins't a const(unless the value passed is a const)...so it can't be in the ROM...
:
: int theFunc(const foo* a);
:
: since its a argument/parameter, it has to be variable...I guess on this one I can escape that...or do C compilers for these ROM-based systems treat the const keyword differently( ie. its only for real consts, and shouldn't be used as argument/parameter specifiers)
:
: Or do I understand wrong...
:
: {2}rIng
:
: P.S. which should i use: argument or parameter (in these posts)? I more comfortable with the former...but for others it doesn't
: seem the same...
:


const foo* a;

It means that you can't change the contents of 'a'. 'a' can point at data allocated in ROM or RAM, you haven't got a clue. I just wanted to point out a weakness in the language, I didn't say that you should use it.

If you write const before your pointer, the programmer who calls the routine gets comfortable, since he knows that the function won't change his precious data.

There is never any case where you want to change the contents or a const variable. If someone finds such a case, then it is because their program design is bad. It is fine to typecast from non-constant to constant, but never the other way around. Also, should you try it in C++, the compiler will give you a box on the ears.

Argument and parameter is the same thing. Parameter is a more commonly used term. None of them is more correct than the other.

I stand by my reply: Copying to a temporary variable and using this variable (by pointing to it) is perfectly fine.

The reason why I wanted to see your code was that I refuse to believe that you couldn't design your way out of this.

: I stand by my reply: Copying to a temporary variable and using this variable (by pointing to it) is perfectly fine.
:
: The reason why I wanted to see your code was that I refuse to believe that you couldn't design your way out of this.
:

May be I could..idk, but I guess thats up to me, since I can't really show you guys the code. The sucky thing is because of things like this, if I choose to try to port this to C++, it won't be so easy...

May be I'll blab a little. Its for this bigint thing (again). The "function" I keep talking about are the operators (ie. add, subtract....not C++ operators though). sometimes the operands need to be tweaked...and I didn't feel it was good to modify the operands to the function, even if I change it back later(what I mean by "tweak" is to negate, perform two's complement, which is easily reversible). Thread safety isn't a reason for this though, for the data of each bigint is a unsigned char*, and each byte is accessed byte by byte, so its only thread safe if the user locks them, and doing this whole copy thing doesn't help making it more thread safe.

But the problem is on error. If we encounter an error, almost all of which require a return, i need to reverse things each time, which, without the help of try{}catch(){} things...isn't so easy.

Oh well, in exchange for C's (thought of) lack of pretty useful constructs is its unsafe flexibility(as what Lundin said), so I guess using that is the best way..at least the best I can see now.

{2}rIng

I think im bi-polar or something. forget all the crap i wrote, i'll just redesign.

{2}rIng

: I think im bi-polar or something. forget all the crap i wrote, i'll just redesign.
:
: {2}rIng
:

there might be another way
you can have another pointer which will store same address as your
*foo pointer
your data can be modified through this new pointer.

: : I stand by my reply: Copying to a temporary variable and using this variable (by pointing to it) is perfectly fine.
: :
: : The reason why I wanted to see your code was that I refuse to believe that you couldn't design your way out of this.
: :
:
: May be I could..idk, but I guess thats up to me, since I can't really show you guys the code. The sucky thing is because of things like this, if I choose to try to port this to C++, it won't be so easy...
:
: May be I'll blab a little. Its for this bigint thing (again). The "function" I keep talking about are the operators (ie. add, subtract....not C++ operators though). sometimes the operands need to be tweaked...and I didn't feel it was good to modify the operands to the function, even if I change it back later(what I mean by "tweak" is to negate, perform two's complement, which is easily reversible). Thread safety isn't a reason for this though, for the data of each bigint is a unsigned char*, and each byte is accessed byte by byte, so its only thread safe if the user locks them, and doing this whole copy thing doesn't help making it more thread safe.
:
: But the problem is on error. If we encounter an error, almost all of which require a return, i need to reverse things each time, which, without the help of try{}catch(){} things...isn't so easy.
:
: Oh well, in exchange for C's (thought of) lack of pretty useful constructs is its unsafe flexibility(as what Lundin said), so I guess using that is the best way..at least the best I can see now.
:
: {2}rIng
:
:

Why, exactly, can't you show us the code?

If you're in school, or some other non-commercial setting, it shouldn't be any problem -- you own the code.

Sincerely,
Jakykong (Jack Mudge)
jack_mudge@hotmail.com