Hello
I've read here that only C language has a standard 64bit integer.
Can you please tell me what are the reasons for this ? What is special about
C language ?
Can you please show me some references to this integer type ? When was it
introduced ?
Thank you
Timothy Madden
Romania
-------------------------------------------------
And I don't wanna miss a thing
28  2453 
Timothy Madden wrote: Hello
I've read here that only C language has a standard 64bit integer.
That's not quite it. The integer types don't have fixed sizes, they only
have minimum sizes. And it happens that C has the type "long long", which
is required to be at least 64bit, and C++ doesn't.
Can you please tell me what are the reasons for this ?
The C++ language standard is based on the C89 standard, which doesn't have
"long long" either. The new version of the C standard that contains the new
type was finished one year after the C++ standard.
What is special about C language ?
Can you please show me some references to this integer type ? When was it
introduced ?
In the C99 standard.
On Mon, 20 Sep 2004 12:10:28 +0300, "Timothy Madden"
<ba****@rmv.spam.home.ro> wrote in comp.lang.c++: Hello
I've read here that only C language has a standard 64bit integer.
No, C has defined the signed and unsigned 'long long' integer types
that must contain at least 64 bits, but could have more.
But it is not "only C", just merely not C++. Java, for example, has
exact-width 64-bit integer types, as do some other languages.
Can you please tell me what are the reasons for this ? What is special about
C language ?
Most of the things that are special about C have nothing at all to do
with this.
As for the reasons, disk drives today cost less than $1.00USD per
gigabyte of storage. It is not even uncommon in some types of
applications to have files containing more than 32 bits worth of
octets.
On a busy trading day, the NASDAQ stock exchange can trade more shares
than can be counted in a signed 32-bit integer type, and the NASDAQ
and AMEX together more than can be counted in an unsigned 32-bit
integer.
Computers today, even 32-bit ones not to mention 64-bit ones, can
easily have enough memory that they can have arrays larger than 2^32
bytes in size, so there must be signed and unsigned integer types
large enough to be size_t and ptrdiff_t for these to work.
Just to name a few situations where an integer type with a width
greater than 32 bits is needed.
The real question is why the C++ standard, being finalized not too
much before the 1999 major update to the C standard, did not include
the 'long long' type or indeed all of the expansions to the integer
types that C added in 1999.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
"Jack Klein" <ja*******@spamcop.net> wrote in message
news:t5********************************@4ax.com... On Mon, 20 Sep 2004 12:10:28 +0300, "Timothy Madden"
<ba****@rmv.spam.home.ro> wrote in comp.lang.c++:
Hello
I've read here that only C language has a standard 64bit integer.
No, C has defined the signed and unsigned 'long long' integer types
that must contain at least 64 bits, but could have more.
But it is not "only C", just merely not C++. Java, for example, has
exact-width 64-bit integer types, as do some other languages.
Can you please tell me what are the reasons for this ? What is special
about C language ?
Most of the things that are special about C have nothing at all to do
with this.
As for the reasons, disk drives today cost less than $1.00USD per
gigabyte of storage. It is not even uncommon in some types of
applications to have files containing more than 32 bits worth of
octets.
On a busy trading day, the NASDAQ stock exchange can trade more shares
than can be counted in a signed 32-bit integer type, and the NASDAQ
and AMEX together more than can be counted in an unsigned 32-bit
integer.
Computers today, even 32-bit ones not to mention 64-bit ones, can
easily have enough memory that they can have arrays larger than 2^32
bytes in size, so there must be signed and unsigned integer types
large enough to be size_t and ptrdiff_t for these to work.
Just to name a few situations where an integer type with a width
greater than 32 bits is needed.
The real question is why the C++ standard, being finalized not too
much before the 1999 major update to the C standard, did not include
the 'long long' type or indeed all of the expansions to the integer
types that C added in 1999.
I understand now
It's because the new type is named 'long long'.
It is really ugly for a standard type.
They could have just said number, integer, real, numeric, natural or
something ...
Pascal has a special large numeric type named 'comp' for example
(implemented with floats)
Language designers had more imagination it it's case, and nobody asked why
the type is named 'comp'
Timothy Madden
Romania
----------------------------------------
And I don't wanna miss a thing
Timothy Madden wrote: The real question is why the C++ standard, being finalized not too
much before the 1999 major update to the C standard, did not include
the 'long long' type or indeed all of the expansions to the integer
types that C added in 1999.
I understand now
It's because the new type is named 'long long'.
It is really ugly for a standard type.
They could have just said number, integer, real, numeric, natural or
something ...
Pascal has a special large numeric type named 'comp' for example
(implemented with floats)
Language designers had more imagination it it's case, and nobody asked why
Or something like int64, etc.
That said, nothing restricts an implementation to provide a long of 64
bits, since long is at least 32 bits. And personally I do not favour the
addition of a new type, since long can do the job.
--
Ioannis Vranos http://www23.brinkster.com/noicys
Ioannis Vranos wrote: Timothy Madden wrote:
The real question is why the C++ standard, being finalized not too
much before the 1999 major update to the C standard, did not include
the 'long long' type or indeed all of the expansions to the integer
types that C added in 1999.
I understand now
It's because the new type is named 'long long'.
It is really ugly for a standard type.
They could have just said number, integer, real, numeric, natural or
something ...
Pascal has a special large numeric type named 'comp' for example
(implemented with floats)
Language designers had more imagination it it's case, and nobody asked
why
Or something like int64, etc.
That said, nothing restricts an implementation to provide a long of 64
bits, since long is at least 32 bits. And personally I do not favour the
addition of a new type, since long can do the job.
You're missing the point, probably. Yes, on some platforms 'long int' can
do the job, but adding a new type to the language would ensure that on
_all_ platforms there is something that is at least 64 bits. 'long int'
is only guaranteed to be 32 bits, so we are still facing with some kind of
compatibility problem when porting 64-bit-enabled code from one platform
to another.
Victor
Victor Bazarov wrote: You're missing the point, probably. Yes, on some platforms 'long int' can
do the job, but adding a new type to the language would ensure that on
_all_ platforms there is something that is at least 64 bits. 'long int'
is only guaranteed to be 32 bits, so we are still facing with some kind of
compatibility problem when porting 64-bit-enabled code from one platform
to another.
What about a new guarantee that long is at least 64-bit? It is a
"superset" of the guarantee that it is at least 32-bit.
--
Ioannis Vranos http://www23.brinkster.com/noicys
Rolf Magnus wrote: Timothy Madden wrote:
Hello
I've read here that only C language has a standard 64bit integer.
That's not quite it. The integer types don't have fixed sizes, they
only have minimum sizes. And it happens that C has the type "long
long", which is required to be at least 64bit, and C++ doesn't.
It should be noted that the new C standard also mentions exact-width
types, although these are optional. Most C99 compilers will likely
provide them.
Brian Rodenborn
Ioannis Vranos wrote: Victor Bazarov wrote:
You're missing the point, probably. Yes, on some platforms 'long int'
can
do the job, but adding a new type to the language would ensure that on
_all_ platforms there is something that is at least 64 bits. 'long int'
is only guaranteed to be 32 bits, so we are still facing with some
kind of
compatibility problem when porting 64-bit-enabled code from one platform
to another.
What about a new guarantee that long is at least 64-bit? It is a
"superset" of the guarantee that it is at least 32-bit.
Such requirement would probably make many programs running today utterly
inefficient on the multitude of 16-bit platforms. Imagine that all 32-bit
calculations would have to be replaced with 64-bit ones.
V
Victor Bazarov wrote: Such requirement would probably make many programs running today utterly
inefficient on the multitude of 16-bit platforms. Imagine that all 32-bit
calculations would have to be replaced with 64-bit ones.
long long will not be inefficient in those systems? If you have such
portability-to-16 bits concerns, you should use int in the first place.
--
Ioannis Vranos http://www23.brinkster.com/noicys
Ioannis Vranos wrote: Victor Bazarov wrote:
Such requirement would probably make many programs running today utterly
inefficient on the multitude of 16-bit platforms. Imagine that all
32-bit
calculations would have to be replaced with 64-bit ones.
long long will not be inefficient in those systems?
Most likely it won't.
If you have such
portability-to-16 bits concerns, you should use int in the first place.
Why? What if 'int' doesn't cut it? What if I need 28 bits? I shouldn't
have to waste time and memory dealing with 64 bit types if it can all be
handled by 32 bits.
Victor Bazarov wrote: Why? What if 'int' doesn't cut it? What if I need 28 bits? I shouldn't
have to waste time and memory dealing with 64 bit types if it can all be
handled by 32 bits.
OK I can understand such a need.In the case of extensions in the type
system, the approach taken should be extensible.
Leaving C aside since it is a different language, what about introducing
int64 being exactly 64 bit, int32 being exactly 32 bits and int16 being
exactly 16 bits, and making int equivalent to int16, and long being
equivalent to int32?
--
Ioannis Vranos http://www23.brinkster.com/noicys
Ioannis Vranos wrote: Victor Bazarov wrote:
Why? What if 'int' doesn't cut it? What if I need 28 bits? I shouldn't
have to waste time and memory dealing with 64 bit types if it can all be
handled by 32 bits.
OK I can understand such a need.In the case of extensions in the type
system, the approach taken should be extensible.
Leaving C aside since it is a different language, what about introducing
int64 being exactly 64 bit, int32 being exactly 32 bits and int16 being
exactly 16 bits, and making int equivalent to int16, and long being
equivalent to int32?
What about them? I am fairly certain the work either has been started on
those and a proposal is already there waiting for the next major Standard
release, or work is being performed on a proposal. Ask in comp.std.c++
if you are interested.
V
Victor Bazarov wrote: What about them? I am fairly certain the work either has been started on
those and a proposal is already there waiting for the next major Standard
release, or work is being performed on a proposal. Ask in comp.std.c++
if you are interested.
I am not talking about long long, int64_t etc crap but for built in types.
--
Ioannis Vranos http://www23.brinkster.com/noicys
Ioannis Vranos wrote: Victor Bazarov wrote:
What about them? I am fairly certain the work either has been started on
those and a proposal is already there waiting for the next major Standard
release, or work is being performed on a proposal. Ask in comp.std.c++
if you are interested.
I am not talking about long long, int64_t etc crap but for built in types.
If there were no need for built-in types of specific sizes before, I do
not think there is a need for them now. But that's just my opinion. If
yours is different, state it and give some background. Why do you think
they should be built-in instead of, say, typedef'ed? What's the advantage
of having N new keywords instead of N new types in the 'std' namespace?
And if you think you have enough for a convincing argument, why don't you
go to comp.std.c++ and post a proposal?
V
Victor Bazarov wrote: If there were no need for built-in types of specific sizes before, I do
not think there is a need for them now. But that's just my opinion. If
yours is different, state it and give some background. Why do you think
they should be built-in instead of, say, typedef'ed? What's the advantage
of having N new keywords instead of N new types in the 'std' namespace?
And if you think you have enough for a convincing argument, why don't you
go to comp.std.c++ and post a proposal?
I have already posted a proposal in both c.l.c++.m. and c.std.c++.
About the typedefs, why would "exotic" (not corresponding to built in
types) integral typedefs be better than built in integer types?
--
Ioannis Vranos http://www23.brinkster.com/noicys
Ioannis Vranos wrote: Victor Bazarov wrote:
If there were no need for built-in types of specific sizes before, I do
not think there is a need for them now. But that's just my opinion. If
yours is different, state it and give some background. Why do you think
they should be built-in instead of, say, typedef'ed? What's the
advantage
of having N new keywords instead of N new types in the 'std' namespace?
And if you think you have enough for a convincing argument, why don't you
go to comp.std.c++ and post a proposal?
I have already posted a proposal in both c.l.c++.m. and c.std.c++.
About the typedefs, why would "exotic" (not corresponding to built in
types) integral typedefs be better than built in integer types?
Because built-in types require new keywords. Adding new keywords to
an existing language is _always_ problematic. Just take C's "_Bool"
as an example of the ugliness that ensues.
V
Victor Bazarov wrote: Because built-in types require new keywords. Adding new keywords to
an existing language is _always_ problematic. Just take C's "_Bool"
as an example of the ugliness that ensues.
I do not agree with Cs extension approach. bool would be sufficient and
codifies pre-existing practice.
Also many compilers already use long long. If it is accepted for C++0x,
should it be introduced as __Long long?
--
Ioannis Vranos http://www23.brinkster.com/noicys
Ioannis Vranos wrote: Victor Bazarov wrote:
Because built-in types require new keywords. Adding new keywords to
an existing language is _always_ problematic. Just take C's "_Bool"
as an example of the ugliness that ensues.
I do not agree with Cs extension approach. bool would be sufficient and
codifies pre-existing practice.
Well, I don't mean to be rude, but who cares that you don't agree? It
is not up for discussion, when C is concerned.
Also many compilers already use long long. If it is accepted for C++0x,
should it be introduced as __Long long?
You again are missing the point. 'long long' is not an introduction of
a new keyword, it's a correction in the grammar. However, int64 or
any other name that you can come up with for a fixed-size type would be
an introduction of a new keyword. Do you propose to have 'long char' or
'short char' to designate 32-bit or 8-bit types?
V
Victor Bazarov wrote: You again are missing the point. 'long long' is not an introduction of
a new keyword, it's a correction in the grammar.
?It is a new type.
However, int64 or
any other name that you can come up with for a fixed-size type would be
an introduction of a new keyword. Do you propose to have 'long char' or
'short char' to designate 32-bit or 8-bit types?
? No. How did you reach such a conclusion. What I propose is:
int16 is introduced and is an exact 16-bit type (of course additional
padding bits are allowed). int and short become equivalent of it.
That is, signed int16, int16, signed, signed int, int, signed short,
short to be all equivalent. The same for the unsigned equivalents. That
is unsigned int16 to be the same as unsigned int and unsigned, etc.
int32 is introduced and holds exactly 32-bit values. long becomes
another name of it, as was the case with the above.
signed int32, int32, signed long, long are all the same.
int64 is introduced and holds 64-bit values. signed int64 is equivalent
and unsigned int64 is the unsigned type.
So we can say:
int64 x;
int32 *p = new int32[10];
long *pp = p;
etc.
--
Ioannis Vranos http://www23.brinkster.com/noicys
Ioannis Vranos wrote: Victor Bazarov wrote:
You again are missing the point. 'long long' is not an introduction of
a new keyword, it's a correction in the grammar.
?It is a new type.
So? It's not a new keyword. 'long' already exists in the language. It
is just a new use for an old keyword.
However, int64 or
any other name that you can come up with for a fixed-size type would be
an introduction of a new keyword. Do you propose to have 'long char' or
'short char' to designate 32-bit or 8-bit types?
? No. How did you reach such a conclusion. What I propose is:
int16 is introduced
Are you tired today, or perhaps have a headache? 'int16' is a new keyword.
I just told you that introduction of a new keyword is NOT likely to be
accepted.
[...]
Victor Bazarov wrote: Ioannis Vranos wrote: Victor Bazarov wrote:
Because built-in types require new keywords. Adding new keywords to
an existing language is _always_ problematic. Just take C's "_Bool"
as an example of the ugliness that ensues.
I do not agree with Cs extension approach. bool would be sufficient and
codifies pre-existing practice.
Well, I don't mean to be rude, but who cares that you don't agree? It
is not up for discussion, when C is concerned.
Also many compilers already use long long. If it is accepted for C++0x,
should it be introduced as __Long long?
You again are missing the point. 'long long' is not an introduction of
a new keyword, it's a correction in the grammar. However, int64 or
any other name that you can come up with for a fixed-size type would be
an introduction of a new keyword. Do you propose to have 'long char' or
'short char' to designate 32-bit or 8-bit types?
Perhaps
int<64> var;
Etc. No idea if that would present other problems.
Scott
"Timothy Madden" <ba****@rmv.spam.home.ro> wrote in message
news:2r*************@uni-berlin.de... Hello
I've read here that only C language has a standard 64bit integer.
Can you please tell me what are the reasons for this ? What is special
about C language ?
Can you please show me some references to this integer type ? When was it
introduced ?
Can you please tell me why is a new keyword not likely to be accepted ?
And why do people seem to want fixed-sized integer types ?
I want a new type for a 64-bit integer, but I don't want the standard to
impose this limit on
it and I definetly don't want it named int64. In a conforming implementation
short int and long int can actualy be the same. They can actualy be
implemented with chars and the implementation would still be confromant.
I think these existing loose limits on integer types are a good thing and I
don't want the
rule broken just to introduce a new integer type
Thank you
Timothy Madden
Romania
-----------------------------------------------
And I don't wanna miss a thing
In article <2r*************@uni-berlin.de>,
Timothy Madden <ba****@rmv.spam.home.ro> wrote: I've read here that only C language has a standard 64bit integer.
Can you please tell me what are the reasons for this ? What is special about
C language ?
Other language have 64 bits types I'm sure.
C added it for the same reason as some of the others,
machines were coming along which supported it and it was time.
Can you please show me some references to this integer type ?
The intent of 'long long' is to provide 64 bit support,
as a minimum (so for instance, it may support 128 bits too).
When was it introduced ?
Formally with C99. Informally for a real long time.
For instance, most C++ compilers also support it as an extension
even though Standard C++ does not discuss its support for it.
--
Greg Comeau / Comeau C++ 4.3.3, for C++03 core language support
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
In article <t5********************************@4ax.com>,
Jack Klein <ja*******@spamcop.net> wrote: The real question is why the C++ standard, being finalized not too
much before the 1999 major update to the C standard, did not include
the 'long long' type or indeed all of the expansions to the integer
types that C added in 1999.
It seems to me (I don't have the spec in front of me) three overall
issues were/are at hand: is "long long" the best "spelling"/form
for C++, are all the "new" C99 long long related issues acceptable,
is there other alternatives especially in consideration of future
direction. I'm not saying those things could not have been
duked out, just that as often is the case, there is not a
straighforward answer. For instance, I suppose if we wanted to,
we could say this was a real question for C90, or for some C before
C99 too, and the reasons it was not added previously to C
are probably as varied as they are for C++.
--
Greg Comeau / Comeau C++ 4.3.3, for C++03 core language support
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
In article <fC****************@newsread1.dllstx09.us.to.verio .net>,
Victor Bazarov <v.********@comAcast.net> wrote: Ioannis Vranos wrote: Timothy Madden wrote: The real question is why the C++ standard, being finalized not too
much before the 1999 major update to the C standard, did not include
the 'long long' type or indeed all of the expansions to the integer
types that C added in 1999.
I understand now
It's because the new type is named 'long long'.
It is really ugly for a standard type.
They could have just said number, integer, real, numeric, natural or
something ...
Pascal has a special large numeric type named 'comp' for example
(implemented with floats)
Language designers had more imagination it it's case, and nobody asked
why
Or something like int64, etc.
That said, nothing restricts an implementation to provide a long of 64
bits, since long is at least 32 bits. And personally I do not favour the
addition of a new type, since long can do the job.
You're missing the point, probably. Yes, on some platforms 'long int' can
do the job, but adding a new type to the language would ensure that on
_all_ platforms there is something that is at least 64 bits. 'long int'
is only guaranteed to be 32 bits, so we are still facing with some kind of
compatibility problem when porting 64-bit-enabled code from one platform
to another.
I agree there is minimum requirements, but in the end you don't
escape the compatibility for all possibilities, you just change the
landscape. I'm not saying that's inherently bad, but adding
a new type whether 64 bits or min 64 bits is of course not the
only way to ensure you have get 64 bits. Of course, all the
alternatives change the landscape. But we have to agree other
language such as FORTRAN have had syntax like type*N for a long time
and it's a matter of a number of things. I can't imagine that
in the next twenty years we'll have 'long long long' and worse,
not to mention all the extended interger type stuff, conversion
rules, etc. (I know you're not saying any of this, I'm just
speaking out loud a bit.)
--
Greg Comeau / Comeau C++ 4.3.3, for C++03 core language support
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
On Mon, 20 Sep 2004 19:46:08 +0300, Timothy Madden wrote: The real question is why the C++ standard, being finalized not too
much before the 1999 major update to the C standard, did not include
the 'long long' type or indeed all of the expansions to the integer
types that C added in 1999.
I understand now
It's because the new type is named 'long long'.
It is really ugly for a standard type.
They could have just said number, integer, real, numeric, natural or
something ...
When you're making a standard, the most important thing is that everyone
agrees, not that it's the absolute best technical solution that "wins"
(which anyway seems rather subjective).
And standarization is also about bringing already widely used things to
a standard form. long long has been used for a long time by vendors...
Nils O. Selåsdal wrote: When you're making a standard, the most important thing is that everyone
agrees, not that it's the absolute best technical solution that "wins"
(which anyway seems rather subjective).
And standarization is also about bringing already widely used things to
a standard form. long long has been used for a long time by vendors...
As also int64 in various forms. In .NET the type larger than long is
__int64.
--
Ioannis Vranos http://www23.brinkster.com/noicys This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: hostmaster |
last post by:
Hi,
I'm quite new to Python and I am reading this book called 'Core Python
Programming' by Wesley J. Chun. I think that this is not a new book but
I believe some of the points are still valid....
|
by: baustin75 |
last post by:
Posted: Mon Oct 03, 2005 1:41 pm Post subject: cannot mail() in ie
only when debugging in php designer 2005
--------------------------------------------------------------------------------
...
|
by: asm |
last post by:
Hi All,
Like typdef, does C have further support for portability?
Thanks,
ASM
|
by: Randy Yates |
last post by:
In Harbison and Steele's text (fourth edition, p.111)
it is stated,
The C language does not specify the range of integers that the
integral types will represent, except ot say that type int may...
|
by: Doug Lerner |
last post by:
I have this snippet of client side code running:
var makeField = document.forms;
alert("makeFieldName name,length,type=" + makeFieldName + ", " +
makeField.name + "," + makeField.length + ","...
|
by: Xah Lee |
last post by:
in March, i posted a essay âWhat is Expressiveness in a Computer
Languageâ, archived at:
http://xahlee.org/perl-python/what_is_expresiveness.html
I was informed then that there is a academic...
|
by: RoughRyde |
last post by:
Hi all,
I'm totally new to C and hava a problem how to handle different types
of variables.
I have a function which which you call by:
double calcdiff(const char *old, const char *new)
I...
|
by: WaterWalk |
last post by:
I've just read an article "Building Robust System" by Gerald Jay
Sussman. The article is here:
http://swiss.csail.mit.edu/classes/symbolic/spring07/readings/robust-systems.pdf
In it there is a...
|
by: Adem24 |
last post by:
The World Joint Programming Language Standardization Committe (WJPLSC)
hereby proclaims to the people of the world that a new programming language
is needed for the benefit of the whole mankind in...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
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,...
|
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,...
|
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...
|
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...
|
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...
|
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 projectplanning, coding, testing,...
| |
