473,836 Members | 2,106 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Is C99 the final C?

I was just thinking about this, specifically wondering if there's any
features that the C specification currently lacks, and which may be
included in some future standardization .

Of course, I speak only of features in the spirit of C; something like
object-orientation, though a nice feature, does not belong in C.
Something like being able to #define a #define would be very handy,
though, e.g:

#define DECLARE_FOO(bar ) #define FOO_bar_SOMETHI NG \
#define FOO_bar_SOMETHI NG_ELSE

I'm not sure whether the features of cpp are even included in the C
standard though (and GCC has definitely taken quite a nonstandard approach
with regards to certain token expansions and whatnot), but that's one area
of improvement I see.

I would also like to see something along the lines of C++ templating,
except without the really kludgy implementation that the C++ folks decided
to go to ( and without the OOP ).

.... Mike pauses for the sound of a thousand *plonks*

Templates save a lot of time when it comes to commonly-used data
structures, and as they are entirely implemented at compile-time and don't
include, by their definition, OOP (although they can be well suited to
it), I think they would be a nice addition and in the spirit of C.

Your thoughts? I'm sure there's some vitriol coming my way but I'm
prepared 8)

--
Mike's Patented Blocklist; compile with gcc:

i=0;o(a){printf ("%u",i>>8*a&25 5);if(a){printf (".");o(--a);}}
main(){do{o(3); puts("");}while (++i);}

Nov 13 '05
193 9665
In <bq**********@n ews.tudelft.nl> Sidney Cadot <si****@jigsaw. nl> writes:
Ok. I'll give you 10:1 odds; there will be a (near-perfect) C99 compiler
by the end of this decade.


By then, C99 is supposed to be obsoleted by C0x ;-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #101
"Dan Pop" <Da*****@cern.c h> wrote in message
news:bq******** **@sunnews.cern .ch...
In <bq**********@n ews.tudelft.nl> Sidney Cadot <si****@jigsaw. nl> writes:

Ok. I'll give you 10:1 odds; there will be a (near-perfect) C99 compiler
by the end of this decade.


By then, C99 is supposed to be obsoleted by C0x ;-)


Not sure how to read this, even with the emoticon. The C committee has
agreed to *reaffirm* the C Standard for the next several years, rather
than begin work on a major revision. I'd say that the odds of there
ever bing an official C0x to replace C99 are pretty small.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Nov 13 '05 #102
In <Zm************ ****@nwrddc01.g nilink.net> "P.J. Plauger" <pj*@dinkumware .com> writes:
"Dan Pop" <Da*****@cern.c h> wrote in message
news:bq******* ***@sunnews.cer n.ch...
In <bq**********@n ews.tudelft.nl> Sidney Cadot <si****@jigsaw. nl> writes:

>Ok. I'll give you 10:1 odds; there will be a (near-perfect) C99 compiler
>by the end of this decade.


By then, C99 is supposed to be obsoleted by C0x ;-)


Not sure how to read this, even with the emoticon. The C committee has
agreed to *reaffirm* the C Standard for the next several years, rather
than begin work on a major revision. I'd say that the odds of there
ever bing an official C0x to replace C99 are pretty small.


In comp.std.c committee members keep mentioning C0x as the next C
standard.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #103
In article <ln************ @nuthaus.mib.or g>, ks***@mib.org says...
qe*@pobox.com (Paul Hsieh) writes:
Sidney Cadot <si****@jigsaw. nl> wrote: [...]
* support for a "packed" attribute to structs, guaranteeing that no
padding occurs.


Indeed, this is something I use on the x86 all the time. The problem
is that on platforms like UltraSparc or Alpha, this will either
inevitably lead to BUS errors, or extremely slow performing code.

If instead, the preprocessor were a lot more functional, then you
could simply extract packed offsets from a list of declarations and
literally plug them in as offsets into a char[] and do the slow memcpy
operations yourself.


Obviously an implementation of packed structures is useless if it
leads to bus errors.

There's ample precedent in other languages (Pascal and Ada at least)
for packed structures. [...] You can't sensible take the address of
packed_obj.i. A function that takes an "int*" argument will likely die if
you give it a misaligned pointer (unless you want to allow _Packed as an
attribute for function arguments). The simplest approach would be to forbid
taking the address of a member of a packed structure (think of the members
as fat bit fields). [...]


Then what would be the point of even calling it a "struct"? This is what I am
saying -- it leads to bus errors because of the rest of the language concepts
like taking the address of any value that is stored in a memory location.
Another possibility (ugly but perhaps useful) is to make the address of a
member of a packed field yield a void*.
No -- the problem is with the BUS error itself. The C language doesn't need
*EVEN MORE* ways of creating UB with otherise acceptable syntax. This is more
than just ugly is very very anti-intuitive.

The right answer is to give such pointers a special attribute, like,
"_Unaligned " (or simply reuse "_Packed".) The compiler would then enforce type
safety in the following way: A non-"_Unaligned " pointer may not accept that
value of an "_Unaligned " pointer, but the other way around is not true.
Certain functions like memcpy and memmove would then be declared with these
"_Unaligned " decorators. But programmers could go ahead and use the decorator
themselves so that unaligned accesses could be propogated arbitrarily down a
call stack in a well-defined and programmer controlled way. This would
precisely encapsulate what the programmer is trying to do without allowing the
compiler to produce unexpected BUS errors. Attempts to address an unaligned
pointer will be caught at compile time -- the perfect solution.
* upgraded status of enum types (they are currently quite
interchangeable with ints); deprecation of implicit casts from
int to enum (perhaps supported by a mandatory compiler warning).


I agree. Enums, as far as I can tell, are almost useless from a
compiler assisted code integrity point of view because of the
automatic coercion between ints and enums. Its almost not worth the
bothering to ever using an enum for any reason because of it.


I don't think enums can be repaired without breaking tons of existing
code. And they are useful as currently defined for defining names for
a number of distinct integer values. If you want Pascal-like
enumeration types, you'd need a new construct -- but I think having
two distinct kinds of enumeration types would be too ugly for new
users.


How about another decorator? Like: enum _Strict ____ {...}; ? Basically the
language would not auto-convert such enums to ints at all without an explicit
cast. Once again, under programmer control.
* a clear statement concerning the minimal level of active function
calls invocations that an implementation needs to support.
Currently, recursive programs will stackfault at a certain point,
and this situation is not handled satisfactorily in the standard
(it is not adressed at all, that is), as far as I can tell.


That doesn't seem possible. The amount of "stack" that an
implementation might use for a given function is clearly not easy to
define. Better to just leave this loose.


Agreed. The limit on call depth is typically determined by the amount
of available memory, something a compiler implementer can't say much
about. You could sensibly add a call depth clause to the Translation
Limits section (C99 5.2.4.1); that would the [require the] implementation to
handle at least one program with a call depth of N, but wouldn't really
guarantee anything in general.


Well the problem with this is that then the *LINKER* would have to have
augmented to analyze the max relevant stack size of all functions in an object
and then assign the final stack according to a formula (N * maxstacksz) that
makes this work. It also kind of makes use of alloca impossible.
[...]
* a #define'd constant in stdio.h that gives the maximal number of
characters that a "%p" format specifier can emit. Likewise, for
other format specifiers such as "%d" and the like.

* a printf format specifier for printing numbers in base-2.
Ah -- the kludge request. Rather than adding format specifiers one at
a time, why not instead add in a way of being able to plug in
programmer-defined format specifiers? I think people in general would
like to use printf for printing out more than just the base types in a
collection of just a few formats defined at the whims of some 70s UNIX
hackers. Why not be able to print out your data structures, or
relevant parts of them as you see fit?


Well, you can do that with the "%s" specifier, as long as you've
defined a function that returns an image string for a value of your
type (with all the complications of functions returning dynamic
strings).


Who is going to free the memory allocated for this string? If its static, then
what happens when you try to printf two such items -- or just try to use it in
a multitasking environment in general?
* 'min' and 'max' operators (following gcc: ?< and ?>)


As I mentioned above, you might as well have operator overloading instead.


Most languages that provide operator overloading restrict it to
existing operator symbols.


Yeah well most languages have real string primitives and built-in array range
checking too. Somehow I don't think what has been done in *other languages*
has any serious bearing on what should be done in C. To reiterate my proposal:
A whole *GRAMMAR* of symbols for operators could be added all of which have no
default definition, but which *can be* defined by the programmer, with
semantics similar to C's function declaration.
[...] If you want "min" and "max" for int, there
aren't any spare operator symbols you can use. If you want to allow
overloading for arbitrary symbols (which some languages do), you'll
need to decide how and whether the user can define precedence for the
new operators.
Good point, but something as simple as "lowest precendence" and increasing in
the order in which they are declared seems fine enough. Or maybe inverted --
just play with those combinations to see what makes sense in practice. If
that's not good enough, then make the precedence level relative to another
operator at the time of declaration. For example:

int _Operator ?< after + (int x, int y) { /* max */
if (x > y) return x;
return y;
}

int _Operator ?> same ?< (int x, int y) { /* min */
if (x < y) return x;
return y;
}
[...]
Personally, I don't think it would be a good idea to have templates
in C, not even simple ones. This is bound to have quite complicated
semantics that I would not like to internalize.
Right -- this would just be making C into C++. Why not instead
dramatically improve the functionality of the preprocessor so that the
macro-like cobblings we put together in place of templates are
actually good for something? I've posted elsewhere about this, so I
won't go into details.


Hmm. I'm not sure that making the preprocessor *more* powerful is
such a good idea. It's too easy to abuse as it is [...]


A *LOT* of C is easy to abuse. If you're worried about programmer you are
working with's abuse of the preprocessor then that's an issue between you and
that programmer.
If you can improve the preprocessor without making it even more
dangerous, that's great. (I don't think I've see your proposal.)


My proposal is to add preprocessor-only scoped variables:

#define $c 1

The idea is that "$c" could never show up as such a symbol in the C source
after preprocessing is done. And in cases where such a $___ variable has not
been defined you could insert an instance specific generated variable such as:

$c -> __PREPROCINST_M D5_09839fe8d987 98fe8978de98799 cfe01_c

so as to kind of put it into its own kind of "name-space" that is not really
"accessible " to the programmer. Where the MD5 obfuscation would come from a
source like: <filename><date ,time><MD5(sour ce)><the $varname> in an effort to
probabilistical ly avoid collisions across files (trust me, this is not as much
voodoo as you might think) in case some bozo turns this into a global
declaration.

The purpose is to allow for even more useful things like:

#for $c in #range(0,5)
printf ("Even: %d Odd: %d\n", 2*$c, 2*$c+1);
#endfor

/* #range(0,5) just expands to 0,1,2,3,4 and the #for loop works, kind of
python-like, just as you would expect. */

#define genStruct(name, #VARARGS) struct tag##name { #VARARGS };\
#for $c in #VARARGS
# define offsetof_##$c offsetof (tag##name, %c)
#endfor

/* Here the "\" is required to attach the #for, which then itself
has an implicit multi-line characteristic, so that the lines
up until the #endfor are sucked into the #define genStruct.
Also, #define's executed inside of a #for are repeatedly
executed for each iteration */

#define swap(type,x,y) { \
type $tmp = x; \
x = y; \
y = $tmp; \
}

/* In this case, without prior definition, $tmp is given an
obfuscated name by the time it reaches the C source code. */

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
Nov 13 '05 #104
"Dan Pop" <Da*****@cern.c h> wrote in message
news:bq******** **@sunnews.cern .ch...
By then, C99 is supposed to be obsoleted by C0x ;-)


Not sure how to read this, even with the emoticon. The C committee has
agreed to *reaffirm* the C Standard for the next several years, rather
than begin work on a major revision. I'd say that the odds of there
ever bing an official C0x to replace C99 are pretty small.


In comp.std.c committee members keep mentioning C0x as the next C
standard.


Ah, peer pressure. Even the crustiest of us succumb sometimes.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Nov 13 '05 #105
Sidney Cadot <si****@jigsaw. nl> writes:
Paul Hsieh wrote: [...] I used "%x" as an example of a format specifier that isn't defined ('x'
being a placeholder for any letter that hasn't been taken by the
standard). The statement is that there'd be only 15 about letters left
for this kind of thing (including 'x' by the way -- it's not a hex
specifier). Sorry for the confusion, I should've been clearer.


What do you mean when you say that "%x" is not a hex specifier?
That's either confusing or wrong.

printf("foo = %x\n", foo);

[...]
Yes I'm sure the same trick works for chars and shorts. So how do
you widen a long long multiply?!?!? What compiler trick are you
going to hope for to capture this? What you show here is just
some trivial *SMALL* multiply, that relies on the whims of the
optimizer.


Well, I'd show you, but it's impossible _in principle_. Given that you
are multiplying two expressions of the widest type supported by your
compiler, where would it store the result?


In a struct, or in an array of two int_max_t's or uint_max_t's.
(Wasn't that a common trick in primordial C, before the introduction
of "long"?)

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)
Nov 13 '05 #106
qe*@pobox.com (Paul Hsieh) writes:
In article <ln************ @nuthaus.mib.or g>, ks***@mib.org says... [...]
There's ample precedent in other languages (Pascal and Ada at
least) for packed structures. [...] You can't sensible take the
address of packed_obj.i. A function that takes an "int*" argument
will likely die if you give it a misaligned pointer (unless you
want to allow _Packed as an attribute for function arguments).
The simplest approach would be to forbid taking the address of a
member of a packed structure (think of the members as fat bit
fields). [...]


Then what would be the point of even calling it a "struct"? This is
what I am saying -- it leads to bus errors because of the rest of
the language concepts like taking the address of any value that is
stored in a memory location.


Surely it's no worse than calling a struct with bit fields a "struct".
Another possibility (ugly but perhaps useful) is to make the address of a
member of a packed field yield a void*.


No -- the problem is with the BUS error itself. The C language
doesn't need *EVEN MORE* ways of creating UB with otherise
acceptable syntax. This is more than just ugly is very very
anti-intuitive.


My thought was that making &struct_obj.pac ked_member yield a void*
would force the programmer to be careful about how he uses it. I
momentarily forgot about the implicit conversion from void* to any
object pointer type. (Which was dumb; I've even been participating in
the permanent floating "don't cast the result of malloc()" flameware.)
The right answer is to give such pointers a special attribute, like,
"_Unaligned " (or simply reuse "_Packed".)

[snip]

Yeah, that makes more sense than my idea.

BTW, I'm not necessarily arguing that packed structures would be worth
adding to the language, just thinking about how to do it right if it's
going to be done at all.

[...]
Agreed. The limit on call depth is typically determined by the
amount of available memory, something a compiler implementer can't
say much about. You could sensibly add a call depth clause to the
Translation Limits section (C99 5.2.4.1); that would the [require
the] implementation to handle at least one program with a call
depth of N, but wouldn't really guarantee anything in general.


Well the problem with this is that then the *LINKER* would have to
have augmented to analyze the max relevant stack size of all
functions in an object and then assign the final stack according to
a formula (N * maxstacksz) that makes this work. It also kind of
makes use of alloca impossible.


No, adding a call depth requirement to C99 5.2.4.1 wouldn't require
any kind of analysis. There would be no guarantee that a given depth
will be supported in all cases, merely that the implementation has to
translate and execute at least one program that hits the limit (along
with all the others). If a requirement for a call depth of at least,
say, 100 were added to 5.2.4.1, it could probably be met by all
existing implementations with no changes.

[...]
Well, you can do that with the "%s" specifier, as long as you've
defined a function that returns an image string for a value of your
type (with all the complications of functions returning dynamic
strings).


Who is going to free the memory allocated for this string? If its
static, then what happens when you try to printf two such items --
or just try to use it in a multitasking environment in general?


That's the same problem you have with any function that returns a
string. There are numerous solutions; programmers reinvent them all
the time.

If you can come up with a specification for an enhanced printf that
can produce arbitrary user-defined output for arbitrary user-defined
types, we can discuss whether it's better than "%s" with an image
function.
[...] If you want "min" and "max" for int, there
aren't any spare operator symbols you can use. If you want to allow
overloading for arbitrary symbols (which some languages do), you'll
need to decide how and whether the user can define precedence for the
new operators.


Good point, but something as simple as "lowest precendence" and
increasing in the order in which they are declared seems fine
enough. Or maybe inverted -- just play with those combinations to
see what makes sense in practice. If that's not good enough, then
make the precedence level relative to another operator at the time
of declaration. For example:
int _Operator ?< after + (int x, int y) { /* max */
if (x > y) return x;
return y;
}

int _Operator ?> same ?< (int x, int y) { /* min */
if (x < y) return x;
return y;
}


I think "increasing in the order in which they are declared" would be
very bad; you could quietly change the semantics of an expression by
reordering the declarations of the operators it uses (e.g., by
changing the order of #include directives).

For most C operators, the common rule for legible code is
"parenthesi ze, parenthesize, parenthesize". For user-defined
operators (if I thought they were a good idea), I'd probably advocate
not defining their precedence at all; if you want to write "x + y @ z",
you *have* to use parentheses. The next best thing might be to say
that all user-defined operators have the same precedence, perhaps just
above assignment.

People already complain that C looks like line noise; I don't think
assigning meanings to more arbitrary sequences of punctuation marks
solves anything. (And I would have thought that "?<" should be min,
and "?>" should be max.)

In the particular case of "min" and "max", I'd much rather just call
them "min" and "max". If you're going to have operator overloading,
you probably want function overloading as well. Even if you insist on
operator syntax rather than function call syntax, "a max b" is at
least as legible as "a $< b".

For most of the things that I'd want to see as operators, the existing
operator symbols are more than sufficient; for anything else, just use
identifiers.

[snip]

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)
Nov 13 '05 #107
Keith Thompson wrote:
I used "%x" as an example of a format specifier that isn't defined ('x'
being a placeholder for any letter that hasn't been taken by the
standard). The statement is that there'd be only 15 about letters left
for this kind of thing (including 'x' by the way -- it's not a hex
specifier). Sorry for the confusion, I should've been clearer.
What do you mean when you say that "%x" is not a hex specifier?
That's either confusing or wrong.

printf("foo = %x\n", foo);
It is wrong. A very stupid lapse on my side.
[...]
Yes I'm sure the same trick works for chars and shorts. So how do
you widen a long long multiply?!?!? What compiler trick are you
going to hope for to capture this? What you show here is just
some trivial *SMALL* multiply, that relies on the whims of the
optimizer.
Well, I'd show you, but it's impossible _in principle_. Given that you
are multiplying two expressions of the widest type supported by your
compiler, where would it store the result?

In a struct, or in an array of two int_max_t's or uint_max_t's.
(Wasn't that a common trick in primordial C, before the introduction
of "long"?)


Yes, that would work, and could be useful. For the signed case, a struct
containing an int_max_t for the most significant part and an uint_max_t
for the least significant part might a more proper choice?

Best regards, Sidney

Nov 13 '05 #108
Paul Hsieh wrote:
Good point, but something as simple as "lowest precendence" and increasing in
the order in which they are declared seems fine enough. Or maybe inverted --
just play with those combinations to see what makes sense in practice. If
that's not good enough, then make the precedence level relative to another
operator at the time of declaration. For example: int _Operator ?< after + (int x, int y) { /* max */
if (x > y) return x;
return y;
}

int _Operator ?> same ?< (int x, int y) { /* min */
if (x < y) return x;
return y;
}


That looks like a decent first stab at a proposed syntax. Some question
though:

- What would be the constraints on acceptable operator names?

- How are you going to define left, right, or lack of associativity?

- In what way will you handle the possible introduction of ambiguity in
the parser, that gets to parse the new tokens?

- What if I want a ?< to work both on int and on double types?

- does (and if so, how) does your syntax allow the introduction of unary
prefix operators (such as !), binary infix operators that may have
compile-time identifiers as a parameter (such as ->), n-ary operators
(such as the ternary a?b:c or your proposed quaternary carry/add
operator), and operators that exist both in unary and binary form (+, -)?

My gut feeling is that this would effectively force the compiler to
maintain a dynamic parser on-the-fly while scanning through the source,
which would be wildly complex. You mentioned that actual languages exist
that do this sort of thing; are they also compiled languages like C, or
are they interpreted languages of the functional variety?

Best regards,

Sidney

Nov 13 '05 #109
Sidney Cadot <si****@jigsaw. nl> writes:
[...]
It is wrong. A very stupid lapse on my side.


Hey, this is Usenet! You're not supposed to admit mistakes here. The
least you could do is sneakily change the subject and start being
personally abusive. 8-)}

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)
Nov 13 '05 #110

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

Similar topics

1
3455
by: Anthony Martin | last post by:
I've been reading the Java Language Specification, and in Chapter 16 there's an interesting topic called Definite Assignment. http://tinyurl.com/3fqk8 I'm wondering about the idea of "Deferred Final Automatic Variables" like the following: void unflow(boolean flag) { final int k;
14
23149
by: Medi Montaseri | last post by:
Hi, I think my problem is indeed "how to implement something like java's final in C++" The long version.... I have an abstract base class which is inherited by several concrete classes. I have a group of methods that I'd like to implement in the base class
48
8720
by: David J Patrick | last post by:
I'm trying to rewrite the CSS used in http://s92415866.onlinehome.us/files/ScreenplayCSSv2.html. using the w3.org paged media standards as described at http://www.w3.org/TR/REC-CSS2/page.html The ScreenplayCSS is flawed, for several reasons; -overuse of <div id= tags -doesn't scale screen resolutions (convert from px to in, pt ?) -no media="print" (how much coule be shared between "screen" & "print") -no automatic page breaks (with...
10
5123
by: Bezalel Bareli | last post by:
I know I have seen some threads on the subject long time ago and it was using a virtual base class ... in short, what is the nicest way to implement the Java final class in c++ Thanks.
14
1777
by: My4thPersonality | last post by:
Has the fact that both Java and C# are garbage collected, and C++ in not, anything to do with the fact that there is no language item to prevent a class from being inherired from? I once read that Java and C# implement this feature for preformance, but the C++ creators said it was not worse the effort. So because Java and C# are garbage collected, in their case is it worse the effort? What is the connection?
1
8624
by: silverburgh.meryl | last post by:
I am trying to convert this code from java to c++: public final class Type { public static final int DEFAULT = 1; private static int index = 2; public static final int COLUMN1 = (int) Math.pow(2, index++); public static final int COLUMN2 = (int) Math.pow(2, index++); public static final int COLUMN3 = (int) Math.pow(2, index++); public static final int COLUMN4 = (int) Math.pow(2, index++);
5
1399
by: Anthony Baxter | last post by:
On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.4.3 (final). Python 2.4.3 is a bug-fix release. See the release notes at the website (also available as Misc/NEWS in the source distribution) for details of the more than 50 bugs squished in this release, including a number found by the Coverity Scan project. Assuming no major bugs pop up, the next release of Python will be...
14
2997
by: Rahul | last post by:
Hi Everyone, I was searching for final class in c++, and i came across few links which suggests to have the constructor of the, to be final class, as private so that any derived class's constructors can't access the same. class C { private:
1
1709
by: Rajib | last post by:
Not that this serves any real purpose, but gcc allows me to do some hack like this: class hide_A { public: class A { public: virtual int final() { return 42; } };
0
9656
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
10821
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...
1
10575
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
10241
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
9358
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
6975
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
5642
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...
1
4443
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
3102
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.