473,836 Members | 1,586 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

const , and valid converstions of pointers thereto

---- Section 1 ----

------
x.c

int main( void )
{
char **a;
char const *const *b;
b = a; // line(9)
}
------

wpp386 x.c

x.c(9): Warning! W1178: Type qualifier mismatch
x.c(9): Note! N2003: source conversion type is 'char const *const *'
x.c(9): Note! N2004: target conversion type is 'char **'

Okay this is the error, when I went through and cleaned up all the
warnings of passing (char **) as (const char **) parameters in other
compilers (gcc, MSVC), by converting function parameters to (char const
*const *), I STILL had warnings in watcom. This warning should please
to go away[engrish].

(though I still think that if the context is variable data passed to a
process expecting constant data, even if not all levels of indirection
are constant, it should be a compatible conversion, but am proven wrong
by C++ compilers)

----
Cut - ignore after this point.

Please do flog me if I dare misspell or mispunctuate.

In the beginning there is char, which is synonymous for purposes of this
conversation as byte, the plural of which is bytes.

All plural references may be assumed as preferably at least one, but
often more than one.

char c;

c is a variable character.

char const cc;
-or- const char cc;

c is a constant character.

char *s;

a variable pointer which points to a variable character;

char const *s;
-or- const char *s;

a variable pointer which points to a constant character.

char * const s;

A constant pointer which points to a variable character.

char const * const s;
-or- const char * const s;

a constant pointer which points to a constant character;

char * * l;

a variable pointer which points to a variable pointer which points to a
variable character.

char const * * l;
-or- const char * *l;

a variable pointer which points to a variable pointer which points to a
constant character.

char * const * l;

a variable pointer which points to a constant pointer which points to a
variable character;

char * * const l;

a constant pointer which points to a variable pointer which points to a
variable character;

char const * const * s;
-or- const char * const * s;

a variable pointer which points to a constant pointer which points to a
constant character.

char const * * const s;
-or- const char * * const s;

a constant pointer which points to a variable pointer which points to a
constant character.

char const * const * const s;
-or- const char * const * const s;

a constant pointer which points to a constant pointer which points to a
constant character.
One may assume that any code which requires a constant character may be
passed a variable character, with consideration that the implementation
is a single thread, and that the user of the constant data will
compelete before the data will be changed.

A more modern compiler might offer an option of declaring a variable
with volatile characteristics , such that the variable is assumed to be
able to change before a given process completes.

Most all modern compilers, and probably even lint processesors provide
no warning for converting a (char *) to a (const char *), that is if you
will recall, treating a variable character as a constant, immutable
character. Providing, even enforcing, that the process operating on the
data will not modify the data itself.

passing any such reference of non constant data to a constant data
process should not require a warning.
(const char **) = (char **) does not merit a warning, given that (const
char *) = (char *) does not.
-----------------
Some actual output from compilers - this is the program.

(Oops, this demonstrates the extra warnings in converting from (char **)
to (char const * const *)

---
int main( void )
{ char **a; // line (2)
const char *const* b; // line (3)
char *xa; // line (4)
const char *xb; // line (5)
int *xia; // line (6)
const int *xib; // line (7)
b = a; // line (8)
a = b; // line (9)
xa=xb; // line (10)
xb=xa; // line (11)
xia=xib; // line (12)
xib=xia; // line (13)
return 0; // line (14)
}

(msvc compiling as C)
[line](9) : error C2440: '=' : cannot convert from 'const char *const *
' to 'char ** '
Conversion loses qualifiers
[line](10) : error C2440: '=' : cannot convert from 'const char *' to
'char *'
Conversion loses qualifiers
[line](12) : error C2440: '=' : cannot convert from 'const int *' to
'int *'
Conversion loses qualifiers

(msvc compiling as C++)
m:\tmp\x.cpp(9) : error C2440: '=' : cannot convert from 'const char
*const * ' to 'char ** '
Conversion loses qualifiers
m:\tmp\x.cpp(10 ) : error C2440: '=' : cannot convert from 'const char *'
to 'char *'
Conversion loses qualifiers
m:\tmp\x.cpp(12 ) : error C2440: '=' : cannot convert from 'const int *'
to 'int *'
Conversion loses qualifiers

(gcc compiling as C)
x.c: In function 'main':
x.c:8: warning: assignment from incompatible pointer type
x.c:9: warning: assignment from incompatible pointer type
x.c:10: warning: assignment discards qualifiers from pointer target
type
x.c:12: warning: assignment discards qualifiers from pointer target
type

(g++ compiling as c++)
x.c: In function 'int main()':
x.c:9: error: invalid conversion from 'const char* const*' to 'char**'
x.c:10: error: invalid conversion from 'const char*' to 'char*'
x.c:12: error: invalid conversion from 'const int*' to 'int*'

(wcc386)
Open Watcom C32 Optimizing Compiler Version 1.5
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
x.c(8): Warning! W1178: Type qualifier mismatch
x.c(8): Note! N2003: source conversion type is 'char **'
x.c(8): Note! N2004: target conversion type is 'char const *const *'
x.c(9): Warning! W1178: Type qualifier mismatch
x.c(9): Note! N2003: source conversion type is 'char const *const *'
x.c(9): Note! N2004: target conversion type is 'char **'
x.c(10): Warning! W1178: Type qualifier mismatch
x.c(10): Note! N2003: source conversion type is 'char const *'
x.c(10): Note! N2004: target conversion type is 'char *'
x.c(12): Warning! W1178: Type qualifier mismatch
x.c(12): Note! N2003: source conversion type is 'int const *'
x.c(12): Note! N2004: target conversion type is 'int *'
x.c: 15 lines, 4 warnings, 0 errors

(wpp386)
M:\tmp>wpp386 x.c
Open Watcom C++32 Optimizing Compiler Version 1.5
Portions Copyright (c) 1989-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
x.c(9): Error! E246: col(3) left expression is not a pointer to a
constant object
x.c(9): Note! N717: col(3) left operand type is 'char * * (lvalue)'
x.c(9): Note! N718: col(3) right operand type is 'char const * const *'
x.c(10): Error! E246: col(3) left expression is not a pointer to a
constant object
x.c(10): Note! N717: col(3) left operand type is 'char * (lvalue)'
x.c(10): Note! N718: col(3) right operand type is 'char const *'
x.c(12): Error! E246: col(4) left expression is not a pointer to a
constant object
x.c(12): Note! N717: col(4) left operand type is 'int * (lvalue)'
x.c(12): Note! N718: col(4) right operand type is 'int const *'
x.c: 15 lines, no warnings, 3 errors

------

So in conclusion,

line 8 is not a warning or error in any C++ compiler.
nor ls 11 or 13;
-----------------------------------------------
---- section 2 ----

Nov 30 '06 #1
10 2799
d3x0xr said:
---- Section 1 ----

------
x.c

int main( void )
{
char **a;
char const *const *b;
b = a; // line(9)
}
Consider:

char foo = 'F';
char bar = 'B';
char *baz = &foo;
char **quux = &baz;
char const * const * eric;

eric = quux; /* erroneous, and equivalent to your code */

The compiler ought to be able to know for sure, because eric is a pointer to
a const pointer to char, that *eric will not change. But because you can do
this at any time:

*quux = &bar;

it becomes possible for legal code to subvert the constness of *eric, and
the compiler won't like that even a little bit.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Nov 30 '06 #2
d3x0xr said:
>int main( void )
{
char **a;
char const *const *b;
b = a; // line(9)
}
Richard Heathfield <rj*@see.sig.in validwrites:
Consider:

char foo = 'F';
char bar = 'B';
char *baz = &foo;
char **quux = &baz;
char const * const * eric;

eric = quux; /* erroneous, and equivalent to your code */

The compiler ought to be able to know for sure, because eric is a
pointer to a const pointer to char, that *eric will not change.
because you can do this at any time:

*quux = &bar;

it becomes possible for legal code to subvert the constness of
*eric, and the compiler won't like that even a little bit.
As far as I know, the only thing const means is that you (the
programmer) cannot change constant of *eric using pointer eric (since
*eric is of type const char *const; same goes for **eric). Compiler
does not care or know if the actual value can change.

If what you are saying is valid then the following would be invalid:

#v+
char foo[] = "foo";
const char *bar = foo;
#v-

because (as you put it) the compiler ought to be known for sure that
*bar will never change but indeed it can through *foo.

--
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*chr ome.pl>--ooO--(_)--Ooo--
Nov 30 '06 #3
Michal Nazarewicz said:

<snip>
>
If what you are saying [about const] is valid [...]
....then I'm a Dutchman. My apologies to the OP. I shouldn't have answered
that question at all. A few years ago, I worked out the logic behind the
necessity for the C Standard to be so bitchy about constness (because
somebody at work happened to ask me a very similar question to the OP's,
and it mattered, and so I looked very closely at it), and I guess I
believed, very late last night, that I still remembered it clearly enough
to explain it. Apparently not.

CHRIS!

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Nov 30 '06 #4
Richard Heathfield:
d3x0xr said:
>---- Section 1 ----

------
x.c

int main( void )
{
char **a;
char const *const *b;
b = a; // line(9)
}

Consider:

char foo = 'F';
char bar = 'B';
char *baz = &foo;
char **quux = &baz;
char const * const * eric;

eric = quux; /* erroneous, and equivalent to your code */
Why would this not be legal, you're just adding restriction on what you
will do via eric...
>
The compiler ought to be able to know for sure, because eric is a
pointer to
a const pointer to char, that *eric will not change. But because you
can do
this at any time:

*quux = &bar;
however, the standard provides for declarations that are
const volatile int blah;

which means it will change, but it will not be changed by the variable
blah.

Again, what they tell me I have a bad interpeation of is that the const
makes it so that the data will definitly be ROM type data and not
writable, it is not such, it does mean that via the reference of
varaible XXXXX it will not be changed, it does not state that beyond the
context of XXXXX that the variable will not change.
>
it becomes possible for legal code to subvert the constness of *eric,
and
the compiler won't like that even a little bit.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Nov 30 '06 #5
Richard Heathfield <rj*@see.sig.in validwrites:
d3x0xr said:
>---- Section 1 ----

------
x.c

int main( void )
{
char **a;
char const *const *b;
b = a; // line(9)
}

Consider:

char foo = 'F';
char bar = 'B';
char *baz = &foo;
char **quux = &baz;
char const * const * eric;

eric = quux; /* erroneous, and equivalent to your code */

The compiler ought to be able to know for sure, because eric is a pointer to
a const pointer to char, that *eric will not change. But because you can do
this at any time:

*quux = &bar;

it becomes possible for legal code to subvert the constness of *eric, and
the compiler won't like that even a little bit.
This problem comes from two issues interacting:

1) The standard forbids certain dangerous conversion involving
qualified types; and
2) To make things easy the rule forbids some safe conversion like the
one give.

The rule in the standard is designed to prevent modification of a
const like this:

int main(void)
{
const char foo = 'F';
char *p;
const char **cp = (const char **)&p; // force with cast
*cp = &foo;
*p = 'B';

printf("c = %c\n", foo);
return EXIT_SUCCESS;
}

Note that the compiler wants to be able to assume the foo can't change
(and maybe more importantly the programmer wants to assume that!) but
if it allowed the assignment I forced with the cast, the const foo can
be changed, silently.

To keep things simple, the standard says:

6.3.2.3:

[2] For any qualifier q, a pointer to a non-q-qualified type may be
converted to a pointer to the q-qualified version of the type; the
values stored in the original and converted pointers shall compare
equal.

and then:

6.7.3 Type qualifiers

[9] For two qualified types to be compatible, both shall have the
identically qualified version of a compatible type; the order of
type qualifiers within a list of specifiers or qualifiers does not
affect the specified type.

which, I think, allows common (safe) usages, forbids dangerous usages
as above but also rules out certain safe combinations involving more
than one level of indirection.

--
Ben.
Nov 30 '06 #6
my point isn't even in typecasting, no typecast operator considered, as
typecasting allows the programmer to break all rules without warning or
error.

The case is, if i start writing routines that accept const char *...

then I can definatly safely pass "blah" to it, as a const char *.

if the routine is written to take a 'char*' then there are warnings
given when converting from the const char * to the char *.

So, I modify the routines to take const char *... but then eventually I
end up with a routine that takes the address of one of these
parameters... either as a char const *const * or a char const **, both
appropriate to taking the address of a const char * to pass to the
routine.

The deeper one goes with making code correct and declaring const char *
where the code definatly does not modify the content of the string, the
more trouble one has. If I had left everything as 'char*' and left the
const off, I would not be having this discussion...

Actually, the point that started this was taking all this wonderful C
code and compiling it wilth a C++ compiler which definately FORBIDS char
* = const char *. So, the parameters had to change to have a const
modifier where const data was passed such as "xyzzy".

Then, coming back to the C compiler, I get assaulted by warnings.

Ben Bacarisse:
Richard Heathfield <rj*@see.sig.in validwrites:
>d3x0xr said:
>>---- Section 1 ----

------
x.c

int main( void )
{
char **a;
char const *const *b;
b = a; // line(9)
}

Consider:

char foo = 'F';
char bar = 'B';
char *baz = &foo;
char **quux = &baz;
char const * const * eric;

eric = quux; /* erroneous, and equivalent to your code */

The compiler ought to be able to know for sure, because eric is a
pointer to
>a const pointer to char, that *eric will not change. But because you
can do
>this at any time:

*quux = &bar;

it becomes possible for legal code to subvert the constness of *eric,
and
>the compiler won't like that even a little bit.

This problem comes from two issues interacting:

1) The standard forbids certain dangerous conversion involving
qualified types; and
2) To make things easy the rule forbids some safe conversion like the
one give.

The rule in the standard is designed to prevent modification of a
const like this:

int main(void)
{
const char foo = 'F';
char *p;
const char **cp = (const char **)&p; // force with cast
*cp = &foo;
*p = 'B';

printf("c = %c\n", foo);
return EXIT_SUCCESS;
}

Note that the compiler wants to be able to assume the foo can't
change
(and maybe more importantly the programmer wants to assume that!) but
if it allowed the assignment I forced with the cast, the const foo
can
be changed, silently.

To keep things simple, the standard says:

6.3.2.3:

[2] For any qualifier q, a pointer to a non-q-qualified type may be
converted to a pointer to the q-qualified version of the type; the
values stored in the original and converted pointers shall compare
equal.

and then:

6.7.3 Type qualifiers

[9] For two qualified types to be compatible, both shall have the
identically qualified version of a compatible type; the order of
type qualifiers within a list of specifiers or qualifiers does not
affect the specified type.

which, I think, allows common (safe) usages, forbids dangerous usages
as above but also rules out certain safe combinations involving more
than one level of indirection.

--
Ben.
Dec 1 '06 #7
"d3x0xr" <d3***@nowhere. netwrites:
Ben Bacarisse:
>Richard Heathfield <rj*@see.sig.in validwrites:
>>d3x0xr said:
int main( void )
{
char **a;
char const *const *b;
b = a; // line(9)
}

Consider:

char foo = 'F';
char bar = 'B';
char *baz = &foo;
char **quux = &baz;
char const * const * eric;

eric = quux; /* erroneous, and equivalent to your code */

The compiler ought to be able to know for sure, because eric is a
pointer to
>>a const pointer to char, that *eric will not change. But because you
can do
>>this at any time:

*quux = &bar;

it becomes possible for legal code to subvert the constness of *eric,
and
>>the compiler won't like that even a little bit.

This problem comes from two issues interacting:

1) The standard forbids certain dangerous conversion involving
qualified types; and
2) To make things easy the rule forbids some safe conversion like the
one give.

The rule in the standard is designed to prevent modification of a
const like this:

int main(void)
{
const char foo = 'F';
char *p;
const char **cp = (const char **)&p; // force with cast
*cp = &foo;
*p = 'B';

printf("c = %c\n", foo);
return EXIT_SUCCESS;
}

Note that the compiler wants to be able to assume the foo can't
change
>(and maybe more importantly the programmer wants to assume that!) but
if it allowed the assignment I forced with the cast, the const foo
can
>be changed, silently.
<snip standards quotes>
>>
which, I think, allows common (safe) usages, forbids dangerous usages
as above but also rules out certain safe combinations involving more
than one level of indirection.
my point isn't even in typecasting, no typecast operator considered, as
typecasting allows the programmer to break all rules without warning or
error.
I know, but I put the cast in because it is needed. I then tried to
show why the cast helps. It reminds you that what some seemingly safe
assignments are not because they would allow a const object to be
changed. I know that in your original example, this is not the case,
but the standard has opted for a simple rule that also rules out some
safe combinations.

Does anyone know how compatibility between pointers to qualified types
could have been worded to allow all safe combinations whilst ruling
out all unsafe ones?
The case is, if i start writing routines that accept const char *...

then I can definatly safely pass "blah" to it, as a const char *.

if the routine is written to take a 'char*' then there are warnings
given when converting from the const char * to the char *.

So, I modify the routines to take const char *... but then eventually I
end up with a routine that takes the address of one of these
parameters... either as a char const *const * or a char const **, both
appropriate to taking the address of a const char * to pass to the
routine.
But one of these (char const **) *must* be outlawed (or forced with a
cast) because it allows a const object to be modified. The other is
just caught in the net.
The deeper one goes with making code correct and declaring const char *
where the code definatly does not modify the content of the string, the
more trouble one has. If I had left everything as 'char*' and left the
const off, I would not be having this discussion...
But then you get no const-safety. At least this way you have to stop
and think: to pass this value here I need a cast -- is it really a
safe thing to do?

--
Ben.
Dec 1 '06 #8
Again, without typecasting. There's no safe way to write code without
getting assaulted by warnrings of undefined conditions.

Why is that? Why MUST I type cast?

I don't in C++.

I don't in gcc.

Ben Bacarisse:
Richard Heathfield <rj*@see.sig.in validwrites:
>d3x0xr said:
>>---- Section 1 ----

------
x.c

int main( void )
{
char **a;
char const *const *b;
b = a; // line(9)
}

Consider:

char foo = 'F';
char bar = 'B';
char *baz = &foo;
char **quux = &baz;
char const * const * eric;

eric = quux; /* erroneous, and equivalent to your code */

The compiler ought to be able to know for sure, because eric is a
pointer to
>a const pointer to char, that *eric will not change. But because you
can do
>this at any time:

*quux = &bar;

it becomes possible for legal code to subvert the constness of *eric,
and
>the compiler won't like that even a little bit.

This problem comes from two issues interacting:

1) The standard forbids certain dangerous conversion involving
qualified types; and
2) To make things easy the rule forbids some safe conversion like the
one give.

The rule in the standard is designed to prevent modification of a
const like this:

int main(void)
{
const char foo = 'F';
char *p;
const char **cp = (const char **)&p; // force with cast
*cp = &foo;
*p = 'B';

printf("c = %c\n", foo);
return EXIT_SUCCESS;
}

Note that the compiler wants to be able to assume the foo can't
change
(and maybe more importantly the programmer wants to assume that!) but
if it allowed the assignment I forced with the cast, the const foo
can
be changed, silently.

To keep things simple, the standard says:

6.3.2.3:

[2] For any qualifier q, a pointer to a non-q-qualified type may be
converted to a pointer to the q-qualified version of the type; the
values stored in the original and converted pointers shall compare
equal.

and then:

6.7.3 Type qualifiers

[9] For two qualified types to be compatible, both shall have the
identically qualified version of a compatible type; the order of
type qualifiers within a list of specifiers or qualifiers does not
affect the specified type.

which, I think, allows common (safe) usages, forbids dangerous usages
as above but also rules out certain safe combinations involving more
than one level of indirection.

--
Ben.
Dec 2 '06 #9
And even at that, if I do typecasst, doesn't that defeat the compiler's
desire to know that a thing is const?


Ben Bacarisse:
Richard Heathfield <rj*@see.sig.in validwrites:
>d3x0xr said:
>>---- Section 1 ----

------
x.c

int main( void )
{
char **a;
char const *const *b;
b = a; // line(9)
}

Consider:

char foo = 'F';
char bar = 'B';
char *baz = &foo;
char **quux = &baz;
char const * const * eric;

eric = quux; /* erroneous, and equivalent to your code */

The compiler ought to be able to know for sure, because eric is a
pointer to
>a const pointer to char, that *eric will not change. But because you
can do
>this at any time:

*quux = &bar;

it becomes possible for legal code to subvert the constness of *eric,
and
>the compiler won't like that even a little bit.

This problem comes from two issues interacting:

1) The standard forbids certain dangerous conversion involving
qualified types; and
2) To make things easy the rule forbids some safe conversion like the
one give.

The rule in the standard is designed to prevent modification of a
const like this:

int main(void)
{
const char foo = 'F';
char *p;
const char **cp = (const char **)&p; // force with cast
*cp = &foo;
*p = 'B';

printf("c = %c\n", foo);
return EXIT_SUCCESS;
}

Note that the compiler wants to be able to assume the foo can't
change
(and maybe more importantly the programmer wants to assume that!) but
if it allowed the assignment I forced with the cast, the const foo
can
be changed, silently.

To keep things simple, the standard says:

6.3.2.3:

[2] For any qualifier q, a pointer to a non-q-qualified type may be
converted to a pointer to the q-qualified version of the type; the
values stored in the original and converted pointers shall compare
equal.

and then:

6.7.3 Type qualifiers

[9] For two qualified types to be compatible, both shall have the
identically qualified version of a compatible type; the order of
type qualifiers within a list of specifiers or qualifiers does not
affect the specified type.

which, I think, allows common (safe) usages, forbids dangerous usages
as above but also rules out certain safe combinations involving more
than one level of indirection.

--
Ben.
Dec 2 '06 #10

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

Similar topics

19
6882
by: Thomas Matthews | last post by:
Hi, Given a structure of pointers: struct Example_Struct { unsigned char * ptr_buffer; unsigned int * ptr_numbers; }; And a function that will accept the structure:
4
1810
by: NKOBAYE027 | last post by:
Hi Everyone: Short description first MathematicalSet is to be a class template that's supposed to behave as the name suggests. It has functions that define union, contains, is_contained_in, etc... I want the thing to behave like a normal collection as well. That is to comply with the ansi standard for STL collections even though it manages two separate lists and two statics (universe and null). The first collection is an object pool...
7
4370
by: al | last post by:
char s = "This string literal"; or char *s= "This string literal"; Both define a string literal. Both suppose to be read-only and not to be modified according to Standard. And both have type of "const char *". Right? But why does the compiler I am using allow s to be modified, instead of generating compile error?
6
8272
by: bob_jenkins | last post by:
{ const void *p; (void)memset((void *)p, ' ', (size_t)10); } Should this call to memset() be legal? Memset is of type void *memset(void *, unsigned char, size_t) Also, (void *) is the generic pointer type. My real question is, is (void *) such a generic pointer type that it
23
2101
by: grubertm | last post by:
When accessing pointer member variables these are not treated as const even though the instance is const. This came as a complete surprise to me and I would appreciate some feedback why that is the case. Here's a snippet: class MyClass { public: char *pChar; }; void ChangePointedTo (char *ch)
12
2445
by: Luca | last post by:
I have 2 questions: 1. Which one is the best: Returning member variables of the class by const ref or returning by pointer? e.g.: Employee* GetEmployee() const; Employee& GetEmployee() const;
0
1879
by: d3x0xr | last post by:
Heh, spelled out in black and white even :) Const is useles... do NOT follow the path of considering any data consatant, because in time, you will have references to it that C does not handle, and you'll be left with just noisy compiler warnings and confusion. if you start a project with all char *, and char ** and even char ***, if you begin at the low level weeding out references of 'passing const char * to char * ( such as...
13
10299
by: ragged_hippy | last post by:
Hi, I wanted to create a vector of const references. Something like this: vector<const x&y; where x is a class name. Is this a valid statement? Will this work if I use a reference of 'y' somewhere else?
17
2452
by: Adrian Hawryluk | last post by:
Hi all, What is everyone's opinion of const inheriting? Should the object that a pointer is pointing at inherit the constness of the pointer? Such as in the case of a class having a pointer and then dereferencing that pointer. Should the dereferenced pointer have the same constness of the pointer as the pointer has the same constness as the class object? Yes, I am aware that C++ does not do this. I just want to know everyones...
0
9826
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
9674
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
10860
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
9389
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...
1
7796
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
6984
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();...
0
5659
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
5831
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
4466
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

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.