Archived

This topic is now archived and is closed to further replies.

AbsolutDew

strange? pointer error

Recommended Posts

When i compile my program I get a warning about some variable not being initialized, ie char* szSomeString. So i set it rewrite it as char* szSomeString = NULL, compiles fine, no warnings, but crashed during execution with the usual helpful windows error code. Anyone know some possible causes?

Share this post


Link to post
Share on other sites

  
char* szTextBuffer;

SendMessage( IMWatchList[x].GetIMRecvHwnd(), WM_GETTEXT, (WPARAM)iLength, (LPARAM)szTextBuffer );

string strTextBuffer = szTextBuffer;


that''s what im doing, i was under the impression i didn''t need to allocate memory when using it like this. But im occasionally wrong

Share this post


Link to post
Share on other sites
you always have to allocate memory for things. the only time you dont is if the function takes a char**, so it can actually return the address to you. if your not sure wether you need to allocate memory, you allocate it. ALWAYS free that memory. if you dont, then you might as well get some corks, cause your app will be leaking something awful.

RTFM when it comes to using functions. actually read what the function does. understand what the args are for.

this is why i *HATE* ppl overusing STL. they neglect important issues when using C fucntions because its all handled for them.

if you dont want to allocate memory, the declare szTextBuffer as
char szTextBuffer[1024];
then its plopped on the stacka nd the compiler worries about allocation, deallocation.

Share this post


Link to post
Share on other sites
How do we not overuse STL? If we decide to use STL in a project, we should standardise it or your code won''t be consistent. Though when it comes to win32 programming, you can''t use string but I do know how to use them. I know how linked lists works but implementing my own will only serve to confuse other programmers using STL.

Share this post


Link to post
Share on other sites
quote:
Original post by a person
this is why i *HATE* ppl overusing STL. they neglect important issues when using C fucntions because its all handled for them.

How much use is overuse? How much of a low-level must we descend to before our code is acceptable to you? What does the STL have to do with C functions, C being an entirely different language?


[ C++ FAQ Lite | ACCU | Boost | Python | Agile Manifesto! ]

[edited by - SabreMan on May 1, 2002 8:39:04 AM]

Share this post


Link to post
Share on other sites
c style fucntions dont accept stl objects. plain and simple. win32 api uses c style styntax. you dont need to use ANY low level code. its just silly to use STL for everything, yet dont understand simple concepts like pointers. i am all for ppl using STL for everything if it is effeicent and works for them, but i dislike ppl using STL when they are using it so they dont have to understand the concepts that STL hides. pointers and memory allocation is a very important concept that sometimes gets lost with STL since it tends to automagically handle most memory management for you. not a problem when undertsand this, and when using the win32 api you can handle memory allocation that may be required for a function.

i am in no way critizing STL use by expierenced coders who know what they are doing. i am critizing overuse of STL by newbies so they can make things quicker without understand the fundamentals.

sabreman, c is not entirly different language. it can be sued along side c++ code. it is used by the win32 api, and other ocde that wants to be easily used from within a c compiler without hacks. the win32 api is OO, but does not use c++. instead using c and encapsulating things using handles to the objects. a window ia an object, it has methods you can call. the difference is that the win32 api was designed with a functional compiler vs an OO compiler in mind. because of this, you have to deal with string allocation, using functions on pointers to change an objects attribute, etc. this is why MFC was created, to hide the c syntax chosen for the win32 api. it have an completely OO approach to most of the api with c++ syntax. now instead of using a char*, you would use a CString. the methods would handle the internal conversions required.

please ponder the following: would you stop using the win32 api and switch to MFC for everything you can use it for? then you can not worry about silly things like char* within most win32 api fucntions. maybe writing an stl wrapper for win32 functions might be in order. then you can stick to completly standard STL objects when dealing with the win32 api. though to write such a wrapper you need to understand what STL is doing under the hood to an extent and be able to take the data stored within the STL object and "convert" it for use within the OO C based win32 api.

such a rant should help answer your questions sabreman. again, i dont care if ppl use STL to solve even the smallest of problems. overuse comes when you use it because you dont understand something, and its a way to hide that (like not understanding concepts like pointers and data storage). perhaps i should have made the previous message clearer. I *HATE* when ppl neglect to understand important fundamental concepts of programming because they use overuse STL. is that better?

Share this post


Link to post
Share on other sites
quote:
Original post by a person
c style fucntions dont accept stl objects. plain and simple.

Yes, but the STL is for C++ programs. If you need to interface with C functions, then it caters for that up to a point.
quote:

i am all for ppl using STL for everything if it is effeicent and works for them, but i dislike ppl using STL when they are using it so they dont have to understand the concepts that STL hides.

OTOH, it is more productive to learn about language concepts when you need them. There is no point teaching a newbie all about confusing pointer and memory management concepts when all he wants to do is, say, write a few strings to a file. You teach the simpler concepts first, the harder ones when they are necessary.
quote:

pointers and memory allocation is a very important concept that sometimes gets lost with STL since it tends to automagically handle most memory management for you.

Good. The less I see of pointers and manual memory management in my code, the happier I am. There are loads of languages where you can do a lot of productive work without ever being exposed to a pointer. Pointers are only important when a better alternative is not available.
quote:

i am in no way critizing STL use by expierenced coders who know what they are doing. i am critizing overuse of STL by newbies so they can make things quicker without understand the fundamentals.

I'd say it's more crucial for a newbie to make things quicker without understanding unnecessary concepts. I go as far as to say C and C++ are terrible languages for newbies to learn programming. C++ isn't actually that bad, but this elitist nonsense about having to learn pointers and memory management first is damaging both to C++, and to the newbie trying to find his way.
quote:

sabreman, c is not entirly different language. it can be sued along side c++ code.

C and C++ are maintained by two distinct ISO working groups. Despite C++ having it's roots in C, it has a distinctly different grammar, and the recommended idioms for each language are incredibly different. To give you an idea of how different they really are, read this: Learning C++ as a new language.
quote:

please ponder the following: would you stop using the win32 api and switch to MFC for everything you can use it for?

Mwah-ha-ha! That's a different issue.
quote:

such a rant should help answer your questions sabreman.

It makes me think that what you have said is ill-considered. C++ is not C with knobs on. It's very different.
quote:

overuse comes when you use it because you dont understand something, and its a way to hide that

Rubbish! Perhaps you would say that you should not use, say, COM if you don't know all the details of how it works? Maybe you shouldn't use your compiler if you can't read and understand all the ASM that it generates. Perhaps you shouldn't use your operating system if you haven't written one yourself. Do you see where your argument leads? There is no reason to make someone learn something that they don't yet need.


[ C++ FAQ Lite | ACCU | Boost | Python | Agile Manifesto! ]

[edited by - SabreMan on May 1, 2002 4:04:39 PM]

Share this post


Link to post
Share on other sites
You know, most beginners'' instruction languages don''t teach "basics" like pointers - BASIC, Pascal... And that''s why Java is also gaining steam as an intro language. If C++ was taught with the STL from the ground up, with lower level concepts being introduced later, we''d have better C++ programmers overall.

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ ]
[ MS RTFM [MSDN] | SGI STL Docs | Boost ]
[ Google! | Asking Smart Questions | Jargon File ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
In defense of myself i'd like to say im very new to STL, and i'm quite comfortable with not using it, what i didn't understand was the char* szSomeVar syntax. I was under the impression it's size was determined at run time, and then could not be changed after that.

And what do you mean by read the fucking manual? I wasn't asking how to use a function, im aware i need a c string.

[edited by - absolutdew on May 1, 2002 7:12:43 PM]

Share this post


Link to post
Share on other sites
The manual would have told you that your pointer to char buffer must point to allocated memory for WM_GETTEXT.

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ ]
[ MS RTFM [MSDN] | SGI STL Docs | Boost ]
[ Google! | Asking Smart Questions | Jargon File ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
BTW Why can't you use strings with C functions?



void SomeFunction(const char* pString)
{
// do something with pString
}

void SomeOtherFunction(char* pString, int length)
{
// this will modify the string
}

void SomeOtherOtherFunction(char** pString)
{
// allocate memory for pString
}

int SomeWin32Function(char* pString, int length)
{
// do something
}

int main()
{
std::string test("Some text");

SomeFunction(test.c_str());
SomeOtherFunction(&test[0], test.length()); // unfortunate but necessary

char* p = 0;
SomeOtherOtherFunction(&p);
test = p;
delete [] p; // dangerous because we don't know how p was allocated in SomeOtherOtherFunction
// usually we'd call LocalFree if using Win32 API functions that return allocated memory.

// we've seen this before, typically with the RegQueryXXX Win32 functions
int bytesRequired = SomeWin32Function(0, 0);
test.resize(bytesRequired + 1);
SomeWin32Function(&test[0], test.length());

return 0;
}


Obviously C++ was meant to be backwards compatible with C and therefore pointer support was necessary. Pointers are a powerful concept/feature and a necessary evil when working with the Win32 API.

While I'd like to see everyone learn the STL I must disagree with not teaching pointers to new C++ users. C++ polymorphism relies on the usage of pointers, for example:


Animal *p = new Cat;
p->Speak();


Because pointers are so prevalent in C++ code it is immensely important that new users learn to use them. Teach them to use the STL but also teach them the fundamental usage of pointers. If not, C++ users will not be able to effectively use their language of choice, or even the STL effectively.

If they don't understand pointers, how can they understand the following?


vector animals;
animals.push_back(new Cat);

animals[0]->Speak();
// etc.


I know most of you will argue (correctly) that a shared pointer-type class should be used instead:


vector< shared_ptr > animals;
animals.push_back(new Cat);

animals[0]->Speak(); // user still needs to understand operator ->.
// etc.


I argue that C++ cannot be taught in its entirety without introducing pointers relatively early on (maybe just after learning about classes.)

Just my opinion though,

Dire Wolf
www.digitalfiends.com

[edited by - Dire.Wolf on May 2, 2002 10:39:00 AM]

Share this post


Link to post
Share on other sites
I agree with a person that using STL without knowing what it does isn''t right. If I knew how to use STL without learning the concepts then I couldn''t possibly say that I know how STL works.

Knowing the why is more important the how. If beginners know why STL is this way and why we should use it, they would still learn pointers and everything.

Dire Wolf, strings are compatible with char pointers and everything but I think what a person meant was to do away completely with char pointers and use strings totally.

Share this post


Link to post
Share on other sites
Dire.Wolf a very informative post. that was more of the response i was expecting from sabreman.

sabreman naturally everything has limitations to how low you should go. just like playing limbo, the bar will eventually fall or your back/knees will give out.

memory mangement and pointers are integral to programming in ANY language. even in basic you could peek and poke locations in memory. though you had a limited block to work with, and very ugly in terms of code. pointers offerer a cleaner way of dealing with the problem, and no matter what language you use that is designed for efficency of excuted code and freedom will have some form of pointers and memory managment.

you dont need to write an OS to use the api. i NEVER said you had to rewrite the STL objects. merely understand the basic concepts of what they do. for a string object, that would be the various methods, and that it allocates memory for your string. its also good to know that when acessing the string directly that you have to stay within the memory allocated. the operators supported should also be learned. there should at least be an understanding that a char* is an atomic type pointer and not an object pointer. furthermore that an array of chars is NOT a string in the sense of text, but a string of bytes that can mean anything and may not be terminated with a NULL.

saying to use mfc instead the win32 api is different as STL is an integral part of c++ while mfc i not. its the closest thing i could think of to use as a metaphor. to use COM, one would have to effectivly understand how objects are delt with, what objects expect to have done to them, order of deletion, any memory mangament considerations, multi-threading issues if using multiple threads, object/COM interaction when designing COM objects, etc. you dont need to know how to physically create a COM system, just how on a high level it interacts with you. much like you need to understand the compiler takes your code, turns it into machine code, and then links to other object code. you should understand there are things as registers, how functions calls are done (ie using the stack), and other basic things about a ocmputer like vram is very slow to read from. you need to know things more in depth depending on how far into the area you will be coding. for instance creating COM objects requires more knowledge then just using them. you would need to know more about the hardware if you use asm. things like pipelines, cache and instruction pairing become more important.

the main thing though is this is a GAME development site. things like memory mangemnt is more important then other types of productive apps. using pointers is a MUST, since there is know other way to access vram in dx/opengl. you cant send sample data to dsound without pointers. you could wrap all that in a nice STL class using << >> operators, but that adds some overhead that may be too high for certain things like updating the screen on a per pixel basis, or for custom blits. pointers are not a hard concept to grasp once you see that its just a varible with an address in it. this address is a location in memory which is part of a larger block of memory allocated. most newbies have no problems using compile time declared arrays, its when things go dynamic it breaks up. they need to understand the concept is EXACTLY the same. the only difference is you are requesting the memory so you must give it back it instead of letting the compiler do it.

darkor, i merely was trying to increase the awarness among newbies that using char* is not the same as string object, but may ppl think that a char* is a string and get confused by terminology. they need to understand a string is not a string when the string is a char*, but still a string of chars where a char is not a really character but just 8bits of information.

Share this post


Link to post
Share on other sites
quote:
Original post by Dire.Wolf
SomeOtherFunction(&test[0]); // unfortunate but necessary

Very dangerous. If your string is shorter than the data SomeOtherFunction generates, you have an overflow.

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ ]
[ MS RTFM [MSDN] | SGI STL Docs | Boost ]
[ Google! | Asking Smart Questions | Jargon File ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
quote:
Original post by a person
memory mangement and pointers are integral to programming in ANY language.

That doesn''t mean they have to be a concern of the applications programmer. Have you ever programmed in any one of Python, Ruby, Lisp, Java, or many other languages? None of these even include the concept of a pointer, yet I''ve managed to very successfully write large applications in each of them. How do you explain that?


[ C++ FAQ Lite | ACCU | Boost | Python | Agile Manifesto! ]

Share this post


Link to post
Share on other sites
quote:
Original post by Dire.Wolf
While I'd like to see everyone learn the STL I must disagree with not teaching pointers to new C++ users. C++ polymorphism relies on the usage of pointers, for example:

Animal *p = new Cat;
p->Speak();


I agree with you on this point, but I don't agree with it as an excuse to scatter pointers everywhere throughout your code (I'm not accusing you of that, but a lot of people do it). It's not the pointer itself that concerns me, so I don't object to a "new" or "delete" statement. It's when that leads to memory management headaches, or if pointer manipulation is required, that I think you are then straying from what is suitable for consumption by newbies. The fact is that too many people are not aware of the alternatives, so are led into believing pointers are necessary in a far wider context than they really are. This is a fault of the way C++ has been taught over the last few years. It is not very difficult to make use of "polymorphic objects" which conceal pointer manipulation. Example:


    
#include <iostream>

#include <boost/smart_ptr.hpp>

using namespace std;

class base
{
public:
virtual void f() =0;
};

class derived : public base
{
public:
void f() { cout << "derived::f" << endl;}
};

int main()
{
typedef boost::shared_ptr<base> base_ptr;

base_ptr pb1(new derived);
pb1->f();
}

quote:

Because pointers are so prevalent in C++ code it is immensely important that new users learn to use them.

Then this becomes self-fulfilling. They are so prevalent because of the way people have been taught to use them, and they are not aware of the alternatives. Note, I am *not* saying "never use pointers" or "never teach pointers", I am advocating teaching the higher-level alternatives first. Intricate language details are a huge distraction from actually being productive in a language.
quote:

I know most of you will argue (correctly) that a shared pointer-type class should be used instead:

Yes.
quote:

// user still needs to understand operator ->.

That's just a bit of syntax, it doesn't require an in-depth understanding of pointers and memory for that.
quote:

I argue that C++ cannot be taught in its entirety without introducing pointers relatively early on (maybe just after learning about classes.)

I wasn't talking about teaching C++ "in its entirety". I'm talking about teaching enough C++ for someone to be productive and to not have to concentrate on distracting details. Are you aware of "Accelerated C++"? I like the order that Koening & Moo present language features: vectors and strings before arrays and c-strings, STL before writing your own code, smart pointers before "dumb" pointers, etc. It's interesting to note Stroustrup supports this approach.
quote:

Just my opinion though,

And just my opinion too.


[ C++ FAQ Lite | ACCU | Boost | Python | Agile Manifesto! ]

[edited by - SabreMan on May 2, 2002 5:43:44 AM]

Share this post


Link to post
Share on other sites
quote:

Accelerated C++



I've never read this book. It does make sense to teach students to use the STL as soon as possible. Too many books make the STL appear to be an add-on or some fancy library that is there if you want it. I guess since most books teach raw pointer manipulation first, many students might not realise the alternatives that the STL offers.

Two problems with shared_ptr are a) multi-threading (though I believe the boost shared_ptr has been updated.) and b) it is not part of the STL (though it should be.)

quote:

Oluseyi wrote:
Very dangerous. If your string is shorter than the data SomeOtherFunction generates, you have an overflow.



I agree. The function should have been listed as SomeOtherFunction(char* pString, int length), where 'length' tells the function how long the string is. I changed the code in my example to reflect this.

Dire Wolf
www.digitalfiends.com

[edited by - Dire.Wolf on May 2, 2002 10:39:57 AM]

Share this post


Link to post
Share on other sites
i will repeat again. this is for *GAME* development. i have seen very few games of top quality in python, ruby, java, etc. that did not use some for of dynamic objects and referencing. please show me a few top quality games written in those languages that does not dynamically allocate memory, manage some memory, and strictly uses only auto garbage collection of the lanaguage. this means that the programmer never deals with passing refereences of objects to functions (ie pointers) or have to deal with out of bound array conditions (memory mangment).

i have done some java, and it has the concpets of pointers. while not the powerful C++ version we all know and love, but instead references to objects and arrays which are just pointers wrapped in magic juice to help ensure you dont try accessing an object directly (ie modify varibles located within the object using offsets to the base address which is VERY bad thing to do as you know). you still have to allcoate arrays. deal with worrying about going out of bounds. when directly accessing a linear 2d array you dont do it via get/set functions. you do it through a pointer.

while i have not used python, i have looked it over and many times its soley used as a scripting engine for use within a c++ based app. basically creating plugins and the sort. not for hardcore graphics that reuire speed.

auto garbage collection is nice (ie never dealing with memory managment), but unless you have some control over it, you lose all efficency and cant really create a decent game.

Share this post


Link to post
Share on other sites
quote:
Original post by a person
i will repeat again. this is for *GAME* development. i have seen very few games of top quality in python, ruby, java, etc. that did not use some for of dynamic objects and referencing. please show me a few top quality games written in those languages that does not dynamically allocate memory, manage some memory, and strictly uses only auto garbage collection of the lanaguage.

Why don't you show me the newbie who expects to write a top-quality game requiring advanced programming techniques? If you agree that newbies don't target top-quality games, then maybe you also agree that newbies don't want or need all the features required in writing a top-quality game. Therefore, they can concentrate on the features that make them more productive - i.e. STL collections, handle classes such as smart pointers, etc.

IMO using the STL to not have to understand (or otherwise worry about) low-level details is exactly the right thing for a newbie to do. Attempt to understand pointer manipulation and memory management once you reach the limitations of the standard library techniques. If someone doesn't learn the common idioms of the language, they will be forever condemned to liberally sprinkle pointers and memory management code throughout their programs, never understanding what an abomination they are creating. As I said, the less places I have that sort of thing in my code, the happier I am.
quote:

i have done some java, and it has the concpets of pointers.

Yes, but it doesn't have a pointer primitive. Pointer management is done "under the hood".
quote:

while i have not used python, i have looked it over and many times its soley used as a scripting engine for use within a c++ based app. basically creating plugins and the sort. not for hardcore graphics that reuire speed.

Which newbies almost *never* need.


[ C++ FAQ Lite | ACCU | Boost | Python | Agile Manifesto! ]

[edited by - SabreMan on May 3, 2002 4:52:47 AM]

Share this post


Link to post
Share on other sites
quote:
i have done some java, and it has the concpets of pointers.

It doesn''t just have the "concept" of pointers -- they''re everywhere. Any and every object is created as a pointer to an object on the garbage-collected heap. There are no stack or value-type objects. You either have a primitive or you have a pointer. That''s all Java knows about. Use of pointers, in conjunction with Java''s strict pass-by-value, is why you can''t write a generic ''swap'' function in Java.

Share this post


Link to post
Share on other sites