Hi
Can anyone explain why the output of the following code:
#define A 1
#define B 2
A.B
after preprocessing only, is:
1 . 2
Why does the preprocessor put spaces between each character, when the
macro invocation has none?
Regards, B 24 1705 bo*******@gmail.com wrote:
Hi
Can anyone explain why the output of the following code:
#define A 1
#define B 2
A.B
after preprocessing only, is:
1 . 2
Why does the preprocessor put spaces between each character, when the
macro invocation has none?
The preprocessor is often -- and incorrectly -- said to
operate on the text of the program's source code. In fact,
it operates on tokens (formally, "preprocessing tokens")
that have been derived from the text. These tokens simply
come one after another, pretty maids all in a row; they do
not need to be separated by spaces. Equally, though, they
do not magically combine with each other just because they
happen to be adjacent.
So: By the time the sample code reaches the preprocessor,
it has been divided into three tokens which we may represent as
A bo*******@gmail.com wrote:
>
Can anyone explain why the output of the following code:
#define A 1
#define B 2
A.B
after preprocessing only, is:
1 . 2
Why does the preprocessor put spaces between each character, when
the macro invocation has none?
Because that is specified by the C standard. As a purely practical
matter, it keeps individual words separated in macros.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com bo*******@gmail.com wrote:
>
Hi
Can anyone explain why the output of the following code:
#define A 1
#define B 2
A.B
after preprocessing only, is:
1 . 2
Why does the preprocessor put spaces between each character, when the
macro invocation has none?
Why did you put a dot in between A and B?
What should AB mean?
--
pete
Eric Sosman <es*****@ieee-dot-org.invalidwrites:
bo*******@gmail.com wrote:
>Hi Can anyone explain why the output of the following code: #define A 1 #define B 2 A.B after preprocessing only, is: 1 . 2 Why does the preprocessor put spaces between each character, when the macro invocation has none?
The preprocessor is often -- and incorrectly -- said to
operate on the text of the program's source code. In fact,
it operates on tokens (formally, "preprocessing tokens")
that have been derived from the text. These tokens simply
come one after another, pretty maids all in a row; they do
not need to be separated by spaces. Equally, though, they
do not magically combine with each other just because they
happen to be adjacent.
[...]
Quite correct.
However, some preprocessors are *implemented* as text-to-text
translators; they take input text, analyze it as a sequence of
preprocessor tokens, and generate output text that is then analyzed by
later compiler phases a a sequence of tokens.
In this case, the preprocessor implementation inserts blanks between
'1', '.', and '2' precisely so that the next phase will see them as
distinct tokens, rather than as a single token '1.2' (a floating
constant).
The fact that the preprocessor implementation allows you to see its
output is just an extra feature, not required by the language. It
could just as correctly have produced a sequence of tokens in some
binary form, as long as the next compilation phase is able to
interpret that form as tokens.
(Historically, of course, the preprocessor was a separate program that
did text processing, as it still is in some implementations. This
stuff about "preprocessor tokens" and "tokens" is a formalization of
what it does; text-to-text processing is now just one way to implement
that formalized process.)
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
On Aug 23, 12:01 pm, CBFalconer <cbfalco...@yahoo.comwrote:
Because that is specified by the C standard.
Care to quote which part?
regards, B bo*******@gmail.com wrote:
Hi
Can anyone explain why the output of the following code:
#define A 1
#define B 2
A.B
after preprocessing only, is:
1 . 2
Why does the preprocessor put spaces between each character, when the
macro invocation has none?
Regards, B
may be you want this:
A##.##B /* No dots will be */
On 23 août, 08:39, Ivan Gotovchits <ivan.gotovch...@auriga.ruwrote:
boroph...@gmail.com wrote:
Hi
Can anyone explain why the output of the following code:
#define A 1
#define B 2
A.B
after preprocessing only, is:
1 . 2
Why does the preprocessor put spaces between each character, when the
macro invocation has none?
Regards, B
may be you want this:
A##.##B /* No dots will be */
This doesn't work and gives 1##.##2
#define AB(a,b) AB_(a,b)
#define AB_(a,b) a ## . ## b
AB(A,B) -1.2
a+, ld.
Are the # and ## operators only allowed within a macro definition?
B. bo*******@gmail.com wrote:
>
Hi
Can anyone explain why the output of the following code:
#define A 1
#define B 2
A.B
after preprocessing only, is:
1 . 2
Why does the preprocessor put spaces between each character, when the
macro invocation has none?
Strange... My compiler's preprocessor outputs "1.B". (No spaces,
but it failed to expand "B".) Is it broken?
Note that it does replace "A->B" with "1->2", which is why I may not
have noticed this before. I do have code with macros for struct
entries, but they're probably all within pointers.
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
Kenneth Brody <ke******@spamcop.netwrites:
bo*******@gmail.com wrote:
>Can anyone explain why the output of the following code:
#define A 1 #define B 2 A.B
after preprocessing only, is:
1 . 2
Why does the preprocessor put spaces between each character, when the macro invocation has none?
Strange... My compiler's preprocessor outputs "1.B". (No spaces,
but it failed to expand "B".) Is it broken?
Probably, but it's hard to be certain by looking at the output of the
preprocessor, which is normally internal to the compiler. The token
sequence 1 . 2 can't appear in a legal program; if the behavior
doesn't affect any legal programs, and doesn't cause the compiler to
fail to issue a diagnostic for some program with a syntax error or
constraint violation, then strictly speaking it's not a bug as far as
the C standard is concerned. (If your preprocessor has an additional
requirement to generate textual output, it may be a bug if it doesn't
meet that requirement correctly.)
Try the following program. It should print "ok".
#define A a
#define B b
int main(void)
{
struct { int b; } a;
a.b = 42;
if (A.B == 42) {
puts("ok");
}
else {
puts("bug");
}
return 0;
}
But here A and B expand to identifiers, not integer constants, so if
there is a bug this may not trigger it.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
CBFalconer wrote:
bo*******@gmail.com wrote:
>> Can anyone explain why the output of the following code:
#define A 1 #define B 2 A.B
after preprocessing only, is:
1 . 2
Why does the preprocessor put spaces between each character, when the macro invocation has none?
Because that is specified by the C standard.
The C standard does not require or even acknowledge any externally visible
intermediate forms between translation phases.
Kenneth Brody wrote:
bo*******@gmail.com wrote:
>Hi
Can anyone explain why the output of the following code:
#define A 1 #define B 2 A.B
after preprocessing only, is:
1 . 2
Why does the preprocessor put spaces between each character, when the macro invocation has none?
Strange... My compiler's preprocessor outputs "1.B". (No spaces,
but it failed to expand "B".) Is it broken?
No. The only required output is a diagnostic; anything
else is outside the scope of the Standard, hence not "broken"
by appeal to the Standard's requirements.
--
Eric Sosman es*****@ieee-dot-org.invalid
I've just noted another funny thing. Why does
#define A stdio
#define B h
A.B
produce stdio.h and not stdio . h? Would it not see these as three
individual tokens just as in the 1 . 2 example? Why does it combine
them in this instance and not the other? I suspect it is because
there is no ambiguity with stdio.h, which cannot possibly be confused
as a single token in the main compilation phase, whereas 1.2 can??
regards, B. bo*******@gmail.com writes:
I've just noted another funny thing. Why does
#define A stdio
#define B h
A.B
produce stdio.h and not stdio . h? Would it not see these as three
individual tokens just as in the 1 . 2 example? Why does it combine
them in this instance and not the other? I suspect it is because
there is no ambiguity with stdio.h, which cannot possibly be confused
as a single token in the main compilation phase, whereas 1.2 can??
Once again, the preprocessor (as far as the standard is concerned)
produces a sequence of tokens that are processed by later compilation
phases. The standard doesn't specify how this sequence of tokens is
represented.
One common implementation (but not the only one) is for the
preprocessor to generate text as output, and for the later compiler
phases to parse the preprocessor's output just as if it were C source
code (i.e., if the preprocessor's input is legal C, its output is also
legal C). In that representation,
stdio.h
and
stdio . h
are exactly equivalent. But given
#define A 1
#define B 2
A.B
the outputs
1.2
and
1 . 2
are different (one token vs. three), so a text-based preprocessor has
to insert blanks to ensure that later compiler phases see the correct
token sequences.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Kenneth Brody wrote:
[...]
#define A 1
#define B 2
A.B
[...]
Strange... My compiler's preprocessor outputs "1.B". (No spaces,
but it failed to expand "B".) Is it broken?
Stranger still. Given:
#define A 111
#define B 222
#define C foo
A.B
C.B
This expands:
A.B --111.B
C.B --foo.222
(In case anyone cares, this is MSVC 6.0a, aka "version 12.00.8804
for 80x86". I have other compilers on other systems, but this is
the one I'm in front of for the nonce.)
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
Kenneth Brody <ke******@spamcop.netwrites:
Kenneth Brody wrote:
[...]
#define A 1
#define B 2
A.B
[...]
>Strange... My compiler's preprocessor outputs "1.B". (No spaces, but it failed to expand "B".) Is it broken?
Stranger still. Given:
#define A 111
#define B 222
#define C foo
A.B
C.B
This expands:
A.B --111.B
C.B --foo.222
(In case anyone cares, this is MSVC 6.0a, aka "version 12.00.8804
for 80x86". I have other compilers on other systems, but this is
the one I'm in front of for the nonce.)
Interesting. As far as I can tell, we have yet to see a case where
the unexpected preprocessor output can affect the legality of a
program. Perhaps the preprocessor is clever enough to give up in
cases where it knows that its output is going to be syntactically
illegal.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Kenneth Brody wrote:
bo*******@gmail.com wrote:
>Can anyone explain why the output of the following code:
#define A 1 #define B 2 A.B
after preprocessing only, is:
1 . 2
Why does the preprocessor put spaces between each character, when the macro invocation has none?
Strange... My compiler's preprocessor outputs "1.B". (No spaces,
but it failed to expand "B".) Is it broken?
Your compiler is broken. What is it?
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
Keith Thompson wrote:
Eric Sosman <es*****@ieee-dot-org.invalidwrites:
.... snip ...
>> The preprocessor is often -- and incorrectly -- said to operate on the text of the program's source code. In fact, it operates on tokens (formally, "preprocessing tokens") that have been derived from the text. These tokens simply come one after another, pretty maids all in a row; they do not need to be separated by spaces. Equally, though, they do not magically combine with each other just because they happen to be adjacent.
[...]
Quite correct.
This sounds as if you are agreeing, which I trust is not so. The
point is that the tokens may be alphabetical (or numeric) strings,
and need to remain separated. For example:
#define foo((a), (b)) (a) (b)
....
foo(sizeof, char) ---sizeof char
or ...sizeofchar
which have much different meanings.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
CBFalconer <cb********@yahoo.comwrites:
Keith Thompson wrote:
>Eric Sosman <es*****@ieee-dot-org.invalidwrites:
... snip ...
>>> The preprocessor is often -- and incorrectly -- said to operate on the text of the program's source code. In fact, it operates on tokens (formally, "preprocessing tokens") that have been derived from the text. These tokens simply come one after another, pretty maids all in a row; they do not need to be separated by spaces. Equally, though, they do not magically combine with each other just because they happen to be adjacent.
[...]
Quite correct.
This sounds as if you are agreeing, which I trust is not so. The
point is that the tokens may be alphabetical (or numeric) strings,
and need to remain separated. For example:
#define foo((a), (b)) (a) (b)
....
foo(sizeof, char) ---sizeof char
or ...sizeofchar
which have much different meanings.
Yes, I agree with Eric. The preprocessor's output is a stream of
tokens; the standard says nothing about how those tokens are
represented. If the output is text to be interpreted as C source,
then certain tokens do need to be separated by whitespace so they'll
be interpreted as separate tokens. If the output is in some binary
form, or if the interface to the preprocess is a get_next_token()
function, then there is no such separation is necessary (and it may
not be meaningful).
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
CBFalconer <cb********@yahoo.comwrites:
Kenneth Brody wrote:
>bo*******@gmail.com wrote:
>>Can anyone explain why the output of the following code:
#define A 1 #define B 2 A.B
after preprocessing only, is:
1 . 2
Why does the preprocessor put spaces between each character, when the macro invocation has none?
Strange... My compiler's preprocessor outputs "1.B". (No spaces, but it failed to expand "B".) Is it broken?
Your compiler is broken. What is it?
We can't be sure the compiler is broken unless we see an example where
the preprocessor misbehaves in a way that either (a) causes a legal
program to be rejected, (b) changes the semantics of a legal program,
or (c) prevents a syntax error or constraint violation from being
diagnosed. If the preprocessor's input is illegal, and its output is
illegal but in a different way, that's not necessarily a bug.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson wrote:
>
CBFalconer <cb********@yahoo.comwrites:
Kenneth Brody wrote:
bo*******@gmail.com wrote: Can anyone explain why the output of the following code:
#define A 1 #define B 2 A.B
[...]
Strange... My compiler's preprocessor outputs "1.B". (No spaces,
but it failed to expand "B".) Is it broken?
Your compiler is broken. What is it?
We can't be sure the compiler is broken unless we see an example where
the preprocessor misbehaves in a way that either (a) causes a legal
program to be rejected, (b) changes the semantics of a legal program,
or (c) prevents a syntax error or constraint violation from being
diagnosed. If the preprocessor's input is illegal, and its output is
illegal but in a different way, that's not necessarily a bug.
This program fails to compile:
==========
#define A 1
#define B 2
#define MYNUM A.B
float foo(void)
{
return MYNUM;
}
float bar(void)
{
return A.B;
}
==========
foo() compiles just fine, returning the float value 1.2, whereas
bar() fails to compile, with:
syntax error : 'constant'
on the "return A.B" line. (Asking the compiler to show the output
of the preprocessor shows that MYNUM expands to "1.2", whereas "A.B"
expands to "1.B".)
Is this one of those cases where you need an extra layer of macro,
like you do with stringifying things?
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
>Keith Thompson wrote:
>We can't be sure the compiler is broken unless we see an example where the preprocessor misbehaves in a way that either (a) causes a legal program to be rejected, (b) changes the semantics of a legal program, or (c) prevents a syntax error or constraint violation from being diagnosed. If the preprocessor's input is illegal, and its output is illegal but in a different way, that's not necessarily a bug.
In article <46***************@spamcop.net>
Kenneth Brody <ke******@spamcop.netwrote:
>This program fails to compile:
========== #define A 1 #define B 2 #define MYNUM A.B
float foo(void)
{
return MYNUM;
}
float bar(void)
{
return A.B;
} ==========
It should, in fact, fail to compile -- or more precisely, it must
"draw a diagnostic", after which pretty much anything can happen.
The problem is (and here "tokens" are represented by surrounding
them with angle brackets, <like<so>) that the required token-stream
after the preprocessing phases of compilation are complete, when
the normal syntax and semantic rules of C take over, begins with:
<float<foo<(<void>
<)<{<return<1>
<.<2<;<}>
In other words, the thing after "return" is not <1.2>-the-number,
but rather the three separate tokens <1>, <.>, and <2>, which
attempts to apply the "." operator to the number 1 and the
(not-)member-name 2.
Equivalently, you might as well have written:
return 1 . 2;
or even:
return 1/**/./**/2;
The latter used to work in the 1980s, in pre-ANSI K&R compilers --
but only in some of them, not all: some actually obeyed what K&R
said about the language in the original White Book.
>foo() compiles just fine, returning the float value 1.2, whereas bar() fails to compile, with:
syntax error : 'constant'
on the "return A.B" line.
This suggests (but does not prove) that the compiler can be shown
to be incorrect by removing function bar(), after which the one
required diagnostic will not occur.
>Is this one of those cases where you need an extra layer of macro, like you do with stringifying things?
If you want to use A.B to make MYNUM to expand to the token <1.2>,
yes -- you would have to apply the token-pasting "##" operator:
#define A 1
#define B 2
#define PASTE_DOT(x, y) x ## . ## y
#define PASTE_EXPAND_DOT(x, y) PASTE_DOT(x, y)
#define MYNUM PASTE_EXPAND_DOT(A, B)
will do the trick.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Chris Torek wrote:
[...]
In article <46***************@spamcop.net>
Kenneth Brody <ke******@spamcop.netwrote:
This program fails to compile:
==========
#define A 1
#define B 2
#define MYNUM A.B
float foo(void)
{
return MYNUM;
}
float bar(void)
{
return A.B;
}
==========
It should, in fact, fail to compile -- or more precisely, it must
"draw a diagnostic", after which pretty much anything can happen.
The problem is (and here "tokens" are represented by surrounding
them with angle brackets, <like<so>) that the required token-stream
after the preprocessing phases of compilation are complete, when
the normal syntax and semantic rules of C take over, begins with:
<float<foo<(<void>
<)<{<return<1>
<.<2<;<}>
[...]
Okay, I understand the subtle distinction.
The question now becomes:
Is it valid to interpret the input sequence:
return A.B;
as:
<return<1<.<B<;>
instead of:
<return<1<.<2<;>
While neither <1><.><2nor <1><.><Bis valid here, is the compiler
allowed to not expand B?
Note that, at this point, it's acedemic, as I don't believe I've ever
used such a construct on numeric literals, and I'm just curious about
this particular aspect of this particular compiler. (Did they really
include a "this is not valid, so I don't need to continue expanding
the macro" feature into the preprocessor?)
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
"Kenneth Brody" <ke******@spamcop.netwrote in message
news:46***************@spamcop.net...
[...]
Note that, at this point, it's acedemic, as I don't believe I've ever
used such a construct on numeric literals, and I'm just curious about
this particular aspect of this particular compiler. (Did they really
include a "this is not valid, so I don't need to continue expanding
the macro" feature into the preprocessor?)
Well, the pre-processor expands some crazy stuff: http://groups.google.com/group/comp....382dc9a40439c7
Like I said... Crazy! This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Chris Reedy |
last post by:
For everyone -
Apologies for the length of this message. If you don't want to look
at the long example, you can skip to the end of the message.
And for the Python gurus among you, if you can...
|
by: mike420 |
last post by:
I think everyone who used Python will agree that its syntax is
the best thing going for it. It is very readable and easy
for everyone to learn. But, Python does not a have very good
macro...
|
by: mike420 |
last post by:
Tayss wrote:
>
> app = wxPySimpleApp()
> frame = MainWindow(None, -1, "A window")
> frame.Show(True)
> app.MainLoop()
>
Why do you need a macro for that? Why don't you just write
|
by: michele.simionato |
last post by:
Paul Rubin wrote:
> How about macros? Some pretty horrible things have been done in C
> programs with the C preprocessor. But there's a movememnt afloat to
> add hygienic macros to Python. Got any...
|
by: Michael Winter |
last post by:
In a recent post ("About C error" by Victor, 21 Sep 2003), comments were
made about the poster's use of macros. What I would like to know is why
they are considered bad? I'm not referring to...
|
by: Ben Hetland |
last post by:
....in certain cituations they can be useful if not for anything else,
then at least for saving a lot of repetetetetetitititive typing. :-)
Beyond the point of "do something better instead", I'm...
|
by: Stephen Sprunk |
last post by:
On a project I'm working on, I ran across the following macros:
/* assume s is struct stream *, s->p is char, v is unit16_t or uint32_t */
#define in_uint16_le(s,v) { v = *((s)->p++); v +=...
|
by: Emil |
last post by:
Is there any hope that new versions of PHP
will support macros similar to C or C++?
I've searched manual and didn't find anything
except define directive, but it can be used
to define constant...
|
by: San |
last post by:
hi there,
I am new to c++ and tryig to learn the basics of the c++ concepts.
While I was reading the templates, I realize that the templates are a
syntax that the compilar expands pased upon the...
|
by: Robert Seacord |
last post by:
When writing C99 code is a reasonable recommendation to use inline
functions instead of macros?
What sort of things is it still reasonable to do using macros? For
example, is it reasonable to...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
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: 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: 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...
| |