473,465 Members | 1,917 Online
Bytes | Software Development & Data Engineering Community
Create Post

Home Posts Topics Members FAQ

Asking if elements in struct arre zero

If I have:

struct one_{
unsigned int one_1;
unsigned short one_2;
unsigned short one_3;
};

struct two_{
unsigned int two_1;
unsigned short two_2;
unsigned char two_3;
};

struct mystruct{
struct one_ one;
struct two_ two;
}mystruct1;

Then could I by any change ask on the value of the whole struct mystruct1,
that is all the elements in the struct in one call? I want to do something
like (in pseudo like language):

if(mystruct1 == 0) { print("All elements of mystruct1 is zero");}
Best Regards
Terry
Nov 13 '05
258 8348
te*********@BUSThotmailE.Rcom wrote:
Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:
It requires giving attention to mark-up or layout that doesn't exist in
plain text messages, and therefore requires more energy.
Pure FUD. Do you work or have you worked for Microsoft?


Don't try to be personally insulting, it doesn't work in your case.

In any case, if I were, I'd be vehemently arguing _for_ the inclusion of
HTML, VBScript, Sheesh, .dot.net..., and goodness knows what else these
days, in Usenet, e-mail, the 'web, and by preference your e-toaster as
well.
Perhaps _you_ work for M$?
There is no reason for you to pay any attention to such things if you
don't want to...you are perfectly able to write in plain text if you so
choose.


I'm not talking about writing, I'm talking about reading. I don't care
how much you try to ignore the markup, you _will_ perceive that some
text has a different layout than some other text, and this _will_
require mental effort, however little.
<body bgcolor=fuchsia text=lime>
<h1><blink>OH YEAH? GOSH, FaNcY ThAt!</blink></h1>
</body>


And I would just skip over your message and would place you in my kill
file for being overtly and unnecessarily obnoxious.

So, what's your point?


My point is that pretty soon, half the world would be in my killfile.

Come to think of it, that might not be so bad, for the same reasons that
not being able to see Flash websites has turned out to be a blessing.

Richard
Nov 13 '05 #251
Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:
te*********@BUSThotmailE.Rcom wrote:
Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:


I'm not talking about writing, I'm talking about reading. I don't care
how much you try to ignore the markup, you _will_ perceive that some
text has a different layout than some other text, and this _will_
require mental effort, however little.


Cite?

--
Nov 13 '05 #252
Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:
In any case, if I were, I'd be vehemently arguing _for_ the inclusion of
HTML, VBScript, Sheesh, .dot.net..., and goodness knows what else these
days, in Usenet, e-mail, the 'web, and by preference your e-toaster as
well. Perhaps _you_ work for M$?


Why don't you try hurling your 'MICROSOFT LOVER' insult over in
netscape.public.mozilla.webtools and see how far you get.

To make it easier for you, I have set the followup to that newsgroup.

If I am not mistaken, they were the first to have a client which
supported HTML USENET postings.
--
Nov 13 '05 #253
On Mon, 17 Nov 2003 11:07:22 -0600, Programmer Dude
<Ch***@Sonnack.com> wrote:
Ian Woods wrote:
Text *became* a universal medium.


I don't know about text 'becoming' a universal medium.


Long ago, there were an awful lot of IBM 3270/SNA terminals!
Another big item was DEC VT*** terminals. Neither were plain
text.

Nearly all 327X terminals were plaintext, most of them uppercase only,
which would not be considered adequate/usable for Usenet etc. today;
graphics was a substantial-extra-cost option, limited, and slow if on
a remote connection. The early DEC video terminals were plaintext
with a few special characters that can basically create boxes and
rules -- which would be adequate, though clumsy, for most technical
material -- although VT10x did have some basic font modifications. I
believe it was VT200 that added programmable but still quite limited
"sixel" graphics. And many of the terminals used on most(?) DEC
systems were from other makers, and if they had any graphics at all
usually weren't compatible and so could only be used with custom
software. Just getting interactive *character* things like screen
erase and scrolling to work across the terminal population on Unix
systems required a pretty big "curses" database.

- David.Thompson1 at worldnet.att.net
Nov 13 '05 #254
Dave Thompson wrote:
Long ago, there were an awful lot of IBM 3270/SNA terminals!
Another big item was DEC VT*** terminals. Neither were plain
text.
Nearly all 327X terminals were plaintext, most of them uppercase...


Not as we define plaintext. The 3270s I remember were "all points
addressable". That is, there were code sequences in the data
stream that allowed "forms and fields" on the screen. Generally,
the operator only had access to the allowed fields.
The early DEC video terminals were plaintext with a few special
characters that can basically create boxes and rules --


And the VT escape codes that allowed a variety of things. Even
the VT100 series was "apa" -- escape sequences allowed you to put
the cursor anywhere you wanted.

You're right that What Was On The Screen was plaintext and typically
uppercase. The data stream that *put* it there was not.

Very much like HTML, actually....

--
|_ CJSonnack <Ch***@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|___ ____________________|
Nov 13 '05 #255
(warning: now veering off even the metatopic)

On Tue, 25 Nov 2003 12:00:36 -0600, Programmer Dude
<Ch***@Sonnack.com> wrote:
Dave Thompson wrote:
Long ago, there were an awful lot of IBM 3270/SNA terminals!
Another big item was DEC VT*** terminals. Neither were plain
text.
Nearly all 327X terminals were plaintext, most of them uppercase...


Not as we define plaintext. The 3270s I remember were "all points
addressable". That is, there were code sequences in the data
stream that allowed "forms and fields" on the screen. Generally,
the operator only had access to the allowed fields.

For points=character-cells, yes. Okay, as you got below, I was talking
here about display enhancements (font variants/sizes, colors,
graphics) and not the datastream, and failed to distinguish.

327X *can* actually be used with a nearly-plain datastream, namely no
"orders" and only the initial command prefix (which is always
required); but this gives an unformatted display with the cursor in
home position, which is usually slow(er), easy(er) to produce garbled
input, and hard or impossible to give good feedback, so it wasn't
popular. I have actually used, and bitched at, some quick&dirty
utilities that did this. (You're right that) most 327X applications
use(d) forms containing protected/output and unprotected/input fields,
and TAB BACKTAB RETURN HOME go only to a protected field; (on a real
327X) if one uses the arrow keys to move to a protected area, or type
off the end of one field onto a non-skip protected field, and try to
type there, it "checks", and I think some emulators may not even allow
the movement.

A formatted field on 327X can also be invisible, and a common method
for "stateless" programming is to write to the screen buffer an
invisible protected field containing state data and flagged modified,
so on the next input operation (ENTER or PFnn) it is included along
with actual input data, and tells the program where to resume
processing; this is rather like HTTP (or HTML http-equiv) cookie or
HTML FORM HIDDEN field, except those don't take screen space.
The early DEC video terminals were plaintext with a few special
characters that can basically create boxes and rules --


And the VT escape codes that allowed a variety of things. Even
the VT100 series was "apa" -- escape sequences allowed you to put
the cursor anywhere you wanted.

I'm not sure about VT50; VT52 was directly addressable, but had IIRC
no display enhancements at all. VT10x had some enhancements, as I
mentioned, but not nearly all the ones you indicated earlier you would
want from HTML news. VT2xx added some and I believe 3xx more, but I
don't remember details there. All DEC terminals, and most other makers
as well, worked perfectly fine as a "glass TTY" with no commands at
all beyond the ASCII control characters (CR LF, maybe BS HT BEL) and
were commonly, I would estimate mostly, used that way. There were
specific applications that operated in "full screen" mode, especially
and most desirably editors, but any fields were created and protected
by the host receiving and screening each keystroke, although IIRC 2xx
added some minimal local checking capability.
You're right that What Was On The Screen was plaintext and typically
uppercase. The data stream that *put* it there was not.

Very much like HTML, actually....


Well, not that much. HTML was intended to be *structural* markup, and
although it has largely been (mis?)used for presentation w3c is trying
to drag it back toward structure. The orders and escape/command
sequences used on 327X and VTnnn, and indeed nearly all video
terminals, are almost entirely presentation, or communications
control. For example, one can't say "indent the following text block"
as you asked for at one point, much less "this is a block quote" or
"this is a stanza of poetry"; instead one must send each line (with a
correct break) with spaces and/or tabs prefixed. Although they do both
qualify as markup -- along with a huge number of other things,
including Usenet/textmail's > ** __ :-) etc.

- David.Thompson1 at worldnet.att.net
Nov 13 '05 #256
Dave Thompson wrote:
(warning: now veering off even the metatopic)
Indeed, and as we seem to be on the same page, this will be my
last contribution. I have just a few "un huh" responses....

The 3270s I remember were "all points addressable".


For points=character-cells, yes.


Un, huh, yep.
327X *can* actually be used with a nearly-plain datastream,
namely no "orders" and only the initial command prefix (which
is always required);
Which really ties back to my original point. Even the most plain
"tty" possible use--which we agree was pretty bogus--still required
some metadata. (Recall that my thesis here is that "text" is not
as generic as we might think--it's an *established* standard that
was once not standard at all. My contention is that HTML may be in
that position today--not a universal, generic standard, but perhaps
in the position of becoming one.)
And the VT escape codes that allowed a variety of things. Even
the VT100 series was "apa" -- escape sequences allowed you to put
the cursor anywhere you wanted.


I'm not sure about VT50; VT52 was directly addressable, but had
IIRC no display enhancements at all.


Well, between the directly addressable cursor and the "graphics"
characters, you could do a lot if you wanted to. Again, the point
is the data stream was anything but "plain text".
VT10x had some enhancements, as I mentioned, but not nearly all
the ones you indicated earlier you would want from HTML news.


Well, no, that wasn't really my goal. I was just pointing out
that "plain text" *evolved* from the systems of the day. Just
as I see HTML (maybe) doing now (more likely, it'll end up being
something more like XML).

You're right that What Was On The Screen was plaintext and
typically uppercase. The data stream that *put* it there was
not.

Very much like HTML, actually....


Well, not that much. HTML was intended to be *structural* markup,
and although it has largely been (mis?)used for presentation w3c
is trying to drag it back toward structure.


[grin] Yes, the Artists and Marketers have been fighting the
Content Providers ever since the web took off (I distinctly
recall believing it would be non-starter--never trust me for
stock picks! :-).

I was referring to the idea of meta-text. Even LF/CR is a type
of meta-text that describes the presentation. The 65/68/72/75/78
preferred character line limit of amUSENET, the embedded LF/CR
(or LF, or CR) isn't some "natural and intuitive" standard. It
evolved from a need.

What I'm seeing is that the need is "to communicate" and that the
techology of THIS day makes plain text a "buggy whip" due for a
replacement.

--
|_ CJSonnack <Ch***@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|___ ____________________|
Nov 13 '05 #257
Programmer Dude <Ch***@Sonnack.com> writes:
[...]
What I'm seeing is that the need is "to communicate" and that the
techology of THIS day makes plain text a "buggy whip" due for a
replacement.


I'm sorry, I didn't understand what you just wrote. Can you try again
in a bigger font? Thanks.

--
Keith Thompson (The_Other_Keith) 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 #258
Keith Thompson wrote:
What I'm seeing is that ...


I'm sorry, I didn't understand what you just wrote. Can you
try again in a bigger font? Thanks.


Sure.

# # #
# # # # # # ## #####
# # # # # # # # #
# # # # ###### # # #
# # # # # # ###### #
# # # # # # # # #
# ## ## # # # # #

### ###
# ### # #
# # ## ##
# # # ## #
# # #
# # #
### # #

#### ###### ###### # # # ####
# # # # ## # # #
#### ##### ##### # # # # #
# # # # # # # # ###
# # # # # # ## # #
#### ###### ###### # # # ####

# #### ##### # # ## #####
# # # # # # # #
# #### # ###### # # #
# # # # # ###### #
# # # # # # # # #
# #### # # # # # # .....
[g, d & rfc]

--
|_ CJSonnack <Ch***@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|___ ____________________|
Nov 14 '05 #259

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

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.