473,854 Members | 1,595 Online
Bytes | Software Development & Data Engineering Community
+ 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 8877
Programmer Dude on site wrote:

An you should know
me well enough to know I do not take kindly to unwarranted attacks.


Then don't make them.

--
Richard Heathfield : bi****@eton.pow ernet.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
Nov 13 '05 #181
Richard Heathfield <do******@addre ss.co.uk.invali d> wrote:
Programmer Dude on site wrote:
An you should know
me well enough to know I do not take kindly to unwarranted attacks.


Then don't make them.


Pot Meet Kettle
--
Nov 13 '05 #182
CBFalconer <cb********@yah oo.com> wrote:
te*********@BUS ThotmailE.Rcom wrote:
Keith Thompson <ks***@mib.or g> wrote:
Programmer Dude <Ch***@Sonnack. com> writes:
> "Arthur J. O'Dwyer" wrote:
[...]
> > Nor do I really want to give spammers the ability to count
> > hits on Usenet postings, like HTML mail has given them the
> > ability to count hits on private email.
>
> ?? How do they do that? (Are you talking using images?)

Yes, they're called "web bugs".


So, why would you allow your client application to make a
connection back to somewhere as it was attempting to render the
page?

Why would you even use a client application that wouldn't allow
you to disable such things?


In case you hadn't noticed, most text editors/viewers don't have
such dangerous abilities, thus there is no need to disable them in
the first place.


You are apparently ignoring the inevitability of a USENET on which HTML
is common and those who wish to continue to use it would be required to
move to clients which supports HTML.

This, of course, does assume that USENET survives to make the
transition...wh ich is by no means guaranteed either. What might replace
it? The most likely candidate at the moment, are web based discussion
boards.

I know of at least one founder of USENET who hates everything that is
USENET and advocates it's demise. I believe he works for Apple Computer
now and helps run their mailing lists (lists.apple.co m).

--
Nov 13 '05 #183
On 11 Nov 2003 09:53:44 -0800
Ch***@Sonnack.c om (Programmer Dude on site) wrote:
CBFalconer wrote:
Fonts, colors, sizes etc. are none of the senders business.
As a writer and an artist, I disagree 1000%! Those attributes
are a part of my creative expressive toolkit (for in the hands
of a knowledgable user, they can add a great deal to the
information content).


The problem here is that most posters (including myself) are *not*
knowledgeable about what is readable to the majority of people. With
plain ASCII text there is far less for people to mess up.
By using plain text and limiting lines to 65 chars I can
display it in sizes, colors, fonts, etc. that SUIT ME when
reading (which I won't if it is in html).


Actually, you can tell your renderer to ignore some or all
the HTML tags. You can define substitute fonts and even specify
a line length. (One nice thing about HTML is the <p> idea. That
allows all users to view decent paragraphs in THEIR prefered line
length, be it 40 cols or 120.)


You are assuming that most people understand how to configure there
software. You are also assuming that the most commonly used software
allows such configuration to be done in a simple manner.
I still see advantages and no disadvantages. You can disable as
much of the HTML as you like. Or not.

Seems win-win to me.


How about the fact that it would take a lot longer to download and that
for people stuck with a maximum 33K download speed. I know areas where
broadband is not available and if BT choose to use a DACS on your phone
line 33K is the maximum you will get.

It used to take long enough for me on a modem when I was regularly
getting 44K connections.
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.
Nov 13 '05 #184
te*********@BUS ThotmailE.Rcom writes:
[...]
You are apparently ignoring the inevitability of a USENET on which HTML
is common and those who wish to continue to use it would be required to
move to clients which supports HTML.
We're not ignoring it, we're denying it. We're not failing to
understand your point, we just think you're wrong.

We've seen a major transition of e-mail from a medium that only
supported plain text to one that also supports HTML. We simply are
not seeing any signs of a similar transition for Usenet, though the
idea has been under discussion for years. Usenet has evolved
mechanisms for transferring binary files, but there just hasn't been
any significant demand for HTML. If this transition is inevitable,
why hasn't it started?

[snip]
I know of at least one founder of USENET who hates everything that is
USENET and advocates it's demise. I believe he works for Apple Computer
now and helps run their mailing lists (lists.apple.co m).


I don't know who you're referring to, but he, like everyone else, is
free not to use Usenet if he doesn't want to.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)
Nov 13 '05 #185
Since the original "buggy whip" comment was directed at me, I'll jump in.

The comment in question was:

} Your desire to remain in the era of buggy whips not withstanding,
} the *fact* of the matter is that formatted text is *easier* to
} read. This--hopefully--is not in dispute.

I found that comment misguided, incorrect, and mildly annoying, but
not deeply offensive. (I've been seriously insulted in this newsgroup
recently; the "buggy whip" remark wasn't even close.)

I suggest not wasting any more time arguing about who insulted whom in
a discussion that's way off-topic anyway.

Let's all just agree that I'm right and everyone else is wrong, and
move on from there.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)
Nov 13 '05 #186
Keith Thompson <ks***@mib.or g> wrote:
te*********@BUS ThotmailE.Rcom writes:
[...]
You are apparently ignoring the inevitability of a USENET on which HTML
is common and those who wish to continue to use it would be required to
move to clients which supports HTML.


We're not ignoring it, we're denying it. We're not failing to
understand your point, we just think you're wrong.

We've seen a major transition of e-mail from a medium that only
supported plain text to one that also supports HTML. We simply are
not seeing any signs of a similar transition for Usenet, though the
idea has been under discussion for years. Usenet has evolved
mechanisms for transferring binary files, but there just hasn't been
any significant demand for HTML. If this transition is inevitable,
why hasn't it started?


It has via the support for HTML in some usenet clients.
--
Nov 13 '05 #187
On Tue, 11 Nov 2003 20:23:50 GMT, Keith Thompson <ks***@mib.or g>
wrote:
We've seen a major transition of e-mail from a medium that only
supported plain text to one that also supports HTML.


What we (or at least I) haven't seen, however, is any major transition
to email that actually needs or even effectively uses HTML. The vast
majority of HTML email I see is simply plain text with a bunch of
tags. The usual goals of email and usenet posting are quick
communication of relatively short messages. HTML adds little if
anything to further those goals, and in fact, usually detracts from
them.

In companies where I work, I sometimes see email (usually posted by
the HR people) which comes in bright colors, with flowers twining
around the border, and attention-grabbing fonts. The reaction from the
recipients is often "Obviously they don't have any real work to do."
Reaction from the network admins is usually "Damn, another gigabyte of
storage gone."

--
Al Balmer
Balmer Consulting
re************* ***********@att .net
Nov 13 '05 #188
Keith Thompson wrote:
Let's all just agree that I'm right and everyone else is wrong,
and move on from there.


Okay, I agree with you that I'm right and everyone else is wrong.

Movin' on..... (-:

--
|_ CJSonnack <Ch***@Sonnack. com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ _______________ ____| Call: 1-800-DEV-NULL |
|______________ _______________ _______________ _|_____________ __________|
Nov 13 '05 #189
Keith Thompson wrote:
(Are you talking using images?)
Yes, they're called "web bugs". An e-mail message contains an IMG
tag with a URL specifying the location of the image.


That's what I thought. Simple solution: turn off images. I think
I mentioned this in one of my first posts....
They can even customize the URL for each message so they can tell
which copy of the message was viewed.


Yep. Adding stuff to the end is one way it's done:

http://www.BadPeople.com/images/BadImage.gif?u=1234567

Virtual paths are another:

http://www.BadPeople.com/images/webb...7/BadImage.gif

In reality, "/images/webbug" is a CGI program. The rest is just
virtual path passed into that program.

--
|_ CJSonnack <Ch***@Sonnack. com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ _______________ ____| Call: 1-800-DEV-NULL |
|______________ _______________ _______________ _|_____________ __________|
Nov 13 '05 #190

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.