C / C++ / MFC Discussion Boards

Re: vc++

David Crow1-Jun-06 4:15

David Crow

1-Jun-06 4:15

yogikaushik wrote:
where i am wrong........

You're going to need to narrow the problem down to just a few lines of code. No one likes to wade through a bunch of irrelevant code. What is the problem you are seeing? Have you single-stepped through the code to find the offending statement(s)? Help us to help you.

"The largest fire starts but with the smallest spark." - David Crow

Does vc7/8 supprot declare a variable in switch case?

followait31-May-06 18:46

followait

31-May-06 18:46

like:

switch (n) {
case 0:
int i=0; //<<<<<<<<<<<<<<<<<
break;
case 1:
break;
}

Re: Does vc7/8 supprot declare a variable in switch case?

_AnsHUMAN_ 31-May-06 18:49

_AnsHUMAN_

31-May-06 18:49

switch (n) {
case 0:
{
int i=0; //<<<<<<<<<<<<<<<<<
}
break;
case 1:
break;
}

This is how it is done in VC7

Somethings seem HARD to do, until we know how to do them.
Wink | ;-)

_AnShUmAn_

Re: Does vc7/8 supprot declare a variable in switch case?

Steve Mayfield31-May-06 19:30

Steve Mayfield

31-May-06 19:30

It is my understanding that you can only use the variable within the case block. When you exit out of the block, the variable goes out of scope and it is destroyed.

Steve

Re: Does vc7/8 supprot declare a variable in switch case?

_AnsHUMAN_ 31-May-06 19:36

_AnsHUMAN_

31-May-06 19:36

Yes this is very true . The scope of the variable is only in the case block.

Somethings seem HARD to do, until we know how to do them.
Wink | ;-)

_AnShUmAn_

Re: Does vc7/8 supprot declare a variable in switch case?

David Crow1-Jun-06 4:17

David Crow

1-Jun-06 4:17

_AnShUmAn_ wrote:

This is how it is done in VC7

Nothing VC7-specific about it. This is how it has been done in C as far back as I can remember.

"The largest fire starts but with the smallest spark." - David Crow

link two visual projects [modified]

widoxs31-May-06 18:39

widoxs

31-May-06 18:39

how i link two MFC projects to visual C++ 6.0 ?? Unsure | :~

-- modified at 0:39 Thursday 1st June, 2006

Re: link two visual projects [modified]

NiceNaidu31-May-06 18:55

NiceNaidu

31-May-06 18:55

U mean, inserting a project into another project.

Do this.

Right Click on the workspace,then click on Insert project in to workspace.

then u can observe both the project in the same workspace.

hope this helps.

Appu..
"If you judge people, you have no time to love them."

Memory problem

Anu_Bala31-May-06 18:20

Anu_Bala

31-May-06 18:20

Hi,
I am working in vc++ for past 4 months.But i dont know very much about MFC.That is where the variables stored and memory allocation like that.When im doing coding,i got error as unhandled exception,Out of memory like that.So, i think im unaware about the memory allocation.So, Is there any tutorial about this allocation etc.,..?

Re: Memory problem

Hamid_RT31-May-06 18:29

Hamid_RT

31-May-06 18:29

I think that these links are helpful to you
Dynamic memory allocation in C++[^] and Memory leaks in C++ and how to avoid them[^]

whitesky

Re: Memory problem [modified]

Nibu babu thomas31-May-06 19:05

Nibu babu thomas

31-May-06 19:05

Anu_Bala wrote:
I am working in vc++ for past 4 months.But i dont know very much about MFC.That is where the variables stored and memory allocation like that.When im doing coding,i got error as unhandled exception,Out of memory like that.So, i think im unaware about the memory allocation.So, Is there any tutorial about this allocation etc.,..?

Well some of the things I know I would like to share. Smile | :)

Use new and delete.
Always use delete[] with new[] and delete with new
Do not mix up c, c++. Either you use C, or use C++ for memory allocation.
Always set a pointer to NULL after deletion.

Always allocate sufficient amount of memory. Do not allocate memory like this...

char *str = new char[ strlen( someStr ) ];//stingy
strcpy( str, someStr );// well asking for trouble
delete [] str;//error here
str = NULL;//good practice

instead use

char *str = new char[ strlen(someStr) + 1 ];//bring it on
strcpy( str, someStr );//gooood, very gooood.
delete [] str;//hehe fine
str = NULL;//good practice

Try using auto_ptr;
Maintain a list of pointers to memory that you have allocated. When you exit from your app you can delete them all at one go if any of them hasn't been deleted.
Always check for NULL on pointers after a new.
Always check for NULL on pointers before using them.
Be really really afraid to dynamically allocate memory.

Nibu thomas
A Developer

Programming tips[^] My site[^]

Re: Memory problem [modified]

David Crow1-Jun-06 4:20

David Crow

1-Jun-06 4:20

Nibu thomas wrote:
strcpy( str, someStr );// well asking for trouble

True, use strncpy() instead.

Nibu thomas wrote:
delete [] str;//error here

Why do you assert this is in error?

Nibu thomas wrote:
Be really really afraid to dynamically allocate memory.

Why?

"The largest fire starts but with the smallest spark." - David Crow

Re: Memory problem [modified]

Nibu babu thomas1-Jun-06 17:23

Nibu babu thomas

1-Jun-06 17:23

DavidCrow wrote:
Nibu thomas wrote:
delete [] str;//error here

That was in relation to the point I mentioned. i.e. to allocate sufficient amount of memory. Well if you are using strcpy for that purpose strcpy will put a NULL char just after the end of the memory block. And when you try to delete such pointers it will result in memory damaged error message.

strcpy was used here just to regenerate that issue.

DavidCrow wrote:
Nibu thomas wrote:
Be really really afraid to dynamically allocate memory.

Why?

Yeah, use it as a last resort. For eg: using standard stl classes can avoid most of the issues.

Note: I didn't say not to use it but instead to be afraid. Sometimes being afraid is good. Smile | :)

Nibu thomas
A Developer

Programming tips[^] My site[^]

Re: Memory problem [modified]

David Crow2-Jun-06 2:56

David Crow

2-Jun-06 2:56

Nibu thomas wrote:
Well if you are using strcpy for that purpose strcpy will put a NULL char just after the end of the memory block.

But the point is that the source could be longer than the destination, which is why strcpy() should not be used, regardless of how it deals with the \0 terminator.

Nibu thomas wrote:
For eg: using standard stl classes can avoid most of the issues.

Last time I checked, STL used memory from the heap (i.e., dynamic). There's just not any way around not using memory from the heap.

"The largest fire starts but with the smallest spark." - David Crow

Re: Memory problem [modified]

Nibu babu thomas2-Jun-06 3:03

Nibu babu thomas

2-Jun-06 3:03

DavidCrow wrote:
But the point is that the source could be longer than the destination, which is why strcpy() should not be used, regardless of how it deals with the \0 terminator.

Exactly, I was just demonstrating how such things could happen.

DavidCrow wrote:
Last time I checked, STL used memory from the heap (i.e., dynamic). There's just not any way around not using memory from the heap.

Exactly, they work by allocating on the heap. But then we don't have to do it. These are proven classes (AFAIK) which work efficiently. Hence using them would be best for us. These classes takes the onus on them to do memory clean up.

Nibu thomas
A Developer

Programming tips[^] My site[^]

Re: Memory problem

Sarath C31-May-06 19:14

Sarath C

31-May-06 19:14

I suggest you to read Effective C++ 2nd Edition or the latest 3rd Edition.

If u r confused about pointers, read Pointers in C to know more about pointers.

as nibu said if u r much concerned about pointers, try using auto_pointers that is the best way to handle memory leaks. but I suggest that not to use auto_pointer because simply u can handle those allocation and deallocation of objects.
In MFC, it is not using any special allocation strategy, its all C++.

Code Complete 2 is a book which contains some best practices.

Sa^Rath

"D on't blindly follow rules you read somewhere without verifying that it makes sense for your situation!"

Re: Memory problem

led mike31-May-06 19:32

led mike

31-May-06 19:32

SaRath C wrote:
In MFC, it is not using any special allocation strategy, its all C++.

That is not entirely accurate.

See this MSDN Article[^]

"What classes are you using ? You shouldn't call stuff if you have no idea what it does"
Christian Graus in the C# forum

led mike

Re: Memory problem [modified]

Sarath C31-May-06 19:52

Sarath C

31-May-06 19:52

Thanks for ur information. It was quite new for me.

Anu said that (he/she) is new to MFC and suffering with some exception and all.
Everything has an user point of view. We are the users of C++ right, at our point of view, operator new has a standard form and a predefined way which it should be used. I just indicated about that fact. never I meant any regarding internal handling of compiler. I think the language I used was something not proper Frown | :(

Sa^Rath

"D on't blindly follow rules you read somewhere without verifying that it makes sense for your situation!"

-- modified at 1:55 Thursday 1st June, 2006

Re: Memory problem [modified]

palbano1-Jun-06 4:50

palbano

1-Jun-06 4:50

SaRath C wrote:
at our point of view, operator new has a standard form and a predefined way which it should be used. I just indicated about that fact.

ah, I understand now, thanks. Smile | :)

-- signature under construction --

-pete

Video Card Memory [modified]

Matthew R. Miller31-May-06 16:45

Matthew R. Miller

31-May-06 16:45

Need a way in C++ to determine how much memory a user has on their graphics card. Either DirectX or some other way. Any leads?

===================

Matthew R. Miller
www.bytemycode.com
www.codeandcoffee.com

Re: Video Card Memory [modified]

Hamid_RT31-May-06 18:44

Hamid_RT

31-May-06 18:44

Im not sure maybe it is some helpful to you Here[^]

whitesky

stack overflow -- in a thread?

Peter Weyzen31-May-06 15:31

Peter Weyzen

31-May-06 15:31

I just moved some code from a CWinThread into a new thread (standard thread) and am now getting stack overflows (while accessing a COM engine -- "DesktopSearch").

Any clues for me?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<A HREF="http://www.soonr.com">SoonR Inc.</A>

Re: stack overflow -- in a thread?

John M. Drescher31-May-06 16:04

John M. Drescher

31-May-06 16:04

Have you initialized com for the new thread?

John

Re: stack overflow -- in a thread?

Peter Weyzen31-May-06 18:47

Peter Weyzen

31-May-06 18:47

absolutely!

I played with different CoInit calls to see if WDS would behave better...

But, I am CoInit'ing in the thread...

What are the issues that surround stack and threads? Is this additional stuff surrounding COM and/or DCOM?

Thanks

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<A HREF="http://www.soonr.com">SoonR Inc.</A>

Re: stack overflow -- in a thread?

Sarath C31-May-06 20:01

Sarath C

31-May-06 20:01

In windows, if u have specified initial size of the stack, in bytes. The system rounds this value to the nearest page. If this parameter is zero, the new thread uses the default size for the executable. may be u ur program requires more stack or encoutering with some loops which do some allocation. Pls check ur code.

Sa^Rath

"D on't blindly follow rules you read somewhere without verifying that it makes sense for your situation!"

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.