calloc.... Why?

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

re: calloc.... Why?

Le dimanche 18 juillet 2004 à 15:15:58, JKop a écrit dans
comp.lang.c++*:
[color=blue]
> 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);
> }[/color]

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

re: calloc.... Why?

sorry, only a test

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

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


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

"JKop" <NULL@NULL.NULL> дÈëÏûÏ¢ÐÂÎÅ:iKuKc.4874$Z14.5839@news.indigo.ie...[color=blue]
> 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[/color]

re: calloc.... Why?

JKop <NULL@NULL.NULL> wrote:[color=blue]
> Is there something I'm missing?[/color]

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.
[color=blue]
> Isn't it just:
>
> inline void* calloc ( const size_t& num, const size_t& size )[/color]

No, it is:
void *calloc(size_t nmemb, size_t size)
[color=blue]
> {
> return malloc(num * size);
> }[/color]

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.

re: calloc.... Why?

[color=blue]
> inline void* calloc ( const size_t& num, const size_t& )[/color]

I use const references because it's inline.


-JKop

re: calloc.... Why?

JKop wrote:
[color=blue][color=green]
>>inline void* calloc ( const size_t& num, const size_t& )[/color]
>
>
> I use const references because it's inline.[/color]


Well calloc() is a standard library function with a specific function
signature, so your above is not a calloc() implementation (and calloc()
also zeros all bytes).






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

re: calloc.... Why?

DUH? what has const references got to do with
being inlined ?
[color=blue]
> -JKop[/color]
"JKop" <NULL@NULL.NULL> wrote in message
news:TePKc.4938$Z14.6004@news.indigo.ie...[color=blue]
>[color=green]
> > inline void* calloc ( const size_t& num, const size_t& )[/color]
>
> I use const references because it's inline.
>
>
> -JKop[/color]

re: calloc.... Why?

Dave Townsend posted:
[color=blue]
>
> DUH? what has const references got to do with
> being inlined ?
>[color=green]
> > -JKop[/color]
> "JKop" <NULL@NULL.NULL> wrote in message
> news:TePKc.4938$Z14.6004@news.indigo.ie...[color=green]
>>[color=darkred]
>> > inline void* calloc ( const size_t& num, const size_t& )[/color]
>>
>> I use const references because it's inline.
>>
>>
>> -JKop[/color]
>
>
>[/color]

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

re: calloc.... Why?

In message <jz6Lc.5010$Z14.6321@news.indigo.ie>, JKop <NULL@NULL.NULL>
writes[color=blue]
>Dave Townsend posted:[color=green]
>>
>> DUH? what has const references got to do with
>> being inlined ?
>>
>> "JKop" <NULL@NULL.NULL> wrote in message
>> news:TePKc.4938$Z14.6004@news.indigo.ie...[color=darkred]
>>>
>>> > inline void* calloc ( const size_t& num, const size_t& )
>>>
>>> I use const references because it's inline.[/color][/color]
>
>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.[/color]

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

--
Richard Herring

re: calloc.... Why?

On Tue, 20 Jul 2004 12:14:36 +0100, Richard Herring <junk@[127.0.0.1]>
wrote:
[color=blue]
>In message <jz6Lc.5010$Z14.6321@news.indigo.ie>, JKop <NULL@NULL.NULL>
>writes[color=green]
>>Dave Townsend posted:[color=darkred]
>>>
>>> DUH? what has const references got to do with
>>> being inlined ?
>>>
>>> "JKop" <NULL@NULL.NULL> wrote in message
>>> news:TePKc.4938$Z14.6004@news.indigo.ie...
>>>>
>>>> > inline void* calloc ( const size_t& num, const size_t& )
>>>>
>>>> I use const references because it's inline.[/color]
>>
>>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.[/color]
>
>And ignoring the "as-if" rule. Nothing _has_ to be copied.[/color]

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

re: calloc.... Why?

Richard Herring posted:
[color=blue]
> And ignoring the "as-if" rule. Nothing _has_ to be[/color]
copied.


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


Still sure nothing has to be copied?


-JKop

re: calloc.... Why?

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

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

re: calloc.... Why?

JKop wrote:[color=blue]
>
> Richard Herring posted:
>[color=green]
> > And ignoring the "as-if" rule. Nothing _has_ to be[/color]
> copied.
>
> void Blah(std::vector a, std::vector b)
> {
> //Change a and b
> }
>
> Still sure nothing has to be copied?[/color]

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.

--
Karl Heinz Buchegger
kbuchegg@gascad.at

re: calloc.... Why?

In message <hb8Lc.5020$Z14.6336@news.indigo.ie>, JKop <NULL@NULL.NULL>
writes[color=blue]
>Richard Herring posted:
>[color=green]
>> And ignoring the "as-if" rule. Nothing _has_ to be[/color]
>copied.
>
>
>void Blah(std::vector a, std::vector b)
>{
> //Change a and b
>}[/color]

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.
[color=blue]
>Still sure nothing has to be copied?[/color]

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?

--
Richard Herring

re: calloc.... Why?

On Tue, 20 Jul 2004 12:30:03 GMT, JKop <NULL@NULL.NULL> wrote:
[color=blue]
>tom_usenet posted:
>[color=green]
>> And using references doesn't make the optimizer's job any[/color]
>easier IMHO.[color=green]
>> But it's likely that both versions will generate[/color]
>identical code when[color=green]
>> inlined in the same context.
>>
>> Tom[/color]
>
>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.[/color]

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[color=blue]
>function; if you use const references, the compiler has no
>optimation to do, it simply uses the objects in the calling
>function.[/color]

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[color=blue]
>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.[/color]

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