473,685 Members | 2,631 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Dilemma of const-ifying a function parameter

Correct me if I am wrong, declaring formal parameters of functions as
const, if they should not be/is not changed, has 2 benefits;
1. It tells the program that calls this function that the parameter
will not be changed - so don't worry.
2. It tells the implementor and the maintainer of this function that
the parameter should not be changed inside the function. And it is for
this reason that some people advocate that it is a good idea to
const-ify even a non-pointer parameter:
void my_func(const int i) { ... }
because if the original programmer or a subsequent maintainer
accidentally change the value of the parameter, the compiler can catch
it.
A third benefit may be that the compiler can optimize the program if it
knows for sure that the parameter is not changed inside the function. I
am not sure about this though.
Now, I would like to benefit from the const-ification of the function
parameter. Let's say I have this code:

typedef struct s_fifoItem t_fifoItem;
struct s_fifoItem {
t_fifoItem *next;
t_fifoItem *prev;
void *elem;
};
typedef t_fifoItem t_fifoQueue;

void enqueue(t_fifoQ ueue *q, void *elem)
{
t_fifoItem *i, *last;

i = malloc(sizeof(t _fifoItem));
i->elem = elem;
last = q->prev;
last->next = i;
i->next = q;
q->prev = i;
}

elem appears to be a good candidate for const-ification. Intutitively
the program calling enqueue() normally does not expect that the item to
be enqueued is to be changed. And the implementor of enqueue() would
not want to change elem either; and actually elem is not changed in the
above implementation. But if I const-ify elem, gcc would complain (in a
warning) that the assignment
i->elem = elem;
would discard the const qualifier because the type of "i->elem" is
"void *", not "const void *". One solution is to cast away the
const-ness of elem in that assignment:
i->elem = (void *)elem;
Another solution is to change the declaration of elem in struct
s_fifoItem to be:
const void *elem;
The latter solution is not practical because there are other places
that will change *elem.
However, the former solution of casting away the const-ness is not very
appealing. It is kind of cheating.
So, how do people resolve this? And to a deeper level, gcc seems to be
caught bewteen 2 conflicting goals: ensuring type correctness (a double
cannot be assigned to an int, a const void * cannot be assigned to a
void *, etc) and ensuring the unmodifiability of a variable. From the
point of view of language design, what are the issues involved and how
do other programming languages deal with it?

P.S. I know nothing about C++. But in its queue STL, there is a
function
void push(const T &val)
The const here means that the element is a const parameter. This
confirms my belief that it is good programming practice to const-ify
the element to be enqueued. But I wonder how this const-ification is
implemented inside push(). It is possible that the parameter is made
constant in the prototype from the client's perspective (to reap the
first benefit I mentioned above) but the parameter is cast (void *)
inside the function (so the second benefit is not reaped, and the STL
coders (i.e. ones who code the STL) need to be careful).

Aug 27 '06 #1
16 3156
hz*****@hotmail .com schrieb:
Correct me if I am wrong, declaring formal parameters of functions as
const, if they should not be/is not changed, has 2 benefits;
1. It tells the program that calls this function that the parameter
will not be changed - so don't worry.
2. It tells the implementor and the maintainer of this function that
the parameter should not be changed inside the function. And it is for
this reason that some people advocate that it is a good idea to
const-ify even a non-pointer parameter:
void my_func(const int i) { ... }
Here you are going wrong.
There is a conceptual difference between
void my_pfunc (const int *pI);
and
void my_func (const int i);
For the former, whatever pI points to must not be modified
but pI may be modified. The equivalent of the latter is
void my_pfunc2 (int * const pI);
which does not allow to modify the _value_ of the parameter.
As the change of the parameter value has no bearing whatsoever
on the argument being passed, there is indeed only the local
"benefit" of not being able to change the parameter.
This IMO is more a question of style than anything else.
If you want to do that consequently and have benefit 1 and 2
on top of it, you arrive at
const Type
<some number of "* const" and plain "*" in between>
ParameterName
i.e. you will have
const int * const pI
for the above and
const int ** const ppI
or
const int * const * const ppI
to be safe on either the level of the values at the bottom
and level of the pointer value or on all levels.

because if the original programmer or a subsequent maintainer
accidentally change the value of the parameter, the compiler can catch
it.
A third benefit may be that the compiler can optimize the program if it
knows for sure that the parameter is not changed inside the function. I
am not sure about this though.
Now, I would like to benefit from the const-ification of the function
parameter. Let's say I have this code:

typedef struct s_fifoItem t_fifoItem;
struct s_fifoItem {
t_fifoItem *next;
t_fifoItem *prev;
void *elem;
[*]
};
typedef t_fifoItem t_fifoQueue;

void enqueue(t_fifoQ ueue *q, void *elem)
{
t_fifoItem *i, *last;

i = malloc(sizeof(t _fifoItem));
You forgot to check the return value of malloc().
Undefined behaviour from here.
Note that
i = malloc(sizeof *i);
is safer in that you have not to adapt the line if the
type of i changes (e.g. copy&paste+adap tion).
i->elem = elem;
Make[*]
const void *elem
if you want to never ever modify *elem via i->elem
and never to be able to modify *(i->elem) when you get
the address from i->elem instead of another copy of the
address.
Then "const"ing *elem via "const void *elem" makes sense.
This is only the case if you want to store the address for
comparisons of either address or value pointed to.
last = q->prev;
last->next = i;
i->next = q;
q->prev = i;
}

elem appears to be a good candidate for const-ification. Intutitively
the program calling enqueue() normally does not expect that the item to
be enqueued is to be changed. And the implementor of enqueue() would
not want to change elem either; and actually elem is not changed in the
above implementation. But if I const-ify elem, gcc would complain (in a
warning) that the assignment
i->elem = elem;
would discard the const qualifier because the type of "i->elem" is
"void *", not "const void *". One solution is to cast away the
const-ness of elem in that assignment:
i->elem = (void *)elem;
Another solution is to change the declaration of elem in struct
s_fifoItem to be:
const void *elem;
The latter solution is not practical because there are other places
that will change *elem.
However, the former solution of casting away the const-ness is not very
appealing. It is kind of cheating.
There is a difference between "the pointer parameter will not be
used in the function to modify what the pointer points to" and
"the address passed via the pointer parameter and its copies made
during the function's lifetime are not used to modify what the
pointer points to". You essentially promise the latter when saying
"const void *elem".
Once again: const-ifying elem means "void * const elem" and that
the parameter will not change its value. If you want to be able
to say "the value elem points to is not changed but the value
i->elem points to may be changed" then you have also to pass the
size of *elem and create a copy of *elem:
i->elem = malloc(size);
if (i->elem == NULL) {
/* Your sensible action here */
}
memcpy(i->elem, elem, size);
So, how do people resolve this? And to a deeper level, gcc seems to be
caught bewteen 2 conflicting goals: ensuring type correctness (a double
cannot be assigned to an int, a const void * cannot be assigned to a
void *, etc) and ensuring the unmodifiability of a variable. From the
point of view of language design, what are the issues involved and how
do other programming languages deal with it?
gcc just does the thing the language is promising.

<OT>
P.S. I know nothing about C++. But in its queue STL, there is a
function
void push(const T &val)
The const here means that the element is a const parameter. This
confirms my belief that it is good programming practice to const-ify
the element to be enqueued. But I wonder how this const-ification is
implemented inside push(). It is possible that the parameter is made
constant in the prototype from the client's perspective (to reap the
first benefit I mentioned above) but the parameter is cast (void *)
inside the function (so the second benefit is not reaped, and the STL
coders (i.e. ones who code the STL) need to be careful).
Note that for C++ templates, the type of the passed val is known,
thus a local copy can be made, just as I suggested above.
If the queue stored a "const T *" or "const T&" copy of val, then
you have once again a pointer or reference to dVal=(whatever
dereferencing val gives you) that cannot be used to change dVal.
If you change whatever is stored in the queue, then you have no
changes whatsoever to dVal.

This is just the same as giving &dElem to enqueue() -- the
prototype of enqueue promises you that dElem will never ever
be changed by the address given to enqueue() or one of its
copies made during the run-time of enqueue(). At least if
enqueue() is honouring the promise of "const void * elem".
</OT>
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Aug 27 '06 #2

<hz*****@hotmai l.comwrote in message
>
elem appears to be a good candidate for const-ification. Intutitively
the program calling enqueue() normally does not expect that the item to
be enqueued is to be changed. And the implementor of enqueue() would
not want to change elem either; and actually elem is not changed in the
above implementation. But if I const-ify elem, gcc would complain (in a
warning) that the assignment
i->elem = elem;
would discard the const qualifier because the type of "i->elem" is
"void *", not "const void *". One solution is to cast away the
const-ness of elem in that assignment:
i->elem = (void *)elem;
Another solution is to change the declaration of elem in struct
s_fifoItem to be:
const void *elem;
The latter solution is not practical because there are other places
that will change *elem.
What you are describing is const poisoning. Very few variables, by
definition, are truly constant through the life of the program. However they
may be constant for a defined period of time.
const was added to C by a committee. Committees are good at taking certain
types of decisions, but language design isn't one of them. A good language
is more like a Renasissance masterpiece than a ladies' knitting circle tea
rota. It doesn't express the constness of data very well.
The question is, what to do about it? There is no good answer. If you reject
const algoether you risk making code uncallable by those folish enough to
use it, if you use it you get these types of problems.

--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.
Aug 27 '06 #3
hz*****@hotmail .com wrote:
Correct me if I am wrong, declaring formal parameters of functions as
const, if they should not be/is not changed, has 2 benefits;
1. It tells the program that calls this function that the parameter
will not be changed - so don't worry.
2. It tells the implementor and the maintainer of this function that
the parameter should not be changed inside the function. And it is for
this reason that some people advocate that it is a good idea to
const-ify even a non-pointer parameter:
void my_func(const int i) { ... }
because if the original programmer or a subsequent maintainer
accidentally change the value of the parameter, the compiler can catch
it.
FWIW, I don't ever see the point of doing this. If you want
that type of behavior, it's much more reasonable to do:
void my_func(int i) { const int i_copy = i; ...}. If the problem
is something like:
void my_func(len I)
{
for ( ; len 0 ; len--)
;
/* oops, future maintainer thinks len is still valid */
},

then making len const just forces you to add a loop
variable and the new code becomes the above
suggestion, with the const transposed. Usually, when
I see foo(const int arg) I take it as a clue that the
author is a newbie and it raises warning flags.
A third benefit may be that the compiler can optimize the program if it
knows for sure that the parameter is not changed inside the function. I
am not sure about this though.
The restrict keyword is probably more beneficial for optimization,
but I believe const has an effect as well. (I have no empirical
evidence to support this claim.)

<snip>
One solution is to cast away the
const-ness of elem in that assignment:
i->elem = (void *)elem;
Another solution is to change the declaration of elem in struct
s_fifoItem to be:
const void *elem;
The latter solution is not practical because there are other places
that will change *elem.
I would go with the former, but a slight modification
of the second solution is to provide an accessor function
which casts away the const from the structure. eg
void *ret;
ret = (void *)(i->elem)
This has essentially exactly the same problems you
describe, but it localizes the cast.
However, the former solution of casting away the const-ness is not very
appealing. It is kind of cheating.
So, how do people resolve this?
I've been wondering about this for some time, and I'm starting
to lean towards using const less often than I'd like. For example,
consider an implementation of strchr:
error_t my_strchr(const char *string, char target, const char
**location);
Where instead of returning the index, you put a pointer to the
first occurence of target in *location. If you don't constify
location, you'll need to cast its assignment in my_strchr. If you
do constify it, then the caller must always pass consts: ie to
replace 'a' with 'b', you'd like to do:

while (my_strchr( string, 'a', &location)) {
*location = 'b';
}

but instead you'll need to cast away the const of location. Again,
I think the solution here is to cast the assignment within my_strchr.
It's aesthically unappealing, but IMO it's the correct thing to do.

--
Bill Pursell

Aug 27 '06 #4
hz*****@hotmail .com writes:
A third benefit may be that the compiler can optimize the program if it
knows for sure that the parameter is not changed inside the function. I
am not sure about this though.
No.

#include <stdio.h>
void foo(const int *a, int *b) {
printf("*a = %d; *b = %d\n", *a, *b);
*b++;
printf("*a = %d; *b = %d\n", *a, *b);
}
int main(void) {
int c = 1;
foo(&c, &c);
return 0;
}
There is no way compiler can tell whether the thing pointed by a const
int* pointer will change or not. You'll had to use 'restrict'
keyword for that:

void foo(const int restrict *a, int restrict *b) { /* ... */

However, still it's up to programmer not compiler to guarantee that
a and b point to different things.
struct s_fifoItem {
t_fifoItem *next;
t_fifoItem *prev;
void *elem;
};
[...]
void enqueue(t_fifoQ ueue *q, void *elem) {
t_fifoItem *i, *last;
i = malloc(sizeof(t _fifoItem));
i->elem = elem;
[...]
}

elem appears to be a good candidate for const-ification.
You'll have to constify it in the structure also and it may or may not
break your code depending on what you do with the pointer.
One solution is to cast away the const-ness of elem in that
assignment:
Then, constifing the formal parameter would be pointless.
Another solution is to change the declaration of elem in struct
s_fifoItem to be:
const void *elem;
And that's what you have to do.
The latter solution is not practical because there are other places
that will change *elem.
So you cannot constify the parameter. The function doesn't change
what elem points to but it doesn't matter. It saves the pointer
somewhere for other functions to be able to modify it so indirectly
the function is modifying it.
However, the former solution of casting away the const-ness is not very
appealing. It is kind of cheating.
It's stupid and pointless. :)
So, how do people resolve this?
If any other function will modify what elem points to you cannot
constify the argument. Compare this to that code:

void inc(int *bar) { ++*bar; }
void foo(const int *const_bar) { inc((int *)const_bar); }

Your saying: OK, foo() doesn't modify *const_bar so we can constify it
but at the same time inc() modifies it so we need to cast it to
non-const pointer but in the end doesn't foo() end modifying
*const_bar?
P.S. I know nothing about C++. But in its queue STL, there is a
function
void push(const T &val)
The const here means that the element is a const parameter. This
confirms my belief that it is good programming practice to const-ify
the element to be enqueued.
I don't know STL but probably there is also a const T &pop() method
which returns *const* reference or val is being *copied* and then
pop() returns non-const reference to the copy. In your case, you want
a void push(const T *val) and T *pop() functions which is wrong.
It is possible that the parameter is made constant in the prototype
from the client's perspective (to reap the first benefit I mentioned
above) but the parameter is cast (void *)
No.

--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl >--<jid:mina86*jab ber.org>--ooO--(_)--Ooo--
Aug 27 '06 #5
hzmonte posted:
Correct me if I am wrong, declaring formal parameters of functions as
const, if they should not be/is not changed, has 2 benefits;

I use the exact same rules for defining function arguments as const, as I
use for defining any object as const.

1. It tells the program that calls this function that the parameter
will not be changed - so don't worry.
2. It tells the implementor and the maintainer of this function that
the parameter should not be changed inside the function. And it is for
this reason that some people advocate that it is a good idea to
const-ify even a non-pointer parameter:
void my_func(const int i) { ... }

Yes, I would define "i" as const if it weren't to be changed.

void enqueue(t_fifoQ ueue *q, void *elem)
{
t_fifoItem *i, *last;

i = malloc(sizeof(t _fifoItem));
i->elem = elem;
last = q->prev;
last->next = i;
i->next = q;
q->prev = i;
}

elem appears to be a good candidate for const-ification.

Indeed:

void *const elem;

Intutitively the program calling enqueue() normally does not expect that
the item to be enqueued is to be changed. And the implementor of
enqueue() would not want to change elem either; and actually elem is not
changed in the above implementation. But if I const-ify elem, gcc would
complain (in a warning) that the assignment
i->elem = elem;
would discard the const qualifier because the type of "i->elem" is
"void *", not "const void *". One solution is to cast away the
const-ness of elem in that assignment:
i->elem = (void *)elem;

No no no! Leave the function argument as a "pointer to const".

There's a difference between an actual object being const, e.g.:

int const i;
int *const p;

, and a pointer to const:

int const *p;

If you change the function parameter to "pointer to NON-const", then
there's the danger of the following:

char const buf[5] = {0};
Func(buf);

Because the address of the array will eventually be held in a "void*"
(which is a pointer to NON-const), there's the danger of it being altered
at some point.

So, how do people resolve this? And to a deeper level, gcc seems to be
caught bewteen 2 conflicting goals: ensuring type correctness (a double
cannot be assigned to an int, a const void * cannot be assigned to a
void *, etc) and ensuring the unmodifiability of a variable. From the
point of view of language design, what are the issues involved and how
do other programming languages deal with it?

First thing to tackle is this:

Should "s_fifoItem " contain a "void*", or a "void const*". If the
former, then this implies that the pointer will be used to alter the data
at that address. If the latter, this implies that the data won't be
altered. If you choose to leave it as "void*", then make your function take
a "void*".

P.S. I know nothing about C++. But in its queue STL, there is a
function
void push(const T &val)
The const here means that the element is a const parameter.

No it doesn't -- it means that val is a reference to a const T.

(A reference can't be const because it isn't an object -- the following
won't compile: int &const i)

--

Frederick Gotham
Aug 27 '06 #6
Here you are going wrong.
Where did I go wrong? I did make a mistake by saying constifying elem;
what I meant was constifying *elem. That is, the data pointed to by
the pointer is not changed.
Make[*]
const void *elem
if you want to never ever modify *elem via i->elem
and never to be able to modify *(i->elem) when you get
the address from i->elem instead of another copy of the
address.
Then "const"ing *elem via "const void *elem" makes sense.
I do want to modify *elem outside this (enqueue) function. That is why
I said I have a dilemma.
There is a difference between "the pointer parameter will not be
used in the function to modify what the pointer points to" and
"the address passed via the pointer parameter and its copies made
during the function's lifetime are not used to modify what the
pointer points to". You essentially promise the latter when saying
"const void *elem".
Yes, I want that (latter) promise.
Once again: const-ifying elem means "void * const elem" and that
Again, I should have said "const-ifying *elem".
the parameter will not change its value. If you want to be able
to say "the value elem points to is not changed but the value
i->elem points to may be changed" then you have also to pass the
size of *elem and create a copy of *elem:
i->elem = malloc(size);
if (i->elem == NULL) {
/* Your sensible action here */
}
memcpy(i->elem, elem, size);
It would be more precise to say that what I want is "the value elem
points to is not changed within the function but the value i->elem
points to may be changed outside the function".
Your suggestion resolved the problem but requires additional memory
that is not necessary had C provided a way to get around this dilemma.
There is no real need to change *elem in the function and thus no need
to malloc a copy of *elem - the need arises only because C does not
satisfy both goals (type compatibility and the desirability to
represent a parameter as "does not change" in a function) at the same
time.

Sep 18 '06 #7

Michal Nazarewicz wrote:
One solution is to cast away the const-ness of elem in that assignment:

Then, constifing the formal parameter would be pointless.
It is not pointless. Constifying the formal parameter tells the
calling function that "Hey, don't worry, I will not change *elem within
me." The caller needs not worry about any side effect.
Another solution is to change the declaration of elem in struct
s_fifoItem to be:
const void *elem;

And that's what you have to do.
The latter solution is not practical because there are other places
that will change *elem.

So you cannot constify the parameter. The function doesn't change
what elem points to but it doesn't matter. It saves the pointer
somewhere for other functions to be able to modify it so indirectly
the function is modifying it.
It matters because constifying a parameter makes a promise that it is
not changed inside the function. Conversely speaking, if the parameter
is not changed inside the function, then it can be const-ified. If the
parameter is not changed inside the function and it still cannot be
const-ified, then what is the use of "const"?
I am inclined to disagreeing to your "indirect modification" argument.
I think "const" promises that the parameter is not modified inside the
function. It is a local promise. My understanding is that it is never
intended to take into consideration whether the parameter would be
modified outside the function, probably as a result of some action
inside the function.
>
However, the former solution of casting away the const-ness is not very
appealing. It is kind of cheating.
If any other function will modify what elem points to you cannot
constify the argument. Compare this to that code:

void inc(int *bar) { ++*bar; }
void foo(const int *const_bar) { inc((int *)const_bar); }

Your saying: OK, foo() doesn't modify *const_bar so we can constify it
but at the same time inc() modifies it so we need to cast it to
non-const pointer but in the end doesn't foo() end modifying
*const_bar?
The difference between your example and my enqueue() example is that in
foo(), you do modify the parameter - the semantics of foo is that the
parameter is incremented, but in enqueue(), *elem is not modified - no
one expect by purely putting a data to a queue would modify the data.

Sep 18 '06 #8
Frederick Gotham wrote:
Should "s_fifoItem " contain a "void*", or a "void const*". If the
former, then this implies that the pointer will be used to alter the data
at that address. If the latter, this implies that the data won't be
altered. If you choose to leave it as "void*", then make your function take a "void*".
I meant the latter - the data won't be altered.

Sep 18 '06 #9
Bill Pursell wrote:
I would go with the former, but a slight modification
of the second solution is to provide an accessor function
which casts away the const from the structure. eg
void *ret;
ret = (void *)(i->elem)
This has essentially exactly the same problems you
describe, but it localizes the cast.
After reading all the related posts in this newsgroup (it turns out
that there are other threads on this subject - just search for "const
poisoning") so far I have felt that this is the most satisfactory
solution.

Sep 18 '06 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
2607
by: Pete | last post by:
I'm developing an open source CMS, but have come across a problem. The system dynamically creates .php files for the front-end of the site, meaning they're owned by user 'nobody'. However, for anyone with safe mode turned on, any "require_once" or "include_once" commands used in these php pages won't work due to safe mode restrictions (the script whose uid is * is not allowed to access..). I want to this system to be available to users...
1
2735
by: Miha | last post by:
hi to everyone... could someone mail me a sample source code of the spatial prisoner's dilemma game...application code,not applet...thanx in advance mihael.sedmak@fer.hr
12
2441
by: Thomas Matthews | last post by:
Hi, According to Robert Martin's Dependency Inversion Principle, http://www.objectmentor.com/resources/articles/dip.pdf, when there is a need to test the type of an object, the code inside the "switch cases" should be placed into the parent class. However, I am finding that this conflicts with the other principles -- the objects now must know details about
4
2289
by: TheFerryman | last post by:
Hi, I keep running up against the same design problem. Let's say I have a cat object like this: //----------------------------------------------------------------------------------------- class Cat { private:
0
1207
by: Colin Basterfield | last post by:
Hi all, Not sure if this is the most appropriate place for this so apologies if inappropriate... I have come back to a framework I built some time ago to see where some refactoring can take place to improve performance, and following some test have highlighted a few areas where some changes would definitely benefit the application.
5
2532
by: c#freeskier89 | last post by:
Can someone please give me some information on sending data through a USB port. What I am trying to do is use the USB port (I get how to do it on a COM port). I am using VC# 2005. I have searched the internet repeatedly but cannot find anything. Overall, what I am trying to do is just activate a LED with a transistor via a progam made in C# by hooking up the the BASE pin of the transistor to the DATA+ pin on the USB cable and then...
1
1297
by: Bishop | last post by:
I have a page that generates a grid of controls; at the end of each row is an update button that is dynamically created with an associated click event. The grid changes based on the date selected in the calendar control and I populate this grid of controls by calling a routine in the page load event. My dilemma is that the page load event executes before my grid control event during a postback, thus the date that the grid references does...
9
1060
by: John | last post by:
Greetings. I apologize for posting this if it is in the wrong group. The boss last week dropped vb.net on my desk and wants to create a web app and a corresponding desktop app. And I'm a newbie to vb.net. Have done vb6 work but not alot. The boss only dropped vb.net and no db to go with it. He indicated for me to use my best judgement on the db. So, I would like to find out what db others of you are using with vb.net for over the...
4
1413
by: arnaudk | last post by:
I have two unrelated types of data elements (objects) which I want to hold in two related types of containers, one for each element type. But this seems contradictory - for consistency, it seems that either the containers should be unrelated through inheritance, or the elements should be related through inheritance. The problem with (a) is that I'd like to specify a base class interface for the containers which necessarily relates them...
1
1093
by: Newcomsas | last post by:
Hello. I have got a little dilemma to solve about AJAX and VS2008. At the moment I'm working on a C# ASP.NET web site in VS2008 environment. The machine that is going to host the site runs with Win2000 OS so it is not possible to install the .NET Framework 3.5 on it. Since I'd like to use .NET AJAX in some pages, I was wondiring if the pre-installed version of it (labeld 3.5 whe you pass with the mouse over the controls) can preserve...
0
8577
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
8512
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
9048
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
8928
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
8774
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
7591
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
5793
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
1
2941
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
3
1931
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.