return pointer type

[technologist]

Is there any function/way to return the type of a pointer?

...
int value = 5;
void *void_ptr = &value;
//here
int * int_pointer = static_cast<int*>(void_ptr);
//here
cout<<*int_pointer;
...

[cire]

The tags are not <code><code/>, but [code][/code].

If you're asking if it is possible to determine the type of object that an arbitrary void pointer references, no. You must keep track of the type yourself.

[technologist]

As per <code><code/> a lot of the time the format buttons don't work and I have to do it from memory. In this case I just messed up. Sorry

No, I mean once its cast. In fact it doesn't even have to be a void pointer cast to a type. In can be a generic pointer, eg:

int * n_ptr = & value

Is there any function/was to return the type of this pointer?

I understand about keeping track of your pointers with void * ptr

[cire]

Is there any function/was to return the type of this pointer?

The type of that pointer is right there in front of you. It's a pointer-to-int. I don't think I'm understanding what you're asking.

[technologist]

Sorry I meant a pointer deeper in the program:

n_ptr = &value

etc.

[TheIdeasMan]

Hi,

Is any of this helpful?

http://en.cppreference.com/w/cpp/types

All that is C++, your question seems to be C related? With C++ there is rarely a need to use raw pointers.

I get how you are after a deep understanding of how things work "under the hood", just wondering why you would want to find the type of a pointer in a C program? With C programming, one is "out in the cold " a lot more: that is, the coder is responsible for taking care of just about everything that might go wrong; and there seems to be much less facilities available to do so (compared to C++). I guess that's why C is used for more low level programming.

With C++ and the STL, there are much more bells & whistles: The STL objects take care of themselves in a lot of ways, and are designed to take a lot of low level "pain" away.

Also, one can achieve a lot with polymorphism, and requiring to find out a type, or having to cast often means bad design. Of course there will be situations where these things are necessary, and there are the subjects of templates and Template Meta Programming (TMP). The type traits functionality is achieved with TMP.

Any way, I hope all this has been of some use, even if only a little :+)

http://en.cppreference.com/w/cpp/language/type
http://en.cppreference.com/w/c/language/type

[technologist]

This was helpful and encouraging thank you.

With more of the C++ language I learn I sometimes feel like I am learning more language than "how things work under the hood". Its just a checking behavior to make sure what I have learned is tangible and not just syntax. I am starting to learn that C++ is there for a reason, and some of that is protection from "pain" of low level languages (lower than c++). Having said that maybe someday I ought to try ASM.

I did some SX assembly programming and I have an itch to scratchwith regards to ASM. But the more I look at that OMG its light years ahead of SX and that's what c++ was invented in the meantime.

The raw pointers et al. are just for exercise sakes -- STL, TMP, etc, is on the horizon.

I guess it sometimes pays to appreciate C++ by experiencing the "pain" of lower level languages. I think I'll take everyone's word for it. : )

[TheIdeasMan]

I am starting to learn that C++ is there for a reason, and some of that is protection from "pain" of low level languages (lower than c++). Having said that maybe someday I ought to try ASM.

The thing is, C and C++ are quite different animals.

C is a procedural language, so there are all these functions which do quite simple things. These functions might not have bounds checking, may not be type safe, and may not be thread safe. It is up to the coder to make sure things work as intended.

On the other hand, C++ has all kinds of things to make life easier. In terms of the language itself, there is function & operator overloading, classes, OOP, virtual polymorphism (runtime), exceptions, templates, static polymorphism (compile time), TMP.

Then there is the STL. One can achieve huge amounts by just using the STL containers and algorithms. These do have bounds checking, are type & thread safe, so this is one example of where the coder is spared the low level "pain". The STL is tremendously convenient in terms of functionality, especially with the algorithms.

And there are third party libraries like boost and juce for example, these have even more really good stuff.

Also, there are design patterns which can aid in writing quality scalable software.

I did some SX assembly programming and I have an itch to scratchwith regards to ASM. But the more I look at that OMG its light years ahead of SX and that's what c++ was invented in the meantime.

Crikey, ASM is light years ahead of SX? Well you should fit into ASM quite easy then, maybe you should do some of that, followed by C, then C++ - although that would be a long hard road, it would certainly make for a well rounded education. I have thought that a really good course would involve detailed work with (every aspect of) ASM, C, Data structures & algorithms, C++, STL, TMP, Boost, Design Patterns, compiler implementation. Not sure if such a course exists :+)

Btw, there were a plethora of languages invented long before C++, including some OO ones. If one was only looking at the evolution of the C family, then C came much earlier than C++.

http://en.cppreference.com/w/c/language/history
http://en.cppreference.com/w/cpp/language/history

cppreference is a good site, it has detailed technical descriptions of C++. It is taken from the C++ standards, and is much easier to understand than reading the standard directly. I like it because it doesn't gloss over things like some other sites do. However it is good to look to look at the reference material here too, then go to cppreference for the detail.

I guess it sometimes pays to appreciate C++ by experiencing the "pain" of lower level languages. I think I'll take everyone's word for it. : )

For me, I taught myself C from K&R "C Programming" book, then was less than impressed by having to learn Fortran77 at uni, similarly with Pascal. Wasn't until years later that I learnt some ASM - a lot things clicked then. After playing around with others things like UNIX shell scripting, RDMS, VBA, I started on C++. Well that was a massive jump forward, so much capability there. I probably should learn another language such as D or Java, but at the moment there is always plenty more to learn with C++.

Probably immoral to post this, but you could buy probably quite cheap (it's not a big book, and is old). It's good to have an actual paper book :+)

http://zanasi.chem.unisa.it/download/C.pdf