Talk:C dynamic memory allocation/Archive 2

Archive 1

Archive 2

Renaming the page to a more general title

Based on talk at Talk:C standard library#Pages for each function and WP:NOTMANUAL

The scope of the article is a lot larger than a single function. The article also covers calloc, free, memset and realloc along with general information on dynamically allocating memory in C. I think moving the article to Dynamic memory management in C and making the necessary changes (redoing the lede, rewording some stuff) is a good first step. C++ adds a lot of complications in addition to new/new[] like smart pointers and destructors so merging that stuff into here should be a separate conversation (I don't think we should). strcat (talk) 05:37, 7 October 2011 (UTC)

I think a better title would be C memory management. It is shorter and consistent with existing C input/output, C string, etc., as well as with Memory management. A page titled Dynamic memory management also exists, but it discuss the same topic, so I proposed it to be merged into Memory management.1exec1 (talk) 20:41, 8 October 2011 (UTC)

alloc.h

I do not think alloc.h can be merged with Memory management page. Memory management page talks about general memory management issues in computer science. On the other hand, alloc.h falls under C library. This is not a standard C header file. This page describes functions in alloc.h briefly and tells about the difference between these functions and general C functions. Hence, according to C header category, in my opinion, alloc.h can not be merged with Memory management.AshishDandekar7 (talk) 02:36, 5 October 2011 (UTC)

Well, alloc.h is actually a good example of page that we want to avoid. The content is not notable and fails WP:NOTMANUAL, i.e. most of the content is usable only for a programmer. Having said that, I think we can find a solution that is acceptable for you. I see that you participate in an ongoing project in which most of the pages we are going to merge are assigned as homeworks. We can wait until the deadline (October 25th) for these homeworks passes and to apply our changes after that. What do you think?1exec1 (talk) 11:38, 5 October 2011 (UTC)

I am fine with your proposal. But I am not understanding clearly, why Wikipedia can not have technical stuff? I have read WP:NOTMANUAL. But I am thinking about its reason.AshishDandekar7 (talk) 07:48, 6 October 2011 (UTC)

Well, technical stuff itself is perfectly legal. However, it matters what the content is. I'm not an expert in wikipedia policies, but it seems wikipedia attitude is that wikipedia is for general public and thus anything that is significant only for very limited group of people should be avoided (thus we have notability criteria). This applies not only to the content itself, but for writing style also, so, for example, it is discouraged to write in very technical (i.e. not understandable for general public) style even in the technical articles. Now, regarding the manuals, what we don't like, is the pages like this, which can be interesting only to a programmer, who is about to use that function. This is pretty much the only problem.1exec1 (talk) 12:12, 7 October 2011 (UTC)

The alloc.h header could at least be mentioned on Memory management, unless there’s a more appropriate topic. (Dynamic memory allocation perhaps?) We can leave the page alloc.h as a redirect that is still a member of Category:C headers if you like; see how the memcmp redirect appears in italics in Category:C standard library.

 The alloca function is probably worth a mention somewhere like Stack-based memory allocation, including its history, problems implementing it and why it is common but isn’t really standardised. The other functions currently tabled should go somewhere common to avoid duplication with malloc. The other bits seem to be only related to special TIGCC functions which are not actually mentioned in the alloc.h page as far as I can see. Vadmium (talk, contribs) 12:53, 5 October 2011 (UTC).

• Oppose rename. I think malloc is and should be a much narrower topic than "memory management" (or variations), even with some discussion of its allied calloc and realloc routines included. Memory management is a very broader term and invites discussion of allocation strategies (best fit, first fit, buddy system, etc., etc.) that most people who only want to know about malloc probably don't care about (precisely because the whole point of malloc is to hide that stuff). Sometimes we'll have somewhat overlapping articles. I don't think that's always terrible. Msnicki (talk) 02:52, 9 October 2011 (UTC)

I disagree. We can divide most of the material in the article into two groups: a) tutorials, examples, basically a manual how to use various functions; b) discussion about different allocation strategies. The content of the former group is forbidden by WP:NOTMANUAL, and in this discussion it was agreed to remove such material. The latter group discusses precisely the same topic, as you agreed memory allocation should discuss, so we can merge the articles.1exec1 (talk) 17:16, 9 October 2011 (UTC)

That's not what I'm proposing. An article about malloc can certainly give an encyclopedic discussion of that topic and that topic only, without turning into a man page. I know what I'd expect to find if I'd heard the term and didn't understand it: I'd expect it to answer the who, what, when, where and why questions to extent any of these was matter in understanding what this is. If I wanted to know more, about how allocation strategies differ and how the algorithms worked, I'd expect that in article about allocation strategies, not right here.
Personally, I do not like the examples in this article. This is way too much WP:HOWTO. I think it's possible to describe software interfaces in an encyclopedic manner but I don't think this is it. Compare the way technical detail is presented here to the way it's done in the C shell article, where all the control structures, etc., are described in fairly complete detail, but it's done conceptually, not with examples. (Proper credit: the format was borrowed from Joy's original paper, "An Introduction to the C shell".) Msnicki (talk) 18:17, 9 October 2011 (UTC)

Argh, I must have confused myself. I am actually against merging with Memory management (see my first comment), but since I am involved in quite a lot of merge discussions, and didn't bother to recheck what I'm arguing for, I managed to find argumentation even for the opposite! LOL.

I agree with your points, there are strong reasons against the merge and even if my above (now deleted) arguments make some sense, they are weak. I was proposing to move the article to C memory management and to merge all articles about this topic to there. What do you think about that?1exec1 (talk) 22:16, 9 October 2011 (UTC)

I agree with you that this article covers a narrower topic than "C memory management" because it focuses specifically on dynamic memory allocation within C. When I proposed the move, I had the move template suggesting a move to Dynamic memory allocation in C (1exec proposed C memory management instead). I think malloc is a reasonable name for the article, but the topic is a bit broader than a specific function from the small family of functions that are used. strcat (talk) 22:29, 9 October 2011 (UTC)

I still disagree with any name change. I don't think there is a valid notable topic in between Malloc and Memory management or Dynamic memory allocation focusing just on C. Malloc is the C run-time library routine. The more general topic of memory management really isn't tied to any particular language, it's about strategies and algorithms that might be employed by the designer of a language, run-time library or OS. I concede that a big problem here is that those other articles are just awful and don't actually talk about strategies and algorithms. But that's a problem for those articles, not this one. Msnicki (talk) 22:54, 9 October 2011 (UTC)

I don't think that this article discusses only Malloc as you seem to allege. If we took it apart and analyzed section by section, you'd see that only small part of the article discusses malloc, the C standard library function:

Rationale - dynamic memory allocation. Discusses rationale for dynamic memory management but not rationale for malloc as a method of dynamic memory allocation

Dynamic memory allocation in C - malloc/free

Usage - malloc

Type safety - malloc

Related functions - calloc, realloc

Common errors - dynamic memory allocation. These problems are inherent to any manual memory management method.

Implementations - dynamic memory allocation. These algorithms can be employed as a backend for almost any memory allocation interface.

1exec1 (talk) 23:33, 9 October 2011 (UTC)

These are problems to be fixed by making this article better. Msnicki (talk) 23:44, 9 October 2011 (UTC)

To me, C memory management could also refer to storage classes in C, static variables, static memory allocation, automatic variables, stack-based memory allocation. I’m thinking this article should perhaps be about dynamic memory allocation in the C standard library, as used by all the functions that return a buffer that has to eventually be passed to free. But that’s rather unweildy; malloc certainly isn’t perfect; maybe Dynamic memory management in C is a compromise; I can’t think of much better :P. Vadmium (talk, contribs) 14:30, 12 October 2011 (UTC).

Hmm, after some thought, I agree that C memory management is too broad. However I find that in C at the end of Dynamic memory management in C somewhat odd, since it breaks consistency with C input/output, C string, C mathematical operations, etc. Maybe we can use C dynamic memory allocation?1exec1 (talk) 18:01, 12 October 2011 (UTC)

C dynamic memory allocation is also a subcategory of C memory management. These files are the outlines of how the dynamic memory allocation is achieved in C. alloc.h is a header file. Header files must have different page because they do not give the concept but the information about the functions and how they work.alloc.h is not telling "what is memory management in C?" but it tells how the memory is managed by using functions in it. So I do think, header files should not be merged.AshishDandekar7 (talk) 06:17, 14 October 2011 (UTC)

No, WP:NOTMANUAL explicitly forbids information about how to use functions, a.k.a. manual. Also, we agreed that we don't want such pages in this discussion. Having said that, the content won't disappear anywhere, since we will import it to Wikibooks before merging. 1exec1 (talk) 11:58, 14 October 2011 (UTC)