By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,193 Members | 826 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,193 IT Pros & Developers. It's quick & easy.

Simple but interesting issue

P: n/a
Hi All,

What is the differece between following code:

#define sbyte m_sbyte
typedef signed char m_sbyte;

and

#typedef signed char sbyte

Actually the first two lines of code solves the decleration
confliction issue. When sbyte is decleared as "unsigned char", the
first two lines of code will allow you to use the sbytes and signed
char. Anyone konws why?

Mar 16 '07 #1
Share this Question
Share on Google+
9 Replies


P: n/a
Mike wrote:
Hi All,

What is the differece between following code:

#define sbyte m_sbyte
typedef signed char m_sbyte;

and

#typedef signed char sbyte
The second is illegal, as there's no #typedef preprocessor
directive. Did you mean

typedef signed char sbyte;

?
Actually the first two lines of code solves the decleration
confliction issue.
What declaration conflict issue?
When sbyte is decleared as "unsigned char", the
first two lines of code will allow you to use the sbytes and signed
char. Anyone konws why?
I've no idea what you mean. Can you be more specific?

--
Chris "electric hedgehog" Dollin
The shortcuts are all full of people using them.

Mar 16 '07 #2

P: n/a
On 16 Mar, 14:07, "Mike" <mail...@gmail.comwrote:
Hi All,

What is the differece between following code:

#define sbyte m_sbyte
Tell the precompiler to replace the string "sbyte" with "m_sbyte" in
the source code.
typedef signed char m_sbyte;
Tell the compiler that "m_sbyte" means "signed char".
>
and

#typedef signed char sbyte
(pre-)compiler error - "#typedef" is not recognised.

Either you meant :-
"typedef signed char sbyte"
which tells the compiler that "sbyte" means "signed char"

or you meant
"#define signed char sbyte"
which tells the precompiler to replace all instances of "signed" with
"char sbyte".
Actually the first two lines of code solves the decleration
confliction issue. When sbyte is decleared as "unsigned char", the
first two lines of code will allow you to use the sbytes and signed
char. Anyone konws why?
I don't know what you are trying to say.

How about cutting and pasting some real code, preferably a small but
complete example, and showing us what problem you are encountering?

Mar 16 '07 #3

P: n/a
On Mar 16, 10:19 am, Chris Dollin <chris.dol...@hp.comwrote:
Mike wrote:
Hi All,
What is the differece between following code:
#define sbyte m_sbyte
typedef signed char m_sbyte;
and
#typedef signed char sbyte

The second is illegal, as there's no #typedef preprocessor
directive. Did you mean

typedef signed char sbyte;

?
Actually the first two lines of code solves the decleration
confliction issue.

What declaration conflict issue?
When sbyte is decleared as "unsigned char", the
first two lines of code will allow you to use the sbytes and signed
char. Anyone konws why?

I've no idea what you mean. Can you be more specific?

--
Chris "electric hedgehog" Dollin
The shortcuts are all full of people using them.
Sorry about the confusion. Here is the case:

In module A, sbyte is declared as unsigned char;
In module B, sbyte is declared as singed char;

When both modules are compiled together, there will be declaration
confliction. Now if you use the first two lines of code in module B.
Everything is OK, no need to change any code in Module A and B.

Mar 16 '07 #4

P: n/a
Mike wrote:
Sorry about the confusion. Here is the case:

In module A, sbyte is declared as unsigned char;
In module B, sbyte is declared as singed char;
Well, I'd say that was a mistake. Especially giving `unsigned
char` the abbreviation `sbyte`. I'll be giving /that/ programmer
no biscuit.
When both modules are compiled together, there will be declaration
confliction.
Not unless those types are declared in the /headers/ of the
compilation units. (I assume they're not being compiled as
a single unit -- that way madness lies.)
Now if you use the first two lines of code in module B.
Everything is OK, no need to change any code in Module A and B.
Even better is to fix the typedefs, in any one of several ways:

* if the typedefs aren't needed in the headers, take them out.

* if the typedefs are supposed to be the same thing, abstract
them out into a common header file.

* if the typedefs are supposed to be different things, apply
whatever your C-doesn't-have-namespaces-but module naming
convention rules are.

--
Chris "unsigned character" Dollin
"Reaching out for mirrors hidden in the web." - Renaissance, /Running Hard/

Mar 16 '07 #5

P: n/a
Mike wrote On 03/16/07 10:46,:
[...]

In module A, sbyte is declared as unsigned char;
In module B, sbyte is declared as singed char;
<fx: sniff, sniff Is something burning?

(Sorry, but the idea of a singed char is a matchless
inadvertent pun. I couldn't resist giving it some light,
even if I now catch heat for topicality abuse. Let the
flame wars begin, so we may smoke out the humor-impaired!)

--
Er*********@sun.com
Mar 16 '07 #6

P: n/a
In article <11*********************@o5g2000hsb.googlegroups.c om>,
Mike <ma*****@gmail.comwrote:
#define sbyte m_sbyte
typedef signed char m_sbyte;
>Sorry about the confusion. Here is the case:

In module A, sbyte is declared as unsigned char;
In module B, sbyte is declared as singed char;

When both modules are compiled together, there will be declaration
confliction. Now if you use the first two lines of code in module B.
Everything is OK, no need to change any code in Module A and B.
Presumably the #define and typedef appear in B after the inclusion of
the header file for A. The result is that B doesn't really use sbyte
at all, because all occurences of it after the #define will be replaced
with m_sbyte.

This sort of hack is quite common when dealing with existing libraries
that have name clashes, but you have to be very careful - should *all*
the uses of sbyte in module B be the signed version? - and where
possibly you should try to resolve the underlying name clash. Many
other languages have some kind of namespace mechanism to solve this.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Mar 16 '07 #7

P: n/a
Eric Sosman wrote, On 16/03/07 15:08:
Mike wrote On 03/16/07 10:46,:
>[...]

In module A, sbyte is declared as unsigned char;
In module B, sbyte is declared as singed char;

<fx: sniff, sniff Is something burning?

(Sorry, but the idea of a singed char is a matchless
inadvertent pun. I couldn't resist giving it some light,
even if I now catch heat for topicality abuse. Let the
flame wars begin, so we may smoke out the humor-impaired!)
It's probably the flame wars that singed the char in the first place!
--
Flash Gordon
Mar 16 '07 #8

P: n/a
Flash Gordon wrote:
Eric Sosman wrote, On 16/03/07 15:08:
>Mike wrote On 03/16/07 10:46,:
>>[...]

In module A, sbyte is declared as unsigned char;
In module B, sbyte is declared as singed char;

<fx: sniff, sniff Is something burning?

(Sorry, but the idea of a singed char is a matchless
inadvertent pun. I couldn't resist giving it some light,
even if I now catch heat for topicality abuse. Let the
flame wars begin, so we may smoke out the humor-impaired!)

It's probably the flame wars that singed the char in the first place!
I believe singed chars have to be displayed in a sans-serif font.

--
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

Mar 16 '07 #9

P: n/a
Eric Sosman <Er*********@sun.comwrites:
[...]
Let the flame wars begin, so we may smoke out the humor-impaired!
That's not funny!

Oh, wait, never mind.

--
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"
Mar 16 '07 #10

This discussion thread is closed

Replies have been disabled for this discussion.