calloc.... Why?

J

JKop

Is there something I'm missing? Isn't it just:


inline void* calloc ( const size_t& num, const size_t& size )
{
return malloc(num * size);
}


-JKop
 
S

Serge Paccalin

Le dimanche 18 juillet 2004 à 15:15:58, JKop a écrit dans
comp.lang.c++ :
Is there something I'm missing? Isn't it just:

inline void* calloc ( const size_t& num, const size_t& size )
{
return malloc(num * size);
}

You missed the memset(...,0,num * size); part.

--
___________ 2004-07-18 15:32:04
_/ _ \_`_`_`_) Serge PACCALIN -- sp ad mailclub.net
\ \_L_) Il faut donc que les hommes commencent
-'(__) par n'être pas fanatiques pour mériter
_/___(_) la tolérance. -- Voltaire, 1763
 
R

rokia

sorry, only a test

--
ÐÂÎÅ×éÀïÓÐÂÒÂ룿ij¸ö³£ÓÃÃüÁîÔڲ˵¥ÖÐÒþ²ØÌ«ÉOEµÄ¿ì½Ý¼ü²»¹»Óã¿

ÊDz»ÊǾ­³£ÔÚÐÂÎÅ×éÀï´ò¿ªÒ»¸öÌû×Ó£¬È´·¢ÏÖÒ»¶ÑÂÒÂ룿ÓÚÊǺõ£¬Ç§ÐÁÍò¿àµÄÈ¥µã»÷²Ë
µ¥,ÔÚÄÇô¶à±àÂëÖÐÑ°ÕÒGB2312£¿ ÏÖÔÚºÃÁË¡£ºÙºÙ¡£ ÓÃÕâ¸ö OEPartner À´¶¨ÖÆÒ»¸ö¿ì
½Ý¼ü¡£ÇáËÉÒ»µã£¬È«²¿¸ã¶¨£¡


Çëµ½ http://rokia.vicp.net ÏÂÔØʹÓá£:)
 
O

Old Wolf

JKop said:
Is there something I'm missing?

As always, yes. Please read the FAQ before posting. (section
7.31 of the comp.lang.c FAQ). Even a glance at the Standard
or your compiler documentation would have explained what
'calloc' does.
Isn't it just:

inline void* calloc ( const size_t& num, const size_t& size )

No, it is:
void *calloc(size_t nmemb, size_t size)
{
return malloc(num * size);
}

Description

[#2] The calloc function allocates space for an array of
nmemb objects, each of whose size is size. The space is
initialized to all bits zero.

[#3] The calloc function returns either a null pointer or a
pointer to the allocated space.
 
J

JKop

Dave Townsend posted:
DUH? what has const references got to do with
being inlined ?

Consider this: if you have a function that takes in two vectors, you're
going to use const references instead of by-value, because then everything
doesn't have to get copied. But... if you're taking in two ints, then it's
more efficent to pass them by-value. But... when a function is inlined,
there's no need for hidden pointers, so the const references are once again
more efficent.

This is all ofcourse assuming a stack and registers system.

-JKop
 
R

Richard Herring

[QUOTE="JKop said:
DUH? what has const references got to do with
being inlined ?

Consider this: if you have a function that takes in two vectors, you're
going to use const references instead of by-value, because then everything
doesn't have to get copied. But... if you're taking in two ints, then it's
more efficent to pass them by-value. But... when a function is inlined,
there's no need for hidden pointers, so the const references are once again
more efficent.

This is all ofcourse assuming a stack and registers system.[/QUOTE]

And ignoring the "as-if" rule. Nothing _has_ to be copied.
 
T

tom_usenet

[QUOTE="JKop said:
DUH? what has const references got to do with
being inlined ?


inline void* calloc ( const size_t& num, const size_t& )

I use const references because it's inline.

Consider this: if you have a function that takes in two vectors, you're
going to use const references instead of by-value, because then everything
doesn't have to get copied. But... if you're taking in two ints, then it's
more efficent to pass them by-value. But... when a function is inlined,
there's no need for hidden pointers, so the const references are once again
more efficent.

This is all ofcourse assuming a stack and registers system.

And ignoring the "as-if" rule. Nothing _has_ to be copied.[/QUOTE]

And using references doesn't make the optimizer's job any easier IMHO.
But it's likely that both versions will generate identical code when
inlined in the same context.

Tom
 
J

JKop

Richard Herring posted:
And ignoring the "as-if" rule. Nothing _has_ to be
copied.


void Blah(std::vector a, std::vector b)
{
//Change a and b
}


Still sure nothing has to be copied?


-JKop
 
J

JKop

tom_usenet posted:
And using references doesn't make the optimizer's job any easier IMHO.
But it's likely that both versions will generate identical code when
inlined in the same context.

Tom

It's not optimization at all, it's simply what inline
functions are all about. When a function is "outline",
arguments have to be passed to it in a certain way (stack
and registers), but when the function's inline, the stack
and registers aren't bothered with. So... with an inline
function; if you use const references, the compiler has no
optimation to do, it simply uses the objects in the calling
function. But if the arguments are by-value, then the
compiler actually would have to do an optimization to
realize that it can use the objects from the calling
function. Alternatively you could pass by-value and have
the objects const in the inline function, then the compiler
would know to use the objects from the calling function. I
prefer the const references, as it's very clear what's
going on.


-JKop
 
K

Karl Heinz Buchegger

JKop said:
Richard Herring posted:

copied.

void Blah(std::vector a, std::vector b)
{
//Change a and b
}

Still sure nothing has to be copied?

Ok. Now do the same with references (const or not const).
That is: call that function, let the function alter the
passed parameters, but the caller should not be aware
of that change. You have to copy the passed arguments.

Back to your assumption, which was
You use a const reference because the function may inline
that function.

Well.
If you have

int foo( int a, int b)
{
return 2 * a + b;
}

int main()
{
int c = 3, d = 4;

cout << foo( c, d );
}

AND the compiler inlines the function, then it most
likely will *not* create copies for c and d. The data
flow analysis of the compiler will show, that a and b
never get altered inside the functions body and thus
the compiler can use c and d directly.

It effectively boils down to

int main()
{
int i = 5;
int j = i;

cout << j;
}

where the compiler is able to wipe out variable j
completely and use i instead.

Of course there is no requirement for the compiler to make
a data flow analysis, but almost all compilers do it. It
would be impossible to sell such a masterpiece on the market
without such an analysis.
 
R

Richard Herring

And ignoring the "as-if" rule. Nothing _has_ to be
copied.


void Blah(std::vector a, std::vector b)
{
//Change a and b
}[/QUOTE]

Not inline, according to a comment modifies its parameters (for no
apparent reason, since they're passed by value) but no code to
illustrate the fact.

Compare with
inline void* JKopsNotQuiteCalloc( const size_t& num, const size_t& size)
{ return malloc(num * size); }

or
inline void* JKopsNotQuiteCalloc(size_t num, size_t size)
{ return malloc(num * size); }

Inline, don't modify their parameters.
Still sure nothing has to be copied?

Quite sure, thanks.

What was your function Blah supposed to be illustrating?

Does "//Change a and b" have any effect on the observable behaviour of
the program?
 
T

tom_usenet

tom_usenet posted:


It's not optimization at all, it's simply what inline
functions are all about. When a function is "outline",
arguments have to be passed to it in a certain way (stack
and registers), but when the function's inline, the stack
and registers aren't bothered with.

inline is only a hint to the compiler, and a way to avoid violating
the one definition rule. The compiler can (and does) choose to inline
apparently non-inline functions, and to put inline functions out of
line.

So... with an inline
function; if you use const references, the compiler has no
optimation to do, it simply uses the objects in the calling
function.

But it introduces aliasing problems, making optimization harder, and
can even change semantics. I'll give you an example:

int foo = 10;

inline int f(int const& ref)
{
foo = ref;
++foo;
return foo + ref;
}

int main(int argc, char** argv)
{
int const& i = argc > 1? foo: 10;
f(foo); //hmmm.
}

Because a reference is used, the compiler doesn't know whether that
reference is an alias for "foo", so it has to assume it is, and
therefore produce suboptimal code. If you change the semantics to:

inline int f(int ref)
{
foo = ref;
++foo;
return foo + ref;
}

then the compiler can optimize it much better, since it knows "ref" is
free from aliases (since it is a local variable).

But my basic point is that references can be bad since they are
aliases, and aliases hurt optimization, since you never know what they
are aliasing.

On another note, your concept of "use the objects in the calling
function" doesn't really make sense. Remember that CPUs have
registers, and often variables have their values both in "main" memory
and in a register. When inlining a function, whether using by-ref or
by-val parameter passing, the compiler optimizes things to work out
whether it already has the relevent value in registers, or whether
they have to be reloaded, or whatever. Using references vs values may
actually harm this process, since the optimizer is generally happier
dealing with local, independant variables.

Still, this is a complex issue, and examining output assemblies is
probably the best way to experiment.

But if the arguments are by-value, then the
compiler actually would have to do an optimization to
realize that it can use the objects from the calling
function. Alternatively you could pass by-value and have
the objects const in the inline function, then the compiler
would know to use the objects from the calling function. I
prefer the const references, as it's very clear what's
going on.

However, it goes against all style guidelines I've read, and will
therefore confuse anyone reading your code (as you have already seen
with this thread).

Tom
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,579
Members
45,053
Latest member
BrodieSola

Latest Threads

Top