ATL / WTL / STL

memcpy, not understanding something

25-Mar-13 23:41

bkelly13 wrote:
The dialog does not explicitly or implicitly restrict the use to dot H / HPP files.

Maybe so, but that is the way the compiler (and by extension Visual Studio) operates. When you want to compile a file, the path and name(s) of the source file(s) to be compiled must be explicitly provided. Any header files that are referred to in the source are searched for according to the rules for that compiler. Most compilers will search the current directory, any directory that contains a named source file, and any directories that are listed in the 'include' lists; these are specified by option, environment variables etc. If the directory path for a source file is incorrect then the compiler will fail that compile and report the error. It will not make any attempt to look in the include directories for it.

bkelly13 wrote:
It works, but I am not at all fond of that solution.

Well that's the way it's supposed to work, and always has done.

bkelly13 wrote:
I find this to be a defect in Visual Studio.

I think you may be in a minority.

Use the best guess

bkelly1311-Mar-13 14:11

11-Mar-13 14:11

Windows 7, Visual Studio 2008, MFC, C++
A memset is not doing what I expect. Here is the relevant code. It is a received TCP/IP payload packet and the goal is to copy some of the data to a new location. m_carry_over_bytes has the expected value of 1200.

All the code surrounding the memcpy is just to look at the before and after.

m_prev_header_packet_size     = mp_search_pointer->iads_structure.header.packet_size;
 m_prev_header_sequence_number = mp_search_pointer->iads_structure.header.sequence_number;
 m_prev_header_packets_sent    = mp_search_pointer->iads_structure.header.packets_sent;
 m_prev_header_packets_lost    = mp_search_pointer->iads_structure.header.loss_or_overflow;
 m_prev_header_dummy_0_5555    = mp_search_pointer->iads_structure.header.dummy[0];
 m_prev_header_dummy_1_6666    = mp_search_pointer->iads_structure.header.dummy[1];
 m_prev_header_dummy_2_7777    = mp_search_pointer->iads_structure.header.dummy[2];
 m_prev_header_dummy_3_ffff    = mp_search_pointer->iads_structure.header.dummy[3];


 memcpy( &m_carry_over_buffer,
         &mp_search_pointer,
         m_carry_over_bytes );

 m_curr_header_packet_size     = m_carry_over_buffer.iads_structure.header.packet_size;
 m_curr_header_sequence_number = m_carry_over_buffer.iads_structure.header.sequence_number;
 m_curr_header_packets_sent    = m_carry_over_buffer.iads_structure.header.packets_sent;
 m_curr_header_packets_lost    = m_carry_over_buffer.iads_structure.header.loss_or_overflow;
 m_curr_header_dummy_0_5555    = m_carry_over_buffer.iads_structure.header.dummy[0];
 m_curr_header_dummy_1_6666    = m_carry_over_buffer.iads_structure.header.dummy[1];
 m_curr_header_dummy_2_7777    = m_carry_over_buffer.iads_structure.header.dummy[2];
 m_curr_header_dummy_3_ffff    = m_carry_over_buffer.iads_structure.header.dummy[3];

Looking at the m_prev* variables I find the expected values: size is 1228, sequence_number is 62316, ... dummy 2 is 0x7777, etc

After the memcpy, the m_curr* values are expected to have the same values ad the m_prev* values. Instead they have all Fs, the value it was initialized to in the constructor.

Both the source and destination work back to this structure:

CSS

// 
  union RECEIVE_TYPE
  {
     char char_array [ C_TCP_MAX_RECEIVE_SIZE ];
     C_IADS_TD_FIXED_PARAMETER_PACKET iads_structure;
  } m_receive_buffer;

I expected this memcpy to be simple. Where am I not understanding it?

Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/

modified 11-Mar-13 20:47pm.

H.Brydon11-Mar-13 14:41

H.Brydon

11-Mar-13 14:41

You haven't shown all of the structures involved, but perhaps the memcpy() should be:

C++

memcpy( &m_carry_over_buffer,
         mp_search_pointer,
         m_carry_over_bytes );

--
Harvey

bkelly1311-Mar-13 14:53

11-Mar-13 14:53

H.Brydon,
You got it right. I was forgetting that mp_search_pointer was a pointer to start with. Still, I don't understand why it did not copy something into m_carry_over_buffer

Just for completeness they are declared as:

RECEIVE_TYPE *mp_search_pointer;
RECEIVE_TYPE  m_carry_over_buffer;

Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/

Richard MacCutchan11-Mar-13 22:35

11-Mar-13 22:35

You are specifying the source address as &mp_search_pointer which is the address of the pointer, rather than the pointer itself. I suspect that is not what you intended.

Use the best guess

member char array is bad pointer

Dale Burr28-Apr-13 22:01

Dale Burr

28-Apr-13 22:01

Richard MacCutchan wrote:
You are specifying the source address as &mp_search_pointer which is the address of the pointer, rather than the pointer itself. I suspect that is not what you intended.

Exactly right. The address of the pointer gives you a block of memory just 4-bytes long, containing a memory address. The pointer itself gives you the allocated memory you're looking for.

bkelly139-Mar-13 16:41

Re: member char array is bad pointer

9-Mar-13 16:41

Environment Visual Studio 2008, C++, MFC
Class C_TCP_Format_WSA_Text has a method that begins like this:

void C_TCP_Format_WSA_Text::Format_WSA_Error_As_Text( int wsa_error, char*  wsa_text )
{...}

Class C_TCP_Client has this member declaration:

char m_tcp_error_text[ MAX_WSA_ERROR_TEXT ];

and has a method with a call that looks like this:

void C_TCP_Client::OnConnect( int nErrorCode )
{...
   m_C_TCP_Format_WSA_Text.Format_WSA_Error_As_Text( m_wsa_error_code, m_tcp_error_text );
...}

The compiler accepts it but when the code gets to the call to Format_WSA_Error_As_Text() the debugger says that m_tcp_error_text is a bad pointer. I looked at an example via google and it indicates my code is fine.
What am I missing?

Thanks for your time

Richard MacCutchan9-Mar-13 22:40

9-Mar-13 22:40

You need to look in your debugger to see what the actual values of all the variables are. I can only assume that you are calling Format_WSA_Error_As_Text() from somewhere else and the pointer is not the one that you think it is. BTW your overuse of underscores in class and variable names does not make for easy reading, see MSDN's paper on General Naming Conventions[^].

Use the best guess

Unexpected result

bkelly1310-Mar-13 6:09

Re: member char array is bad pointer

10-Mar-13 6:09

Following your advice I found some completely unexpected results. Skipping some steps here is the situation. From code in the dialog box the TCP client class is created as follows:

try
{
   mp_C_TCP_Client = new C_TCP_Client( mp_C_Log_Writer,
      C_TCP_DEFAULT_SOCKET_PORT,
      C_TCP_DEFAULT_IP_ADDRESS  );
   last_error = GetLastError();

} catch( ... ) {...}

Before stepping over the new statement, the port number is 49000 and the IP address is 192.168.2.2. Further down is this fragment:

if( mp_C_TCP_Client != NULL )
{
   mp_C_TCP_Client->Set_Log_Sequence_Match(      m_log_sequence_miss_match );

In the debugger the variable m_log_sequence_miss_match shows up as false, expected.

After stepping over the new statement, which does not catch any exception, the debugger no longer displays any value for that variable. It does not show a value for last_error = GetLastError().

When a break point is put in the constructor the arguments, correct before the new statement, are not correct within the constructor.

I presume there is something wrong with the new operation, but the debugger continues to step through the code in the constructor of the just created object. The values of the variable are clearly incorrect, but the debugger keeps on stepping.

BTW: here is a critical declaration:

C_TCP_Client *mp_C_TCP_Client;

I have been working on this code for a while and construction of the object has been fine. As usual, I do not recall making any changes that would affect the object's construction.

I do not know how to interpret these symptoms.

Thanks for your time

bkelly1310-Mar-13 7:29

Re: member char array is bad pointer

10-Mar-13 7:29

To reply to your comment on my underscore and the convention.
IDoNotLikeWritingLikeThis. IWouldNeverBuyABookWrittenLikeThis. IBelieveAllLanguagesUseSpacesBetweenWords.
More like this. Since I use expressive names,
the_underscore_meets_syntax_rules_with_minimum_disruption. In my opinion, the use of under scores is far more readable then camel case.
Another standard is to use UPPER_CASE when creating constants. So how does the standard address that in this example: DAYSOFTHEWEEK = 7. My choice is DAYS_OF_THE_WEEK. With this example, my use of under scores in variable names is consistant, camel case is inconsistent.
PLEASE note that I do not critisize others on this concept. I do NOT take offense at your comment, but do RESPECTFULLY disagree. Please, no flame wars on this topic.

Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/

Richard MacCutchan10-Mar-13 8:04

resolved, with many curses directed at myself

10-Mar-13 8:04

bkelly13 wrote:
I do NOT take offense at your comment, but do RESPECTFULLY disagree.

Similarly my comment was just that, not a criticism.

Use the best guess

bkelly1310-Mar-13 7:38

10-Mar-13 7:38

I just saw an earlier posting of mine that someone answered and was the answer to this one.

This application is TCP/IP code. The solution has two projects, Server and Client. I built in release so I could copy the Server exe to another computer and run it there where testing the client on my desktop. Then I forgot to go back to debug mode and rebuild. The debugger is wildly inconsistent and does not work well when running a release version.

That was a stupid error on my part.

Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/

Richard MacCutchan10-Mar-13 8:05

10-Mar-13 8:05

bkelly13 wrote:
That was a stupid error on my part.

Something I have done many times.

Use the best guess

Albert Holguin10-Mar-13 14:27

10-Mar-13 14:27

It really is a nice feature that the debugger can run with some components in release and others in debug, once you get used to it you won't make the mistake as much or you'll recognize the symptoms immediately.

bkelly1310-Mar-13 15:44

10-Mar-13 15:44

I thought about that and decided to not say anything either way. After reading you post, I thought some more. Yes, it can be a good thing to have the debugger able to run with release code. OTH, the inability to show the correct values for variables seems to reduce its usefulness. I suppose that seeing what it is executing is better than nothing.

Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/

Albert Holguin10-Mar-13 15:49

10-Mar-13 15:49

Well like I said before, the reason you can run release versions is not so that you can debug them... it's so you can debug components that ARE in debug mode. For example, if you have a really large project made up of multiple components (exes, dlls, and libs), you only need to have the component that you're debugging in debug mode.

something new to me

bkelly1310-Mar-13 16:14

10-Mar-13 16:14

Well now,..., I did not fully understand you first post. Now I presume that module X can be compiled in debug mode while everything else is in release mode. If true, just how is that done?

Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/

Re: something new to me

Albert Holguin11-Mar-13 7:53

rookie need help with STL

11-Mar-13 7:53

Only time I've had to do it was when I didn't have the source to a third-party dll. You should be able to have the rest of the application be debug and your third-party dlls be release mode with no issues (obviously you can't debug the inner working of those dlls but they're still loaded and working).

With that said though... it's probably better practice to run the whole thing in debug or release (a lot can go wrong with the mixed assemblies).

modified 11-Mar-13 14:03pm.

spawn200420-Feb-13 7:40

spawn2004

20-Feb-13 7:40

Hi everybody Smile | :)

I need some professional help from experienced people. I am writing a program in C++ about a game. I have to specify a class Questions with attributes question, answers and difficulty. In the program i should have methods add, edit, select, search, print and remove. The problem that i have is that i have to work dynamically with these questions and when i choose from the menu save, just then to save everything into the file. So far i have ideas for everything except what kind of container to use?? I thought that i can use "map" but the key ( this should be the number of question) is const and if i delete a question the keys after that will remain the same. I need when i delete a question this integer ( question number) to decrease with 1. Can you give me an advise what kind of container to use and if i need to put question number as an attribute into the class.
Thank you in advance for the help Smile | :)

Re: rookie need help with STL

Jonathan Davies21-Feb-13 1:05

Jonathan Davies

21-Feb-13 1:05

Perhaps you should look at array or, considering you mention a dynamic requirement vector. You mention the number of the question needing to decrease by 1 if you delete a question. Map uses keys that remain the same i.e. don't decrease by 1 whilst vector, for instance will accomodate this better. I'm assuming that, say, if you delete question 5 then the fact that you want what was question 6 to now become question 5, question 7 to become 6 etc. With a map you could keep the keys 1,2,3,4,6,7,8.

Re: rookie need help with STL

Rahul from Poona23-Feb-13 22:26

Rahul from Poona

23-Feb-13 22:26

In the above scenario u can use vector which would maintain the count of questions.Second thing if u want to provide some uniqueness to the question I think u should take a timestamp as variable in your question class which is updated when u create a question and will be overwritten if u modify that question. Thus ur count and uniqueness will remain intact.

locals not valid in debugger

bkelly1313-Feb-13 3:13

Re: locals not valid in debugger

13-Feb-13 3:13

Windows XP Pro, Visual Studio 2008, C++, MFC

Start an application in the debugger and step over:

C++

unsigned int length = 0;
length = strlen( some_char_array );

When hovering over the variable the debugger will not show a value for length. It does show the text of some_char_array, passed in as an argument. Quick watch claims that length is not defined. A breakpoint was set in the constructor of that object and it is being called. The same problem exists there also.

In the below fragment neither the if or the else is executed:

C++

if( length < SOME_CONSTANT )
  { X = 1; }
else
  { X = 2; }

What have I done that will cause the debugger to not show variables?

EDIT: To be more precise the quickwatch says:
CXX0030 Error: expression cannot be evaluated.

Thanks for your time

modified 13-Feb-13 9:44am.

Richard MacCutchan13-Feb-13 3:18

Re: locals not valid in debugger

13-Feb-13 3:18

It is possible that the executable you are debugging is not up to date with the source code. Try a full rebuild of your project.

bkelly1313-Feb-13 3:51

Re: locals not valid in debugger

13-Feb-13 3:51

The computer was rebooted, same results. On the above suggestion, did a Clean and Rebuild, same results. I will try another reboot and clean and if sucessful, will post the results. Otherwise, assume no change.
(The working computer has no internet connection and is in another room)

I also noticed:

C++

m_hour = 0;
m_minute = 0;
m_second = 0;

All are declared a member variables. The debugger skipped over m_hour and visited m_minute and m_second. Very curious.

EDIT

After a reboot and after deleting the *ncp and *.pch files, the results were the same. Another Clean and Build had no effect.

THEN
I realized the project was set to build the realease version. (That is displayed in the toolbar) After changing that to debug, everything seems normal again. I could whine about this, that, and the other, and how it SHOULD work but that is not going to change anything. The end result is almost two hours expended learning this little lesson because I did not notice all the indicators.

Thanks for taking the time to post.

Thanks for your time

modified 13-Feb-13 10:10am.

Albert Holguin13-Feb-13 4:42