#define ALLOCIT(Type)((Type *)malloc(sizeof(Type))) [英] #define ALLOCIT(Type) ((Type*) malloc (sizeof (Type)))

查看:84
本文介绍了#define ALLOCIT(Type)((Type *)malloc(sizeof(Type)))的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

考虑以下宏:


#define ALLOCIT(Type)((Type *)malloc(sizeof(Type)))


目的是将N字节的原始内存分配

包装成一个宏,该宏返回分配的内存块

用作Type结构。

背景:我被殴打多次(肯定是b $ b不是我的独家经验)

返回并接受void *。有这样的功能,

,有些情况下你不能做很多事情

(第三方图书馆,容器等)。我的结论是:

结论:void *是邪恶的,当

可能而且容易时,必须避免。因此我认为使用上面的宏比使用原始malloc更好

。而且我认为这是一个有效的信念,而不是相信圣诞老人或活着

猫王。


在像玩具一样的玩具项目中贴在这里,当你做的时候


int * func(无效)

{

int * foo = malloc(10 * sizeof * foo);

...

}


因为如何使用malloc无关紧要/>
它既简单又容易。但是在大型程序中,当你有很多其他需要担心的事情时,很高兴知道

你减少了返回的函数调用次数

void *。至少对我来说很高兴。类型不匹配

这是很平常的事(不幸的是),因为

我用类来处理很多,有嵌套结构

喜欢


struct Parent {...};

struct Child {struct Parent parent; ...};


它很容易搞砸,并且避免使用

额外的空虚*实际上是一件好事。请注意,这个

Child-Parent事情与malloc无关。但

它确实与使用错误的类型有很大关系。并且

我不会想到这是malloc,没有什么

与此相关,无效*在这里很好。我只是避免使用

void *。


现在并非所有人都认为ALLOCIT()购买任何类型的安全。

其他人确实认为它确实如此。


无论如何,很难与一个以上的人争论

,所以我决定发布什么我想这个

特别是是的,我想要演员*在这里*事情。你可能会说我想要C ++,你可能会说错误。,你可以用十步来证明它是错误的,无论如何。我至少

知道我不是唯一一个相信

的人铸就这个单身的东西所以我不是一个完整的

白痴。 (当然你可以说相信这个人b / b
都是白痴或错误的,但是工作软件证明他们不是b
。)


Yevgen

Consider the following macro:

#define ALLOCIT(Type) ((Type*) malloc (sizeof (Type)))

The intent is to wrap raw memory allocation of N bytes
into a macro which returns allocated chunk of memory
to be used as a Type structure.
The background: I was beaten many times (it surely
is not my exclusive experience) by functions which
return and accept void*. There are such functions,
and there are cases when you can''t do much about it
(third-party libraries, containers, etc.). I make
a conclusion: void* is evil and must be avoided when
possible and easy. Therefore I believe it''s better
to use above macro than raw malloc. And I think this
is a valid belief, not like believing in Santa or alive
Elvis.

In toy programs like posted here, when you do

int *func (void)
{
int *foo = malloc (10 * sizeof *foo);
...
}

it certainly doesn''t matter how you use malloc since
it''s small and easy. But in big programs, when you have
lot of other things to worry about, it''s nice to know
that you reduced number of function calls which return
void*. At least it''s nice to know for me. Type mismatch
here is quite a usual thing (unfortunately), since
I deal a lot with "classes", with nested structures
like

struct Parent {...};
struct Child {struct Parent parent; ...};

It''s extremely easy to mess it up, and avoiding using
extra void* is actually a good thing. Note that this
Child-Parent thing has nothing to do with malloc. But
it does have a lot to do with using wrong types. And
I don''t try to think like "this is malloc, has nothing
to do with that, void* is fine here". I just avoid using
void*.

Now not all people think that ALLOCIT() buys any type safety.
Some other people do think it does.

Anyway, it''s hard to argue with more than one person
at once, so I decided to post what I think about this
particular "yes I want cast *here*" thing. You may
say I want C++, you may say "Wrong.", you may prove
using ten steps that it''s wrong, whatever. I at least
know that I am not the only person who believes in
"cast is good in this single thing" so I am not a complete
idiot. (Of course you can say that people who believe this
are all idiots or wrong, but working software proves they
aren''t).

Yevgen

推荐答案

Yevgen Muntyan写道:

Yevgen Muntyan wrote:


背景:我被多次击打(肯定是
不是我的独家经验),其功能是

返回并接受void *。有这样的功能,

,有些情况下你不能做很多事情

(第三方图书馆,容器等)。我的结论是:

结论:void *是邪恶的,当

可能而且容易时,必须避免。
The background: I was beaten many times (it surely
is not my exclusive experience) by functions which
return and accept void*. There are such functions,
and there are cases when you can''t do much about it
(third-party libraries, containers, etc.). I make
a conclusion: void* is evil and must be avoided when
possible and easy.



你需要对void *感到满意。它是该语言中最强大的

类型之一。

You need to become comfortable with void *. It''s one of the most powerful
types available in the language.


Yevgen Muntyan写道:
Yevgen Muntyan wrote:

考虑以下宏:


#define ALLOCIT(Type)((Type *)malloc(sizeof(Type)))


目的是将N个字节的原始内存分配

包装到一个宏中,该宏返回分配的内存块

用作Type结构。
Consider the following macro:

#define ALLOCIT(Type) ((Type*) malloc (sizeof (Type)))

The intent is to wrap raw memory allocation of N bytes
into a macro which returns allocated chunk of memory
to be used as a Type structure.



如果它将被用作指向类型的指针,则需要初始化其

字段。为了可维护性

,字段应该初始化接近创建点b / b
。在这种情况下,将有一个正确类型的变量

,从

分配表达式初始化;所以ALLOCIT宏

几乎买不到任何东西,它买的东西很少,

我认为它与可能的编辑周期交易

当改变分配的类型时。


一次我希望它/可能/帮助是什么时候

通过mallocated商店作为参数为了
a函数,所以变量对手不是。但是

然后你将一个指向未初始化的指针

商店传递给一个函数,我将它放入

要求麻烦类别。

If it''s going to be used as a pointer-to-Type, its
fields need to be initialised. For maintainability
the fields should be initialised close to the point
of creation. In which case, there will be a variable
of the right type to hand, initialised from the
allocation expression; and so the ALLOCIT macro
buys you hardly anything, and what little it buys,
I think it trades off against an possible edit cycle
when changing the type of the allocation.

The one time I''d expect it /might/ help is when
passing the mallocated store as an argument to
a function, so the variable-to-hand isn''t. But
then you''re passing a pointer-to-uninitialised
store to a function, which I''d put into the
Asking For Trouble category.


背景:我被殴打多次(肯定是

不是我的独家经验) br />
返回并接受void *。
The background: I was beaten many times (it surely
is not my exclusive experience) by functions which
return and accept void*.



我不觉得/我曾经遇到过这个问题,但是......

I don''t /think/ I''ve ever had that problem, but ...


有这样的功能,

,有些情况下你不能做很多事情

(第三方图书馆,容器等)。
There are such functions,
and there are cases when you can''t do much about it
(third-party libraries, containers, etc.).



....我还没与很多人合作过(第三方

的东西,我的意思是:当然我有容器库。

如果他们有问题我会把它们包起来并完成。

.... I haven''t worked with many of those (third-party
thingies, I mean: of course I have container libraries).
Were they problematic I''d wrap them and be done.


我制作

a结论:void *是邪恶的,当

可能和容易时必须避免。因此我认为使用上面的宏比使用原始malloc更好


I make
a conclusion: void* is evil and must be avoided when
possible and easy. Therefore I believe it''s better
to use above macro than raw malloc.



我不认为它解决了一个有问题的问题。

I don''t think it solves an intersting problem.


在这里发布的玩具程序,当你做的时候


int * func(无效)

{

int * foo = malloc(10 * sizeof * foo) );

...

}


自从你使用malloc以来无关紧要

它小而简单。但是在大型程序中,当你有很多其他需要担心的事情时,很高兴知道

你减少了返回的函数调用次数

void *。
In toy programs like posted here, when you do

int *func (void)
{
int *foo = malloc (10 * sizeof *foo);
...
}

it certainly doesn''t matter how you use malloc since
it''s small and easy. But in big programs, when you have
lot of other things to worry about, it''s nice to know
that you reduced number of function calls which return
void*.



嗯。我没看到ALLOCIT宏如何帮助/

那里。打开包装?


-

Chris" electric hedgehog" Dollin

花了很长时间,比最慷慨的估计要长得多。

- James White,/ Sector General /

Um. I don''t see how the ALLOCIT macro helps /at all/
there. Unpack?

--
Chris "electric hedgehog" Dollin
"It took a very long time, much longer than the most generous estimates."
- James White, /Sector General/


2月9日14:52,Yevgen Muntyan< muntyan.removet ... @ tamu.eduwrote:
On 9 Feb, 14:52, Yevgen Muntyan <muntyan.removet...@tamu.eduwrote:

考虑以下宏:


#define ALLOCIT(类型)((类型*)malloc(sizeof(Type)))
Consider the following macro:

#define ALLOCIT(Type) ((Type*) malloc (sizeof (Type)))



好​​几百万点勇气......

well several million points for courage...


意图是包装N字节的原始内存分配

进入一个宏,返回分配的内存块

用作Type结构。

背景:我被殴打了很多次(肯定是

不是我的独家体验)

返回并接受void *的功能。
The intent is to wrap raw memory allocation of N bytes
into a macro which returns allocated chunk of memory
to be used as a Type structure.
The background: I was beaten many times (it surely
is not my exclusive experience) by functions which
return and accept void*.



你能给出一些例子吗?我无法看到一个函数

返回void *可以击败你。分配错误的类型?

could you give some examples? I can''t see how a function
returning void* can "beat you". Assign to the wrong type?


有这样的功能,

,有些情况下你不能做很多事情

(第三方库,容器等)。我的结论是:

结论:void *是邪恶的,当

可能而且容易时,必须避免。
There are such functions,
and there are cases when you can''t do much about it
(third-party libraries, containers, etc.). I make
a conclusion: void* is evil and must be avoided when
possible and easy.



我不会大量使用它,但我不会把它归为邪恶。

malloc()对我来说似乎没问题。

I don''t use it heavily, but I wouldn''t catagorise it as "evil".
malloc() seems ok to me.


因此我认为使用上面的宏比使用原始malloc更好

。我认为这是一个有效的信念,而不是相信圣诞老人或活着

猫王。
Therefore I believe it''s better
to use above macro than raw malloc. And I think this
is a valid belief, not like believing in Santa or alive
Elvis.



你可能有一些证据表明降低了bug或者b $ b的费率或者易用性或者你的宏。

well you presumably have some evidence of lowered bug
rates or ease of use or whatever for your macro.


在这里发布的玩具程序中,当你这么做时


int * func(void)

{

int * foo = malloc(10 * sizeof * foo);

...


}


无论你如何使用malloc都没关系,因为

它很小而且简单。但是在大型程序中,当你有很多其他需要担心的事情时,很高兴知道

你减少了返回的函数调用次数

void *。至少对我来说很高兴。类型不匹配

这是很平常的事(不幸的是),因为

我用类来处理很多,有嵌套结构

喜欢


struct Parent {...};

struct Child {struct Parent parent; ...};


它很容易搞砸,并且避免使用

额外的空虚*实际上是一件好事。
In toy programs like posted here, when you do

int *func (void)
{
int *foo = malloc (10 * sizeof *foo);
...

}

it certainly doesn''t matter how you use malloc since
it''s small and easy. But in big programs, when you have
lot of other things to worry about, it''s nice to know
that you reduced number of function calls which return
void*. At least it''s nice to know for me. Type mismatch
here is quite a usual thing (unfortunately), since
I deal a lot with "classes", with nested structures
like

struct Parent {...};
struct Child {struct Parent parent; ...};

It''s extremely easy to mess it up, and avoiding using
extra void* is actually a good thing.



我不明白为什么。在clc中成语:

父* p = malloc(sizeof * p);


用你的成语

父* p = ALLOCIT(父母);


因为你的版本有两个地方的类型我会说错误

*更多*可能。如果我的例子有误导,你可以建造一个更好的吗?


我不知道你的宏如何提高类型的安全性。

I don''t really see why. In "clc" idiom:
Parent *p = malloc (sizeof *p);

In your idiom
Parent *p = ALLOCIT (Parent);

Since your version has the type in two places I''d say an error
was *more* likely. If my example is misleading could you
construct a better one?

I don''t see how your macro improves type safety.


注意这个

Child-Parent事情与malloc无关。
Note that this
Child-Parent thing has nothing to do with malloc.



这让我很困惑。我认为这个讨论是关于malloc()的?

this confuses me. I thought this discussion was about malloc()?




它与使用错误的类型有很大关系。并且

我不会想到这是malloc,没有什么

与此相关,无效*在这里很好。
But
it does have a lot to do with using wrong types. And
I don''t try to think like "this is malloc, has nothing
to do with that, void* is fine here".



我不明白这一点。

I don''t understand this bit.


我只是避免使用void *。


现在并非所有人都认为ALLOCIT()购买任何类型的安全。

其他一些人确实认为它确实如此。


无论如何,很难与一个以上的人争论

,所以我决定发布我对此的看法

特别是是的我想要施放*这里*事情。你可能会说我想要C ++,你可能会说错误。,你可以用十步来证明它是错误的,无论如何。我至少

知道我不是唯一一个相信

的人铸就这个单身的东西所以我不是一个完整的

白痴。
I just avoid using void*.

Now not all people think that ALLOCIT() buys any type safety.
Some other people do think it does.

Anyway, it''s hard to argue with more than one person
at once, so I decided to post what I think about this
particular "yes I want cast *here*" thing. You may
say I want C++, you may say "Wrong.", you may prove
using ten steps that it''s wrong, whatever. I at least
know that I am not the only person who believes in
"cast is good in this single thing" so I am not a complete
idiot.



我可能最好提出一个合理的技术

参数。

I might be better to come up with a reasoned technical
argument.


(当然你可以说那些相信这个人b / b
都是白痴或错误的,但工作软件证明他们

不是) 。
(Of course you can say that people who believe this
are all idiots or wrong, but working software proves they
aren''t).



不一定。

well not necessarily. The cost in

中的费用

这篇关于#define ALLOCIT(Type)((Type *)malloc(sizeof(Type)))的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆