krishna.vamsi | 4 Aug 17:28 2006

Anonymous structures

Hi all,

Can I pass anonymous structures as function arguments, 

Struct A{ int a; int b};

F(struct A a)
{
}

Int main()
{
	f({a,b})
}

If I can how can I do that ?

-Vamsi
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Glynn Clements | 4 Aug 19:22 2006

Re: Anonymous structures


krishna.vamsi <at> wipro.com wrote:

> Can I pass anonymous structures as function arguments, 
> 
> Struct A{ int a; int b};
> 
> F(struct A a)
> {
> }
> 
> Int main()
> {
> 	f({a,b})
> }
> 
> If I can how can I do that ?

No. An anonymous structure has an unknown size, so the compiler cannot
generate code to copy them.

Anonymous structures are only useful as pointer targets, i.e.
"struct A *foo". You can pass around pointers to structures without
knowing the size of the structure, although you can't dereference them.

--

-- 
Glynn Clements <glynn <at> gclements.plus.com>
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Raseel Bhagat | 5 Aug 04:28 2006
Picon

Re: Anonymous structures

Hi Glynn,

On 8/4/06, Glynn Clements <glynn <at> gclements.plus.com> wrote:
> No. An anonymous structure has an unknown size, so the compiler cannot
> generate code to copy them.
>
> Anonymous structures are only useful as pointer targets, i.e.
> "struct A *foo". You can pass around pointers to structures without
> knowing the size of the structure, although you can't dereference them.
>
>

If we can't dereference them, then what would be the use of such a call ?
Can you cite a example for the above scenario ?

--

-- 
Raseel.
http://osd.byethost8.com
http://raseel.livejournal.com
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Glynn Clements | 5 Aug 18:20 2006

Re: Anonymous structures


Raseel Bhagat wrote:

> > No. An anonymous structure has an unknown size, so the compiler cannot
> > generate code to copy them.
> >
> > Anonymous structures are only useful as pointer targets, i.e.
> > "struct A *foo". You can pass around pointers to structures without
> > knowing the size of the structure, although you can't dereference them.
> 
> If we can't dereference them, then what would be the use of such a call ?
> Can you cite a example for the above scenario ?

They can be dereferenced in a context where the structure isn't
anonymous.

A library can define a structure in a private header which is used by
the library's source files, while the public header only has an
anonymous declaration. The library can pass pointers to the
application, which can pass them back to the library, but the
application can't access the structure's members. To the application,
the pointer is an opaque handle.

E.g.:

private header:

	struct foo { int x; };

library source:
(Continue reading)

Randie King | 8 Aug 00:44 2006

August Payment Summary, Invoice #93742

collection efforts with this Past-Due Account form
Attachment (invoice.doc): application/msword, 45 KiB
Robert P. J. Day | 10 Aug 13:58 2006
Picon

the rationale for defining macros for simple types?


  a project that i inherited a while back contains a header file with
the following macros:

#ifndef UCHAR
#define UCHAR   unsigned char
#endif

#ifndef UINT
#define UINT    unsigned short int
#endif

#ifndef ULONG
#define ULONG   unsigned long int
#endif

#ifndef BOOL
#define BOOL    unsigned int
#endif

#ifndef TRUE
#define TRUE    (1>0)
#define FALSE   !TRUE
#endif

and proceeds to, naturally, define numerous variables using those
macros.  it's not clear why the original programmer chose to do it
this way rather than just use <stdint.h> and things like uint8_t and
so on.  i don't see any overwhelming need to add yet another level of
complexity when the standard types would seem to do just fine.
(Continue reading)

Robert P. J. Day | 10 Aug 16:01 2006
Picon

the pros and cons of "catch-all" header files


  over the next few days, i'm going to have some general design-type
questions as i try to restructure a project i'm working on, so i'm
hoping i don't wander too far from the mandate of the list.

  on this current project, there is frequent use of what i call
"catchall" header files.  rather than have individual source files
pull in just those header files they need, a monster "catchall.h" file
is created that contains almost all project-related inclusions, so
that source files need only:

  #include "catchall.h"

  sure, it's convenient, but there are also some obvious downsides.
the simple question -- is there a defensible rationale for this
approach?  i personally don't like it and would prefer source files to
be more selective, but the argument i keep hearing is, "it's more
convenient."

  thoughts?

rday
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Robert P. J. Day | 10 Aug 16:10 2006
Picon

how to implement routines that return general strings?


  i'm about to design and implement a number of routines that return
strings and, as far as i can tell, i have two general design choices.

  int		func(char* buf, int bufsiz) ;
  char*		func() ;

  that first form obviously accepts the address of a buffer (and its
size) into which to copy the result, and leaves the "int" return value
to be used perhaps as an error code.  perfectly reasonable, but it
forces every invocation to first have a buffer ready to go.

  the second form would be intuitively more natural, but is affected
by the scope of the result.  the approach i would use there might be:

char*
func()
{
	static buf[128] ;	// or whatever size is appropriate
	... copy result into buf ...
	return buf ;
}

an error of some kind might be implemented by returning NULL, but that
will restrict the range of error codes i can pass back.

  are there compelling arguments either way?  while i like the natural
feel of the second form, i have to admit the first form is more
informative.  thoughts?

(Continue reading)

Smith, Jason - VA | 10 Aug 17:35 2006
Picon

RE: the rationale for defining macros for simple types?

Robert,

stdint.h is a part of glibc methinks, and not part of any blessed
standard that I am aware of.  What you probably want to include for the
int*_t types is <inttypes.h>, which found in /usr/(local/)?/include on
most of the common *nix's out there (might be part of a standard like
C99 too).

Typically these "convention-establishing" macros are only needed when
you need to get exact sizing for native types to compensate for word
size on multiple processor/OS/compiler combinations.  But they'll be
peppered with #ifdef wrappers for whatever dependent macro is defined
for the compiler/OS/processor you need to support.  In other words, what
inttypes.h is most likely already doing for you.

As a second opinion, I agree that those macros you have there are close
to worthless, as they are just abbreviated rehashes of the word-size
dependent native types.  Unless you have a compelling reason for making
the code less readable with no benefit over inttypes.h, I'd ditch those
macros.

Regards,
--jls 

P.S.  If you want your code to perform consistently across platforms
(and you don't care about absolute variable size), consider using the
"fast" (better speed, possible bigger size) or "least" (smaller size,
possibly slower) versions of int*_t's, such as int_fast32_t or
int_least32_t.

(Continue reading)

Robert P. J. Day | 10 Aug 17:45 2006
Picon

RE: the rationale for defining macros for simple types?

On Thu, 10 Aug 2006, Smith, Jason - VA wrote:

> Robert,
>
> stdint.h is a part of glibc methinks, and not part of any blessed
> standard that I am aware of.

my copy of harbison and steele lists <stdint.h> as part of C99.  am i
somehow reading that incorrectly?

> What you probably want to include for the int*_t types is
> <inttypes.h>, which found in /usr/(local/)?/include on most of the
> common *nix's out there (might be part of a standard like C99 too).

again, from my copy of H&S, inttypes.h includes stdint.h, so i guess
either one would work fine.  i'm guessing inttypes.h would be the
better choice since it's more all-encompassing.  thanks.

rday
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Gmane