return a pointer is not important as long as you store in the corresponding pointer type that you wanna work with , im correct ?
Casting is not required at all. In fact it is not recommended because you repeat yourself.
In C, yes, in C++, it is required. Reason is, in C++, any pointer, T*, can be implicitly converted to a void*, but an explicit cast is required to convert from void* to a point of a specific data type, T*.
In C, yes, in C++, it is required. Reason is, in C++, any pointer, T*, can be implicitly converted to a void*, but an explicit cast is required to convert from void* to a pointer of a specific type, T*.
Why would you use malloc in C++?
Simplest way to allocate 😎
new is much more simpler than malloc.
yes but no
That definitely clarified a lot for me
new its c++ thing malloc its more c thing than c++
And your point is? I said new should be preferred in C++.
gcc, clang and other "compilers" perform automatic type conversion, and its not portable for all systems. BTW, turning off this feature show how the compiler works and improve our skill
C99 and beyond requires implicit casting from void* to any other data pointer. So if an implementation doesn't support it, it is not standard compliant. When an implicit conversion is supported and it is lossless, there is no reason why you should make it an explicit cast. You are just repeating yourself with no added benefit.
I would not, but but some people do (just check Q&A sites) and it is provided by the standard, so the clarification had to be made.
Oh, to build onto my previous answer, some implementations of new used to (still do?) us malloc internally for the actual memory allocation. There are people who build highly custom memory allocation facilities for given environments and constraints, and some might overload new and delete. You can be sure that for those cases, they will probably use malloc internally at some point, cause the whole point is to provide alternatives for the default new and delete. That is a pretty solid use case for malloc and free in C++.
Not all systems are standard compliant, lot have only "some" compatibility
Why not just use mmap, VirtualAlloc, etc?
I agree. But most of the people who write their own allocators or overload operator new (the only ones who use malloc) would already know that they have to use an explicit cast for the return value from malloc
Can you give me an example of a system where the implicit conversion from void* to a data pointer of any type fails. I am really curious because this is so fundamental for the working of everything from an written in C to embedded and IoT world.
First thing to ask in such scenarios is, are they general purpose memory allocators, like malloc, or do they serve a very specific use case? Do they suit the use case for the memory allocation scheme one desires? Then wrap them in a proper RAII interface and use them to your content. However, remember, we are talking about why someone would use malloc in C++ instead of operator new, hence the explanation in my previous message. Can mmap and VirtualAlloc be used to develop a general purpose operator new that is then provided as part of a standards compliant C++ implementation? I mentioned that some implementations of the default C++ operator new used to (still do?) use malloc internally for the actual memory allocation. Your two functions serve specific use cases, while malloc is more general and available. This is a simple yet interesting thread on this very topic, https://www.gamedev.net/forums/topic/708119-two-questions-regarding-virtualalloc-windows-and-mmap-linux/
"proper" and "RAII" at the same time heh, seems kind of... paradoxical
I don't consider RAII to be "proper"
What do you consider it to be?
8 bit pic microcontrollers. They use memory bank approach with several bits of selection inside the main register. When you use void* to encapsulate or hide data, it will be rougly translate for the address of that specific bank. You must use far void * to force the compiler will save those bits of bank selection. That obscure bugs gave me gray hair 😆
I see your point but I think you meant malloc being more accessible instead of general since mmap, VirtualAlloc, these functions get memory directly from the operating system. To be exact glibc's malloc implementation has a structure called arena which contains linked list of sub divided memory regions (called a chunk) called a free list. These chunks are what given to the application when memory is requested.
Interesting. Well, it is the major bedrock of sane and safe C++ as far as system resources are concerned, so I strongly disagree with you. However, to each his own, though I would be interested in hearing how you personally deal with the scenarios it is usually employed in. Hold on. Do you use C++, or are you on this channel for C?
I do use C++ when I have to, but I don't really use most of the features (constructors, destructors, templates, ...)
I generally use DoD-style approaches where possible, so I use shared lifetimes and multiple allocators
Those are the features you don't use or the ones you do use?
The ones I don't use
Ah. This explains your unappreciation for RAII.
Обсуждают сегодня