[badjava]

if you have a dynamic variable such as:
int *p1;

When you create a new dynamic variable to be pointed to by p1 you have to specify the type again such as:
p1 = new int;

Why refer to int again? Why not just be able to say
new p1;

As far as I can tell you can't do any spooky cast typing when creating (dunno about later when using it) the dynamic variable, I tried a few ways to use anything other than int in the 'new' statement and everything causes the compiler to throw an error.

Any ideas why this obvious type of redundancy exists?

[Bench]

int* is a pointer type, not a dynamic variable ("dynamic variables" or 'duck-typed' variables of the kind you might expect to see in Ruby or Python do not exist in C or C++ since its a strongly typed language)

edit re-written the post

There's several reasons why you need to specify the type after new

- When you call new, it creates a new object of a specific type - This involves both allocating memory, and calling a constructor. Without having a type specified after new, there would be absolutely no way to tell what constructor to use. Even built in types have a 'hidden' constructor, used as part of initialisation. for example

int i(5);

is almost the same as

int i = 5

except the copy-assignment is effectively optimised out (most compilers will do that anyway, but this is a way of doing it explicitly).

you can do the same with new

int* p1 = new int(5);

-This becomes even more important with OO class structures, where its common to have derived class objects pointed-to by a base-class pointer

class base {};
class derived : public base {};

int main()
{
    base* p1 = new derived;
} 

new can also be used for creating multiple objects of the same type in memory - a.k.a an array

int* p1 = new int[5];

If you wanted to fiddle about, you could even create an object of a different type using new, and assign it to the pointer (though this is usually undefined behaviour, and not reccomended)

int* p1 = reinterpret_cast<int*>( new char[sizeof(int)] );

This post has been edited by Bench: 06 December 2008 - 07:04 AM

[badjava]

Bench, on 6 Dec, 2008 - 05:40 AM, said:

From a simple language parsing perspective, Its not redundancy, because int*, the type of p1, is a completely different type to int. Of course you could argue that new always returns a pointer, however, new isn't required to check that the pointer it returns is necessarily going to be assigned to anything - so it would be possible to write a program where there'd be no assignment or initialisation involved

Pondering the int* != int, I think I get that. Trying to visualize the second part of that paragraph where you don't assign the pointer to anything, I don't yet see how you could get away with that syntax-wise.

Quote

There's another, far more widely-used reason - You might want to use new to put aside enough space for multiple int objects

int* p1;
p1 = new int[5]; 

Without this, dynamically allocated arrays would be a problem

But even with your above explanation and this example of pre-allocating resources, as far as I understand you can't put ANYthing but int in the second line of this statement without throwing a compiler error. The two types specified have to be exactly the same yes? One thought I had was maybe you have to specify the type in two places to make it harder for the programmer to try to create or call one later with the wrong type or in the wrong way in general since "new p1" was out there somewhere with no type and who knew what it was?

Thank you for the very detailed explanation! I'm sure I will understand this more as I continue.

[janotte]

I really think you are running a serious risk of 'teaching yourself' some really faulty concepts if you just flail around in this area without some fundamental grounding.

I'd seriously suggest pausing now and going and reading some good material on pointers.

Then your experiments will have some solid foundation. I think you may be building on sand just now and the rubble when that collapses may get in your way in the long-term.

[Bench]

I actually re-wrote this post completely after you began replying - Perhaps it makes a little more sense now.

badjava, on 6 Dec, 2008 - 02:04 PM, said:

Pondering the int* != int, I think I get that. Trying to visualize the second part of that paragraph where you don't assign the pointer to anything, I don't yet see how you could get away with that syntax-wise.

Very easily in fact. this program is valid

int main()
{
    new int;
}

I can't think of any normal circumstances where this would be a good idea, though.

badjava, on 6 Dec, 2008 - 02:04 PM, said:

as far as I understand you can't put ANYthing but int in the second line of this statement without throwing a compiler error.

When the type is int, you would need a cast to avoid warnings/errors (Its not impossible just harder - C/C++ have ways of letting you do almost anything you want, provided you know the dangers first). However with class types its less clear-cut, since you can neatly fit derived-class pointers into base-class pointers - in fact, polymorphism can't happen without it

This post has been edited by Bench: 06 December 2008 - 07:13 AM

[badjava]

janotte, on 6 Dec, 2008 - 06:10 AM, said:

I'd seriously suggest pausing now and going and reading some good material on pointers.

Oh yah, I'm reading my textbook and basically throwing firecrackers around with my compiler to see what happens and experiment a bit to see how it works as I get ready for the next assignment (due monday ugh).

TY tho

P.S. I also switched to Gordon Highlanders - The Bagpipes & Drums of Scotland, and my brain seems to be working better than when I was pounding out z Rammstein

Bench, on 6 Dec, 2008 - 06:10 AM, said:

Very easily in fact. this program is valid

int main()
{
    new int;
}

I can't think of any normal circumstances where this would be a good idea, though.

Whoa

Quote

When the type is int, you would need a cast to avoid warnings/errors (Its not impossible just harder - C/C++ have ways of letting you do almost anything you want, provided you know the dangers first). However with class types its less clear-cut, since you can neatly fit derived-class pointers into base-class pointers - in fact, polymorphism can't happen without it

This makes a lot more sense after reading all of your posts, even though I don't know how to implement any type of polymorphism or custom classes even, classes are the next chapter! I think I have a good sense of the ideas behind it now, awesome info ty.

[baavgai]

It's important to realize that the type notation in the pointer declaration defines the behavior of the pointer. However, a pointer is ultimately just a reference to a memory location. What's really at that location is unknown unless you properly tell it.

You can fake out pointers with little effort. This is the programmer knowing what they're doing part.

For example:

int n, *pn;
float f = 3.14;
void *huh; // this is a non typed pointer

pn = &n; // now we're pointing to n
n = 5;
printf("%d\n", *pn); // this prints 5

huh = &n; // now we're pointing to n
// we have to do a little dance to explicitly say
// the type we want the void pointer to behave
// like an int pointer
printf("%d\n", *((int *)huh)); // this prints 5

huh = &f; // now we're pointing to f
printf("%f\n", *((float *)huh)); // this prints 3.14

pn = (int *)&f; // fake out
printf("%d\n", *pn); // this prints garbage
printf("%f\n", *((float *)pn)); // this prints 3.14

As you can see, the declaration of "int *pn" really just defines how the program treats the pointer.

Hope this helps.

[badjava]

baavgai, on 6 Dec, 2008 - 01:58 PM, said:

As you can see, the declaration of "int *pn" really just defines how the program treats the pointer.

Hope this helps.

The lights are so pretty...look at the pretty lights...

About half way through this I started feeling like C++ was really a snow job, that there is something else hiding behind the code, and that maybe I should take the red pill.

[baavgai]

badjava, on 7 Dec, 2008 - 01:29 AM, said:

The lights are so pretty...look at the pretty lights...

LOL!

It's all just bits. At the memory level, the computer stores data in blocks of 0s and 1s, usually referenced in 8bit clusters for ease of use. That you arbitrarily pic 8 or 16 or 32 or 64 of those bits and pretend is some kind of number, or perhaps a machine instruction, or some characters; that's at the whim of the code.

All languages do this. At the level of the CPU, the machine itself does this. It's part of the fun of C that it reveals more of what's behind the curtain than most.

Make your next language Assembly and feel the burn.

[badjava]

baavgai, on 7 Dec, 2008 - 03:47 AM, said:

Make your next language Assembly and feel the burn.

Back in my first uni days I was terrified of assembler and avoided it like the plague. Nowadays I'm intrigued and tried to justify fitting it in to my last semester

Some day when I'm feeling really masochistic I'll have to give it a go.

The funny thing at the time btw was the people taking RPG, they were bitching a LOT more about their coding problems with their rulers and column counting, more so than the ppl doing asm. HAH! take that you business geek types!

This post has been edited by badjava: 07 December 2008 - 05:01 AM

[janotte]

If you are starting to see the power that C/C++ gives you through more direct access to "the metal" than Java allows (running in its nice safe VM) and the opportunities, dangers and double abstractions that this allows then you are ready to appreciate this article.

http://www.joelonsof...avaSchools.html

I don't agree with everything in there but it's good for provoking thought and discussion.

It's not that Java is bad. It's just that some of the stuff it can't do are things that teach you a lot about how computers really work. If someone has a CompSci degree and they have only ever used Java they haven't yet been exposed to some powerful ideas that really allow you to see things in a different way.

[KYA]

Which is why I go out of my way to take CS classes that don't use java.

[baavgai]

As someone who's done large projects in "powerful" languages, I quite prefer to do them in things like Java or C#. I know what those languages are doing for me and, having had to do it manually in the past, I really appreciate it. I think that's probably the rub; I know what they're doing for me.

It's possible to write perfectly good programs without understanding the impact of what's being done. The more you abstract it, the less you're in a position to grasp it. The other day I wrote this code:

if ((n/d)==floor(n/d)) {

Speed was important and I instantly rewrote it as

t = n/d;
if (t==floor(t)) {

The reason is that allocating storage outside the loop and putting the results in that location once was less costly than doing the calculation twice. These kind of habits come from understanding that operations cost something and storage costs something. The higher languages allow the programmer to not worry about such things. I really don't know if that's good, but I don't have a real solution beyond simple education.

Some languages allow you to shoot yourself in the foot, others do the best they can to stop you. No one wants to loose a toe, but there are occasions where useful to be able to blow a toenail off...