function pointer - C Language (Moderated)

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

function pointer
Goto page Previous 1, 2, 3 ... 10, 11, 12, 13 Next

C++Talk.NET Forum Index -> C Language (Moderated)

View previous topic :: View next topic

Author

Message

Guest

Posted: Sat Dec 16, 2006 4:57 am Post subject: Re: Returning pointer to local variable

raviinroorkee.7 (AT) gmail (DOT) com wrote:

Quote:

We shuold avoid returning a pointer to local variable but if the
variable gets its memory from heap then its work fine ,even we can
retrun a pointer to static variable,why later 2 cases wrks fine and not
the first one.

Not sure I follow exaclty why you mean, but it may be a question of
definitions.

By "local memory" most people mean a stack variable, as in:

char* f()
{
char s[10];
...
return s;
}

By that definition, heap and static are not "local memory". Both heap
and static variables are not stored in the stack, therefore they don't
disappear when the function returns.

The reason why the code snippet above doesn't work is because the stack
is reclaimed when the functions exits.

What makes some people believe that it may work is that the stack
contents are not wiped out when the function returns. The compiler
adjusts the stack pointer to recover the stack. What was there in the
stack is still there, at least for a little while.

Example that looks like it is working, using f() above:

int main()
{
char* mys = f();
printf(s); // *may* print s, as returned by f()
}

This will almost certainly not work:

int main()
{
char* mys = f();

// calling another function will overwrite what f() left in the
stack
f2();

printf(s); // will most likely print garbage
}

Christian
--
comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

Barry Schwarz
Guest

Posted: Sat Dec 16, 2006 4:57 am Post subject: Re: Returning pointer to local variable

On 05 Dec 2006 19:53:25 GMT, raviinroorkee.7 (AT) gmail (DOT) com wrote:

Quote:

Objects (such as variables) have duration.

An object with automatic duration ceases to exist when the
block it is defined in terminates. If you happen to have the address
of such an object and you attempt to evaluate that address for any
purpose after the object no longer exists, you invoke undefined
behavior.

An object with static duration is guaranteed to exist for the
duration of your program. You can always evaluate the address and if
the object has been assigned a value you can dereference the address.

An object with allocated duration exists from the time it is
allocated until it is freed. During this time period its address acts
very much like the address of a static variable..

Remove del for email
--
comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

Barry Schwarz
Guest

Posted: Sat Dec 16, 2006 4:57 am Post subject: Re: Returning pointer to local variable

On 05 Dec 2006 19:53:25 GMT, raviinroorkee.7 (AT) gmail (DOT) com wrote:

Quote:

Barry Schwarz
Guest

Posted: Sat Dec 16, 2006 4:57 am Post subject: Re: Returning pointer to local variable

On 05 Dec 2006 19:53:25 GMT, raviinroorkee.7 (AT) gmail (DOT) com wrote:

Quote:

Douglas A. Gwyn
Guest

Posted: Sat Dec 16, 2006 4:58 am Post subject: Re: Returning pointer to local variable

raviinroorkee.7 (AT) gmail (DOT) com wrote:

Quote:

Because the popped portion of the stack gets reused.
--
comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

Guest

Posted: Tue May 15, 2007 9:06 pm Post subject: Re: Fast bitwise access

File I/O is carried out by underlying system calls. Those work on data primitives as defined by the OS/hardware. There is no C support for doing I/O on files at a bit level. Read or write n bits to file will not work -- unless n happens to equal sizeof(data type). Depending on your OS, there will be system calls to map entire files into memory. This creates a buffer of size=filesize in memory. You can step bitwise through that. Failing memory mapping API's, you can call fread() to read in the whole file. Is this what you mean? -- comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry.

James Kuyper
Guest

Posted: Wed Dec 10, 2008 7:09 am Post subject: Re: File Limit of 1021

jgd (AT) cix (DOT) compulink.co.uk wrote:

Quote:

In article <clcm-20081202-0063 (AT) plethora (DOT) net>, paul.lemelle (AT) gmail (DOT) com ()
wrote:
I am trying to create a series of 4K files, everything works fine
until I pass the 1022 mark - I get an error stating that the file
cannot be opened.

//fclose(fp[i]);

Your C compiler is accepting C++ - style comment markers. So you have

Or C99 style comment markers. Take your pick.

Quote:

commented out the fclose call. So you aren't closing your files.

I rather assumed that this was deliberate. I don't see any plausible way
he could accidentally comment out that line.
--
comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

Dag-Erling SmÃ¸rgrav
Guest

Posted: Wed Dec 10, 2008 7:09 am Post subject: Re: How to implement a 64 bit counter using two 32-bit count

Keith Thompson <kst-u (AT) mib (DOT) org> writes:

Quote:

Dag-Erling SmÃ¸rgrav <des (AT) des (DOT) no> writes:
(you probably meant to say unsigned long long, which can store any
integer value between 0 and 2^63 - 1)
That was probably a typo; you meant "between 0 and 2^64 - 1".

Yes, thank you.

DES
--
Dag-Erling SmÃ¸rgrav - des (AT) des (DOT) no
--
comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

Eric des Courtis
Guest

Posted: Wed Dec 10, 2008 7:10 am Post subject: Re: Shared pointers???

On 14 Nov, 14:35, "gedumer1" <gedum...@bellsouth.net> wrote:

Quote:

Hi,

in C... is there any such thing as an "any" type pointer? In the example
below, is there any way that I could define function "x" to accept a pointer
of type "struct a" or "struct b", or any other structure I might create with
an "int i", so I wouldn't have to create multiple functions that do exactly
the same thing? Let's assume I have a valid reason for having separate
structures with similar data. I would just like to share function "x" and
eliminate function "y". I could have many more similar structures and I'd
like to use generic function "x" for all of them. Is there any way I can do
that?

#include <stdio.h
// Structure "a"
typedef struct
{
int i;} a;

// Structure "b"
typedef struct
{
int i;
char s[5];} b;

// Function "x"
void x(a *p)
{
(*p).i = 10;}

// Function "y"
void y(b *p)
{
(*p).i = 20;}

int main(void)
{
a a1;
b b1;
x(&a1);
y(&b1);
printf("a1.i = %d, b1.i = %d\n", a1.i, b1.i);
return 0;}

--
comp.lang.c.moderated - moderation address: c...@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

THE SHORT ANSWER.

Use something called a union and declare all the structure types that
you want to use inside it.

You might want to add the union inside yet another structure along
with an enumeration of the types of structures so you know what the
union contains.

Eric
--
comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

Dag-Erling SmÃ¸rgrav
Guest

Posted: Wed Dec 10, 2008 6:41 pm Post subject: Re: Shared pointers???

Eric des Courtis <Eric.des.Courtis (AT) gmail (DOT) com> writes:

Quote:

You might want to add the union inside yet another structure along
with an enumeration of the types of structures so you know what the
union contains.

Does C99 allow anonymous unions, or is that still a GNU extension? They
are very useful for cases like this.

DES
--
Dag-Erling SmÃ¸rgrav - des (AT) des (DOT) no
--
comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

Keith Thompson
Guest

Posted: Mon Dec 15, 2008 8:04 pm Post subject: Re: Shared pointers???

Dag-Erling Smørgrav <des (AT) des (DOT) no> writes:

Quote:

Eric des Courtis <Eric.des.Courtis (AT) gmail (DOT) com> writes:
You might want to add the union inside yet another structure along
with an enumeration of the types of structures so you know what the
union contains.

Does C99 allow anonymous unions, or is that still a GNU extension? They
are very useful for cases like this.

No, C99 doesn't allow anonymous unions. On the other hand, anonymous
unions are really nothing more than syntactic sugar, and you can
always simulate them with macros:

struct foo {
int which;
union {
unsigned long x;
#define x u.x

double y;
#define y u.y

void *z;
#define z u.z
} u;
};

Putting the #defines inside the union is a little misleading, since it
implies scoping that doesn't really exist. You can always put the
#defines after the struct declaration if you prefer, but that makes
maintenance a little more difficult. And of course you have to make
sure the member names aren't used elsewhere; in this case, you can't
declare "int x;" anywhere in the same translation unit after the
#define. (Historical triva: in ancient C, member names had to be
unique anyway, which is why, for example, struct tm's members all
start with "tm_".)

--
Keith Thompson (The_Other_Keith) kst-u (AT) mib (DOT) org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
--
comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

Jasen Betts
Guest

Posted: Mon Dec 15, 2008 8:05 pm Post subject: Re: Shared pointers???

On 2008-12-10, Dag-Erling SmÃ¸rgrav <des (AT) des (DOT) no> wrote:

Quote:

In GCC turn on C99 compatibility mode and see what happens.

I think not.
--
comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

Philipp Janda
Guest

Posted: Mon Dec 15, 2008 8:05 pm Post subject: Re: "float* f" vs. "float *f"

Hi!

Mark Wooding schrieb:

Quote:

Tom Impelluso <impellus (AT) attila (DOT) sdsu.edu> wrote:

I have used both of these
"float *f"
and
"float* f"

Could someone tell me if one is preferred and why?

Since most posters so far seem to prefer the first possibility I'll add
another opinion to the mix.

Quote:

It's a style issue. Different people prefer different styles. The
compiler doesn't care, because it ignores the whitespace in either case.

But humans don't. In fact humans often use whitespace to tokenize text. So

int *j;

might be three tokens to the compiler, but for humans it's only two. The
question is: As written, does the * belong to the type or the variable name?

Quote:

Cuddling up the * to the type name, as in your second example, seems
especially popular in C++ circles: the style was popularized by Bjarrne
Stroustrup.

[SNIP]

I'd
write the above as

int i, *j;

because `*j' is how I'd dereference `j' in an expression.

<OT>
This does not work for C++ as C++ adds reference types that are declared
similarly to pointers

int& iref;

but do not have an explicit dereference syntax. Maybe that's why C++
people prefer a different style for pointers as well.
</OT>

Quote:

I could write the declarators in the other order:

int *j, i;

Hopefully that's still clear. Now, if I use the other spacing
convention, I get

int* j, i;

which is trying (quite hard) to convince me that both j and i are going
to be pointers, even though in fact only j is.

For me a pointer declaration like

int* nontrivial_name = NULL;

-- maybe followed by a comment -- is more than long enough for a single
line. So that's not a real problem for me.

Quote:

So far, so neutral. My personal view is that Stroustrup's declarator
cuddling fails to reflect the syntactic reality of the situation in ways
which can delude and confuse; it therefore is EVIL and MUST DIE.

Heavens alone know how Stroustrup-cuddlers write

int (*foo)(char *);

Probably

int (*foo)(char*)

which is not that different (function pointer syntax as well as arrays
is a special case anyway).

But for me, e.g.

int* (*foo)(char*)

is clearer and easier to decipher than

int *(*foo)(char *)

because the return value, the function pointer name, and the parameter
are nicely grouped.

Quote:

or

unsigned char *const *bibble;

unsigned char* const* bibble;

surprise ;-)

Quote:

without seeming inconsistent. But then I don't know what merit that
style is meant to have anyway.

[SNIP]

It depends on how you think about the declarations. For me it's easier
and more consistent:

unsigned char* const* bibble;

(from right to left):
"bibble is a pointer to a const pointer to a char which is unsigned",
compared to:

unsigned char *const *bibble;

"bibble, when dereferenced, becomes a const, when dereferenced,... err..."

Same goes for:

sizeof( int* )

I think about it as the "size of a pointer to int" instead of the "size
of something that's an int when dereferenced".

Or

typedef int* iptr;

The left most word is the typedef keyword, the right most word is the
new type name and everything in between is the type.

"iptr is defined to be a type equivalent to a pointer to int" instead of
"iptr is defined to be a type that is an int when dereferenced" -- wait
a minute, since when can types be dereferenced?!

Long story short:
For me, the * conceptually belongs to the type and not the identifier.

regards,
Philipp
--
comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

Guest

Posted: Wed Apr 04, 2012 11:05 pm Post subject: Re: portable code

On Thursday, December 16, 2010 8:45:38 PM UTC+2, raffamaiden wrote:

Quote:

Hi all. I'm writing a program wich will write some variables to an
output file. I do something like

int a =5;
fwrite(&a, sizeof(int), 1, my_file_ptr);

This will write an int to the file pointed by my_file_ptr. But i know
that the c standard does not specify the exact size in bytes for its
primitive type, as far as i know it only specifies that and int is an
integer type that rapresents a number with a sign, but different
implementations\operating systems can have different size for an int.

So this mean that my program will write a 32 bit integer with one
implementation and a 16 bit with another implementation. This would
also mean that the file generated by the program that is running in
one implementation will not be readable in another implementation,
unless the program knows also in which implementation the instance
that generated the file was running.
That is right? I do not want such a behavior. How can i solve this?
--
comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

You can say

write((i >> 24) & 0xFF)
write((i >> 16) & 0xFF)
write((i >> Cool

& 0xFF)
write(i & 0xFF)

This is because the integer of 32 bits you want has 4 bytes. so when you read it back simply...

int out = 0;
out += (read() >> 24);
out += (read() >> 16);
out += (read() >> Cool

;
out += (read());

This will always work no matter the endian or binary type of your system, which means the code will be more portable. Also you will never have to worry about if the compiler will have int32_t and so on because you can just assume control of the 4 bytes. As a time saving measure do the work into a buffer of unsigned char first and then just write the whole buffer of the system.

If you just have 2 bytes then same difference. Even will work with 8 bytes and __uint64 values. the example of 4 bytes is for unsigned int which is guranteed always containing 4 bytes worth of integer.
--
comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

James Kuyper
Guest

Posted: Mon Apr 23, 2012 1:31 pm Post subject: Re: which one is faster?

On 04/04/2012 07:05 PM, echo ma wrote:

Quote:

on a 32bit system.

#pragma pack(4)
struct TestStruct
{
unsigned short a;
unsigned short b;
unsigned int c;
};
#pragma pack()
struct TestStruct t;
t.a = 0; //step 1
t.b = 1; //step 2
t.c = 2; //step 3

Questing is : Are these 3 steps having the same perfomance time?

On some systems, #pragma pack() won't even be recognized as a supported
#pragma. It's not defined by the standard, and it might have different
effects on different systems.

Even on systems where #pragma pack() is recognized, and has similar
effects, there is no general answer to that question, just different
answers for different systems, and those answers will differ even on the
same system, depending upon the context. Tell us which 32-bit system
you're using, and if anyone has a similar system, they'll be able to
perform tests to determine which one is faster.
--
James Kuyper
--
comp.lang.c.moderated - moderation address: clcm (AT) plethora (DOT) net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

	C++Talk.NET Forum Index -> C Language (Moderated)	All times are GMT Goto page Previous 1, 2, 3 ... 10, 11, 12, 13 Next
Page 11 of 13