I'm aware that there is no ANSI (or POSIX, or any standard, to my knowledge)
way of flushing stdin or any other application-level input buffer, but if
anyone knows a hack or a non-portable way to do this, no matter how obscure
or arcane, I'd appreciate it.
30  45740 
Jonathan Neill wrote: I'm aware that there is no ANSI (or POSIX, or any standard, to my knowledge)
way of flushing stdin or any other application-level input buffer, but if
anyone knows a hack or a non-portable way to do this, no matter how obscure
or arcane, I'd appreciate it.
Um...what does it mean, to flush an input buffer?
If you mean you want to read and discard whatever's in the buffer at
a certain time, under POSIX I suppose you could use non-blocking
reads until they come up empty. I don't think standard C has
non-blocking I/O, does it?
If you mean you want to wipe the buffer's memory space, because the
user entered a password or something, I'd avoid using stdin for such
purposes.
--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'g******@cbobk.pbz' | rot13
I agree. In any case, he can try setbuf() to use non-buffered streams.
--
Ricardo
"Jonathan Neill" <TY*******@tyler.net> wrote in
news:vl************@corp.supernews.com on Thu 04 Sep 2003 07:16:14p: I'm aware that there is no ANSI (or POSIX, or any standard, to my
knowledge) way of flushing stdin or any other application-level input
buffer, but if anyone knows a hack or a non-portable way to do this, no
matter how obscure or arcane, I'd appreciate it.
You'd do better asking on a system-specific newsgroup. The geeks there
will know a dozen ways to do this on your specific system (or will know if
it can't be done at all). Here, we deal with Standard C, not any system-
specific extensions to the language. If you have a question about ANSI/ISO
C (up to and including C99, and even including pre-Standard K&R C if you
still need it), this is the best place to ask it. If you want to do
something that is system-specific, ask on a system-specific newsgroup for
the best answers. http://www.eskimo.com/~scs/C-faq/s19.html -- A list of answers to
questions that can't be answered in Standard C. Read the (rest of the) FAQ
for more info.
Jonathan Neill wrote: I'm aware that there is no ANSI (or POSIX, or any standard, to my
knowledge) way of flushing stdin or any other application-level input
buffer, but if anyone knows a hack or a non-portable way to do this, no
matter how obscure or arcane, I'd appreciate it.
What do you mean by "flush"? If you mean that you want to discard the
current character and all subsequent characters until exactly one \n has
been discarded (and this is typically what most people want from a
so-called "flush" of stdin), call this function:
#include <stdio.h>
/* constraint: fp must be open for input */
int fpDrain(FILE *fp)
{
int ch = 0;
while((ch = getc(fp)) != EOF && ch != '\n')
{
continue;
}
return EOF == ch;
}
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Hi,
The problem with non portable solutions is that they tend to be highly
system specific. The solution to the problem must be tailored to the
specifics of the systems where it is intended to be used. Since you
did not describe your system / environment we can not give you a
specific working solution.
For instance there are systems where "fflush(stdin);" actually works
and does what you want (e.g. Microsoft Visual C). Another solution
would indeed be to check your system for a non blocking function to
read from a stream or terminal. To add to the already existant obscure
examples: Microsoft C offers a function called "_kbhit()" to check if
there is pending keyboard input available.
--
Stephan Wilms
"Jonathan Neill" <TY*******@tyler.net> wrote in message news:<vl************@corp.supernews.com>... I'm aware that there is no ANSI (or POSIX, or any standard, to my knowledge)
way of flushing stdin or any other application-level input buffer, but if
anyone knows a hack or a non-portable way to do this, no matter how obscure
or arcane, I'd appreciate it.
Jonathan Neill wrote: I'm aware that there is no ANSI (or POSIX, or any standard, to my knowledge)
way of flushing stdin or any other application-level input buffer, but if
anyone knows a hack or a non-portable way to do this, no matter how obscure
or arcane, I'd appreciate it.
It doesn't even mean anything. Read the description of the action of
fflush() on output streams and try to come up with a reasonable analogy for
input streams.
--
Martin Ambuhl
Jonathan Neill wrote: I'm aware that there is no ANSI (or POSIX, or any standard, to my
knowledge) way of flushing stdin or any other application-level input
buffer, but if anyone knows a hack or a non-portable way to do this, no
matter how obscure or arcane, I'd appreciate it.
What do you mean by "flush"? If you mean that you want to discard the
current character and all subsequent characters until exactly one \n has
been discarded (and this is typically what most people want from a
so-called "flush" of stdin), call this function:
#include <stdio.h>
/* constraint: fp must be open for input */
int fpDrain(FILE *fp)
{
int ch = 0;
while((ch = getc(fp)) != EOF && ch != '\n')
{
continue;
}
return EOF == ch;
}
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Hi,
The problem with non portable solutions is that they tend to be highly
system specific. The solution to the problem must be tailored to the
specifics of the systems where it is intended to be used. Since you
did not describe your system / environment we can not give you a
specific working solution.
For instance there are systems where "fflush(stdin);" actually works
and does what you want (e.g. Microsoft Visual C). Another solution
would indeed be to check your system for a non blocking function to
read from a stream or terminal. To add to the already existant obscure
examples: Microsoft C offers a function called "_kbhit()" to check if
there is pending keyboard input available.
--
Stephan Wilms
"Jonathan Neill" <TY*******@tyler.net> wrote in message news:<vl************@corp.supernews.com>... I'm aware that there is no ANSI (or POSIX, or any standard, to my knowledge)
way of flushing stdin or any other application-level input buffer, but if
anyone knows a hack or a non-portable way to do this, no matter how obscure
or arcane, I'd appreciate it.
Jonathan Neill wrote: I'm aware that there is no ANSI (or POSIX, or any standard, to my knowledge)
way of flushing stdin or any other application-level input buffer, but if
anyone knows a hack or a non-portable way to do this, no matter how obscure
or arcane, I'd appreciate it.
It doesn't even mean anything. Read the description of the action of
fflush() on output streams and try to come up with a reasonable analogy for
input streams.
--
Martin Ambuhl
Stephan Wilms wrote: The problem with non portable solutions is that they tend to be highly
system specific.
<captious>
Really? Gosh. I guess that's why they're non-portable, then?
</captious>
--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'g******@cbobk.pbz' | rot13
Stephan Wilms wrote: The problem with non portable solutions is that they tend to be highly
system specific.
<captious>
Really? Gosh. I guess that's why they're non-portable, then?
</captious>
--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'g******@cbobk.pbz' | rot13
On Fri, 5 Sep 2003 01:16:14 UTC, "Jonathan Neill"
<TY*******@tyler.net> wrote: I'm aware that there is no ANSI (or POSIX, or any standard, to my knowledge)
way of flushing stdin or any other application-level input buffer, but if
anyone knows a hack or a non-portable way to do this, no matter how obscure
or arcane, I'd appreciate it.
100% ANSI compatible:
/* flush stdin */
/* params: */
/* int c int to hold temorary readed char from stdin */
/* */
/* read from stdin until end of file or end of line reached */
#define FLUSHIN(c) while ((c = getc() != EOF && c != '\n')
stdin is commonly line buffered or unbuffered. In both cases reading
until '\n' is dedected is flushing the input stream. Even when stdin
is set to be block buffered (e.g. as pipe or file it makes sense to
"flush". Because stdin is a text stram, so reading until '\n'
syncronises the stream so that the next coming char will be the first
of a line.
--
Tschau/Bye
Herbert
eComStation 1.1 Deutsch Beta ist verügbar
[snips]
On Fri, 05 Sep 2003 02:23:09 +0000, Tom Zych wrote: Jonathan Neill wrote:
I'm aware that there is no ANSI (or POSIX, or any standard, to my knowledge)
way of flushing stdin or any other application-level input buffer, but if
anyone knows a hack or a non-portable way to do this, no matter how obscure
or arcane, I'd appreciate it.
Um...what does it mean, to flush an input buffer?
You're sitting at the keyboard, firing in commands to do this, that, the
other thing. In the process, you inadvertently enter some option which
is potentially dangerous... but you're still merrily typing away, while
the potentially dangerous program is figuring out what to do - you're
queuing up your inputs.
The program, realizing that what you asked for is dangerous, puts up a
prompt "Do you really mean this? y/N" and waits for input. However, since
you've already queued up inputs, it may well see an N (or worse, a Y)
and the results range from annoying to disastrous.
'Course, if the program had flushed input, your queued commands would be
lost... but you wouldn't be feeding an unwanted input into the program at
a critical juncture.
In a GUI system, generally, this would be done with a messagebox and your
typing wouldn't make an iota of difference; in a CLI environment, however,
it can matter.
One frequent solution is to flush input; whether that means reading and
discarding inputs until a strictly valid one is obtained (i.e. fgets and
only accepting a 'Y' or an 'N' by itself, ignoring other typed inputs) or
using some other means, the result is the same: attempting to flush the
input buffer.
"The Real OS/2 Guy" <os****@pc-rosenau.de> wrote:
/* flush stdin */
/* params: */
/* int c int to hold temorary readed char from stdin */
/* */
/* read from stdin until end of file or end of line reached */
#define FLUSHIN(c) while ((c = getc() != EOF && c != '\n')
^
There's a ')' missing here. :)
--
What does this red button do?
Kelsey Bjarnason <ke*****@xxnospamyy.lightspeed.bc.ca> wrote: [snips]
On Fri, 05 Sep 2003 02:23:09 +0000, Tom Zych wrote:
Um...what does it mean, to flush an input buffer?
You're sitting at the keyboard, ...
<SNIP>
I am pretty sure he already knows what (usually) is meant when
people talk about "flushing an input buffer": it is the wrong
term for "draining an input buffer".
Irrwahn.
--
What does this red button do?
On Fri, 5 Sep 2003 01:16:14 UTC, "Jonathan Neill"
<TY*******@tyler.net> wrote: I'm aware that there is no ANSI (or POSIX, or any standard, to my knowledge)
way of flushing stdin or any other application-level input buffer, but if
anyone knows a hack or a non-portable way to do this, no matter how obscure
or arcane, I'd appreciate it.
100% ANSI compatible:
/* flush stdin */
/* params: */
/* int c int to hold temorary readed char from stdin */
/* */
/* read from stdin until end of file or end of line reached */
#define FLUSHIN(c) while ((c = getc() != EOF && c != '\n')
stdin is commonly line buffered or unbuffered. In both cases reading
until '\n' is dedected is flushing the input stream. Even when stdin
is set to be block buffered (e.g. as pipe or file it makes sense to
"flush". Because stdin is a text stram, so reading until '\n'
syncronises the stream so that the next coming char will be the first
of a line.
--
Tschau/Bye
Herbert
eComStation 1.1 Deutsch Beta ist verügbar
[snips]
On Fri, 05 Sep 2003 02:23:09 +0000, Tom Zych wrote: Jonathan Neill wrote:
I'm aware that there is no ANSI (or POSIX, or any standard, to my knowledge)
way of flushing stdin or any other application-level input buffer, but if
anyone knows a hack or a non-portable way to do this, no matter how obscure
or arcane, I'd appreciate it.
Um...what does it mean, to flush an input buffer?
You're sitting at the keyboard, firing in commands to do this, that, the
other thing. In the process, you inadvertently enter some option which
is potentially dangerous... but you're still merrily typing away, while
the potentially dangerous program is figuring out what to do - you're
queuing up your inputs.
The program, realizing that what you asked for is dangerous, puts up a
prompt "Do you really mean this? y/N" and waits for input. However, since
you've already queued up inputs, it may well see an N (or worse, a Y)
and the results range from annoying to disastrous.
'Course, if the program had flushed input, your queued commands would be
lost... but you wouldn't be feeding an unwanted input into the program at
a critical juncture.
In a GUI system, generally, this would be done with a messagebox and your
typing wouldn't make an iota of difference; in a CLI environment, however,
it can matter.
One frequent solution is to flush input; whether that means reading and
discarding inputs until a strictly valid one is obtained (i.e. fgets and
only accepting a 'Y' or an 'N' by itself, ignoring other typed inputs) or
using some other means, the result is the same: attempting to flush the
input buffer.
"The Real OS/2 Guy" <os****@pc-rosenau.de> wrote:
/* flush stdin */
/* params: */
/* int c int to hold temorary readed char from stdin */
/* */
/* read from stdin until end of file or end of line reached */
#define FLUSHIN(c) while ((c = getc() != EOF && c != '\n')
^
There's a ')' missing here. :)
--
What does this red button do?
Kelsey Bjarnason <ke*****@xxnospamyy.lightspeed.bc.ca> wrote: [snips]
On Fri, 05 Sep 2003 02:23:09 +0000, Tom Zych wrote:
Um...what does it mean, to flush an input buffer?
You're sitting at the keyboard, ...
<SNIP>
I am pretty sure he already knows what (usually) is meant when
people talk about "flushing an input buffer": it is the wrong
term for "draining an input buffer".
Irrwahn.
--
What does this red button do?
Kelsey Bjarnason wrote: The program, realizing that what you asked for is dangerous, puts up a
prompt "Do you really mean this? y/N" and waits for input. However, since
you've already queued up inputs, it may well see an N (or worse, a Y)
and the results range from annoying to disastrous.
<snip>
One frequent solution is to flush input; whether that means reading and
discarding inputs until a strictly valid one is obtained (i.e. fgets and
only accepting a 'Y' or an 'N' by itself, ignoring other typed inputs) or
using some other means, the result is the same: attempting to flush the
input buffer.
Ah, yes. I've noticed that problem and some programs that cope with
it. Never thought of it as "flushing" since that has an entirely
different meaning for output. I think Irrwahn's "draining", or
perhaps "clearing", would be better.
I don't see a good way to do it without non-blocking reads. With
them, of course, it's easy.
--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'g******@cbobk.pbz' | rot13
The Real OS/2 Guy wrote: stdin is commonly line buffered or unbuffered. In both cases reading
until '\n' is dedected is flushing the input stream. Even when stdin
is set to be block buffered (e.g. as pipe or file it makes sense to
"flush". Because stdin is a text stram, so reading until '\n'
syncronises the stream so that the next coming char will be the first
of a line.
If that's the behavior you want, ok. But another poster pointed out
that one use is to clear the buffer of *all* input, for example, if
the program is asking if you want to do something dangerous. You
wouldn't want it to accept the first character that happens to be in
the input stream in that case.
--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'g******@cbobk.pbz' | rot13
Kelsey Bjarnason wrote: The program, realizing that what you asked for is dangerous, puts up a
prompt "Do you really mean this? y/N" and waits for input. However, since
you've already queued up inputs, it may well see an N (or worse, a Y)
and the results range from annoying to disastrous.
<snip>
One frequent solution is to flush input; whether that means reading and
discarding inputs until a strictly valid one is obtained (i.e. fgets and
only accepting a 'Y' or an 'N' by itself, ignoring other typed inputs) or
using some other means, the result is the same: attempting to flush the
input buffer.
Ah, yes. I've noticed that problem and some programs that cope with
it. Never thought of it as "flushing" since that has an entirely
different meaning for output. I think Irrwahn's "draining", or
perhaps "clearing", would be better.
I don't see a good way to do it without non-blocking reads. With
them, of course, it's easy.
--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'g******@cbobk.pbz' | rot13
The Real OS/2 Guy wrote: stdin is commonly line buffered or unbuffered. In both cases reading
until '\n' is dedected is flushing the input stream. Even when stdin
is set to be block buffered (e.g. as pipe or file it makes sense to
"flush". Because stdin is a text stram, so reading until '\n'
syncronises the stream so that the next coming char will be the first
of a line.
If that's the behavior you want, ok. But another poster pointed out
that one use is to clear the buffer of *all* input, for example, if
the program is asking if you want to do something dangerous. You
wouldn't want it to accept the first character that happens to be in
the input stream in that case.
--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'g******@cbobk.pbz' | rot13
Tom Zych wrote:
The Real OS/2 Guy wrote:
stdin is commonly line buffered or unbuffered. In both cases reading
until '\n' is dedected is flushing the input stream. Even when stdin
is set to be block buffered (e.g. as pipe or file it makes sense to
"flush". Because stdin is a text stram, so reading until '\n'
syncronises the stream so that the next coming char will be the first
of a line.
If that's the behavior you want, ok. But another poster pointed out
that one use is to clear the buffer of *all* input, for example, if
the program is asking if you want to do something dangerous. You
wouldn't want it to accept the first character that happens to be in
the input stream in that case.
Don't take this personally, but the point of having an input stream is
to be able to 'read' it. Do that! Determine whether what you read was
dangerous or useful and do the 'wright' thing. It is your program after
all that allows input in the first place. The very least you can do is
'listen' to your user. Having read the input it is always within your
power to ignore it. I see no case for fflush(stdin) or similar.
--
Joe Wright mailto:jo********@earthlink.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Joe Wright wrote: Tom Zych wrote:
If that's the behavior you want, ok. But another poster pointed out
that one use is to clear the buffer of *all* input, for example, if
the program is asking if you want to do something dangerous. You
wouldn't want it to accept the first character that happens to be in
the input stream in that case.
Don't take this personally, but the point of having an input stream is
to be able to 'read' it. Do that! Determine whether what you read was
dangerous or useful and do the 'wright' thing. It is your program after
all that allows input in the first place. The very least you can do is
'listen' to your user. Having read the input it is always within your
power to ignore it. I see no case for fflush(stdin) or similar.
I'm not sure you understood me. Did you read Kelsey Bjarnason's
posting?
--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'g******@cbobk.pbz' | rot13
On Sun, 7 Sep 2003 02:29:50 UTC, Joe Wright <jo********@earthlink.net>
wrote: Tom Zych wrote:
The Real OS/2 Guy wrote:
stdin is commonly line buffered or unbuffered. In both cases reading
until '\n' is dedected is flushing the input stream. Even when stdin
is set to be block buffered (e.g. as pipe or file it makes sense to
"flush". Because stdin is a text stram, so reading until '\n'
syncronises the stream so that the next coming char will be the first
of a line.
If that's the behavior you want, ok. But another poster pointed out
that one use is to clear the buffer of *all* input, for example, if
the program is asking if you want to do something dangerous. You
wouldn't want it to accept the first character that happens to be in
the input stream in that case.
Don't take this personally, but the point of having an input stream is
to be able to 'read' it. Do that! Determine whether what you read was
dangerous or useful and do the 'wright' thing. It is your program after
all that allows input in the first place. The very least you can do is
'listen' to your user. Having read the input it is always within your
power to ignore it. I see no case for fflush(stdin) or similar.
You gave the wrong answer.
#define EPMPTYIN while (getc() != EOF) ;
will flush the whole stream. If the stream is not a file it will wait
until the user closes it (e.g. Ctrl. C or CTRL D). If it is a file it
would be readed completely.
But in both cases it would be more easy simply to fclose() it.
Flushing an inputstream is commonly used to syncronise the stream to a
point a logical record/field starts. As it is mostenly impossible to
find the next logical field after something wrong comes in it is more
secure to syncronise to the begin of the next record. So reading
anything until '\n' occures means that one has a clean start point
again.
When your stream has another char's words that defined as syncronison
point you may extend the FLUSHIN macro to find them. But as this
exeeds the work
--
Tschau/Bye
Herbert
eComStation 1.1 Deutsch Beta ist verügbar
>On Fri, 05 Sep 2003 02:23:09 +0000, Tom Zych wrote: Um...what does it mean, to flush an input buffer?
The word "flush" comes from the Middle English "flusshen", meaning
"to take wing" or "to fly up suddenly". (Birds do this in groups
when startled.) This meaning persists today in the phrase "flush
out": things that are hidden can be flushed, chased out of their
concealment for all to see. This is what fflush() does.
Flushing an input buffer, then, would expose its contents to
view -- which is not really all that useful. :-)
I suspect what is really wanted is more like a "purge". The BSDs
have an fpurge() function that does this (for both input AND output,
since it has sensible applications in both cases).
In article <pa****************************@xxnospamyy.lightsp eed.bc.ca>
Kelsey Bjarnason <ke*****@xxnospamyy.lightspeed.bc.ca> writes:You're sitting at the keyboard, firing in commands to do this, that, the
other thing. In the process, you inadvertently enter some option which
is potentially dangerous... but you're still merrily typing away, while
the potentially dangerous program is figuring out what to do - you're
queuing up your inputs.
The program, realizing that what you asked for is dangerous, puts up a
prompt "Do you really mean this? y/N" and waits for input. However, since
you've already queued up inputs, it may well see an N (or worse, a Y)
and the results range from annoying to disastrous.
'Course, if the program had flushed input,
(presumably you mean "purged" input :-) -- but we might simply
redefine "flush" to mean "discard", except when it applies to
output, which is not discarded at all...)
your queued commands would be
lost... but you wouldn't be feeding an unwanted input into the program at
a critical juncture.
There is a technical problem here (with a technical but currently
unimplementable solution). Suppose you are sitting at the keyboard
in Australia, typing into the machine located in Vancouver BC, over
a lossy or satellite-based Internet connection with huge latency.
You are "firing in commands" at time T, T+1, T+2, T+3, and so on,
but the transmission to the remote system is rather "lumpy" so that
they arrive there at time T+2, T+6, T+6, T+6, T+9, T+11, T+11, and
so on.
The "dangerous" operation occurs at time T+5 and arrives at the
remote system at time T+9. By then, of course, even more input is
queued at the source (Australia).
Meanwhile, the program prints "do you really mean this" at T+9 and
tries to purge typeahead. The message "do you really mean this"
arrives in Australia at T+11 or so. What input is discarded?
The problem is that the input, output, and flush/purge/whateveryoucallit
operations are not synchronized -- and without some sort of embedded
timing information (or external protocol), they cannot even *be*
synchronized. So fpurge(), while useful, is still quite limited.
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.
Chris Torek wrote: On Fri, 05 Sep 2003 02:23:09 +0000, Tom Zych wrote: Um...what does it mean, to flush an input buffer?
I suspect what is really wanted is more like a "purge".
I like the word "drain", for that action.
--
pete This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Johnathan Doe |
last post by:
I'm trying to find a way to reliably peek at stdin, and if anything's
waiting, flush stdin so that it clears the stream ready to wait for a
character.
The problem I have is that in an...
|
by: Darklight |
last post by:
is this correct or incorrect i just read the post below before posting
this: In fflush(stdin), what happens to flushed data?
this program is taken from sams teach yourself c in 21 days
/*...
|
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: 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: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
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: 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...
| |
