Is it really that necessary to use those fucking pointers when programming in C++?
Can I just pass variables in a similar fashion to Python or Ruby, except just defining the types explicitly?
>mfw pointers
There are two types of programmers.
Those who understand pointers.
And those who get picked up by their mom after work.
No you fucker. Either you understand how memory actually works, or you deal with languages with jiggabyte sized runtimes that have to constantly pause your program to wipe your ass (or in some cases leave you standing in a pile of your own shit until the manager of your daycare kicks you out), not that it'd be a good program anyway since you likely don't even understand the basics of computer science.
>>51311010
I understand them but I'm just lazy, years of Python and Ruby literally spoiled me.
Interestingly, the how variables should be passed is not that easy to answer, and depends on each particular case.
>>51311045
You musn't be lazy pointers are a most wonderful thing to have.
>>51311045
s/lazy/incompetent/
>>51311060
I've been asking myself many times what's the best or at least standard practice of doing this. Thanks for posting this anon.
>>51311045
you literally state in your OP that you don't understand how to use pointers
now you're lazy?
you think c++ is bad with pointers? try c faggot
>>51311249
I'm just learning them since i never had a reason to do that before using those other languages, i understood the basic concept.
I know about C, that's why I asked for C++, I read that raw pointers are actually discouraged with it.
>>51311091
they're literally useless and only kept around for legacy support. try to keep up grandpa
>>51310937
All dynamic memory allocations in C++ at some point require pointers to be used, although you can mask this somewhat by using wrapper classes like shared_ptr and such.
The larger the data value, the slower it will be to copy around. On the other hand a pointer is always fast enough to copy around. So for performance pointers and references are very important.
>>51311590
Confirmed for not understanding how pointers work.
I await more personal attacks.
>>51311222
There's a lot more best practices than just that there anon.
https://github.com/isocpp/CppCoreGuidelines
If you're using pointers in C++, you're doing it wrong.
>>51313704
If you're using C++ you're doing it wrong
>>51311436
>I read that raw pointers are actually discouraged with it.
True. If you're writing application code (which the majority here would probably be doing). At least don't use them in cases where you need to use the keyword 'new' in application code. Use smart pointers instead like std::unique_ptr<>.
Raw pointer usage is ofc needed for performance by library writers (for things like the STL). Let them handle the dirty work for you.
>>51312005
>mask this somewhat
like in 100% of application code?
>>51313710
What language should I use then? Requirements are no garbage collector and no or slim runtime (yes, --fno-rtti --fno-exceptions).
>>51313728
>std::unique_ptr<>
>>51313767
That's going to be the correct choice in most cases.
>>51310937a=*(void****)(((void**)a)+2*sizeof(void**));
with pointers you can write great efficient system independent code.
>>51313802
What on earth are the applications of using a quadruple void pointer?
Only use smart pointers when necessary, learn references, learn RAII, learn STL. Typically no, you don't need pointers and you definitely don't need raw pointers.
>>51313728
>>51314239
There is nothing wrong with pointers. What is discouraged though, is using naked new/delete malloc/free -- or any resource allocation for that matter.
Using *non-owning* pointers is completely fine, sometimes even necessary when you want to point at different things and/or say that the value may be optional (nullptr). For other cases use references (since they can't be null, you don't have to perform any checks for that).
>>51314567
>There is nothing wrong with pointers. What is discouraged though, is using naked new/delete malloc/free -- or any resource allocation for that matter.
Can someone explain this to me? I'm starting to play with C++ on a Particle Photon, and I come from a C, Obj-C, C# background. Why is manual memory management discouraged?
>>51314684
Because, in most cases, resource allocation requires explicit deallocation (a resource being memory, file, socket etc.) Through proper use of C++'s RAII you ensure that the resource is deallocated, no matter which code-path is taken (e.g. the variable holding the resource exits the scope or an exception is thrown or whatever).
This would be quite hard to achieve without RAII (or some runtime memory management like garbage collectors--but we don't want the runtime overhead...) and resource leaks are bound to happen sooner or later. This is obviously true for larger projects...when you're doing one new/delete pair in the whole program, you might as well get away with using just naked allocations.
>>51314986
>RAII
So basically a fancy name for garbage collection?
>>51315178
No. https://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
>>51315223
or this http://en.cppreference.com/w/cpp/language/raii
>>51315243
ty anon
>>51314165
Three-dimensional array of particles of different types with a standard interface.
I'm not sure why he's dereferencing the declaration of a function pointer though.
>>51314567
>What is discouraged though, is using naked new/delete malloc/free -- or any resource allocation for that matter.
Yea agreed, and I said as much or meant to. The fundamental issue is using owning pointers outside wrappers that depend on RAII. Observer-only pointers are fine.
Bjarne discusses this 'point' during his keynote this year.
https://www.youtube.com/watch?v=1OEu9C51K2A
The C++ Core Guidelines provide for a owner type that can be statically checked for just this purpose. MS has a working GSL that includes it.
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#S-gsl
>>51315178
Not at all. It's better known as 'never leak resources, period."
No garbage, no garbage collection.
>>51310937
>mfw pointers
its just yfw you cant program
>>51310937
Bcaz cross-language interprocessing historically uses C void* as a de facto means of communications. That's simply because C accidentally obtained a de facto stable ABI which everyone could develop against.
I just can't get my head around pointers
I know what they "do" but I can never find a clear answer on WHY you would use them
>>51321058
I feel you. You might look into this book anon.
http://shop.oreilly.com/product/0636920028000.do
Indirection is one of the moat fundamental concepts in CS. Pointera are powerful.
>>51321058
>I know what they "do" but I can never find a clear answer on WHY you would use them
Its pretty easy anon, say you have functionA() and functionB(), you want functionB() to modify TWO variables local to functionA(), in this situation you cant simply return a value (and the return would probably be used for error checking anyways). So you:int functionA()
{
int i = 0, ii = 0;
if(functionB(&i, &ii) == ERR)
return SOME_OTHER_ERR;
return NOERR;
}
void functionB(int *i, int *ii)
{
*i = 1;
*ii = 2;
return NO_ERR;
}
There are plenty of other situations such as blocks of memory (strings or whatever you're using malloc for).
>>51323155
>void functionB(int *i, int *ii)
well this shouldnt be void but you get the idea, I just woke up, forgive me
This is one of those things you should probably learn from Rust before shooting yourself in the foot in some other language.
