|
Perhaps I am missing something here. The sample you have shown is for a .cpp file. This suggests to me that this is not a problem with your "Additional Include Directories", but that those files were included into your project with the relative path. I would open up the .vcxproj (if that is the extension used for 2008) and look at the path specified for that file.
As an example from one of my projects, there are files included like this:
<ItemGroup>
:
<ClCompile Include="StdAfx.cpp">
:
:
</ClCompile>
<ClCompile Include="..\..\Libraries\include\Packets\Stream.cpp">
:
:
</ClCompile>
:
</ItemGroup>
Obviously if you just copy the solution to a folder with a different nesting level, that will mess things up.
[EDIT]Updated the entries from my sample to show the .cpp files instead of the .h files[/EDIT]
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
File Project_Client_.vcproj contains:
<Tool
Name="VCCLCompilerTool"
Optimization="0"
AdditionalIncludeDirectories="D:\COMMON_CODE"
PreprocessorDefinitions="WIN32;_WINDOWS;_DEBUG"
MinimalRebuild="true"
BasicRuntimeChecks="3"
RuntimeLibrary="1"
UsePrecompiledHeader="2"
WarningLevel="3"
DebugInformationFormat="4"
It has the absolute location of the include files. I presume that is correct.
Re: Obviously if you just copy the solution to a folder with a different nesting level, that will mess things up.
I don't see why. Everything within the solution proper is in the same relative locations. Only this directory is in the stated absolute location. The problem is only with the common code directory, and it has the correct path for that. Same as the original location.
Edit: But then in another place in the same file is this:
<Files>
<Filter
Name="Source Files"
Filter="cpp;c;cc;cxx;def;odl;idl;hpj;bat;asm;asmx"
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}"
>
<File
RelativePath="..\..\..\..\COMMON_CODE\C_Log_Writer.cpp"
>
</File>
<File
RelativePath="..\..\..\..\COMMON_CODE\C_TCP_Client.cpp"
>
So it has the location in both relative and absolute position. That appears to be the worst of both worlds. How do I tell VS to recalculate all the relative positions.
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
|
|
|
|
|
But that is because the "Additional Include" directories is for including header files.
Let me ask you this: If you double-click on your C_Log_Writer.cpp in your solution, is it found and opened in the IDE? I do not expect it to be if the relative path specified in you project file is now incorrect.
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
Upon clicking on C_Log_Writer.cpp VS pops a message:
d:\B\COMMON_CODE\C_TCP_Client.cpp Cannot open file.
The solution is in directory D:\B\etc. The common code is in D:\COMMON_CODE like I explicitly specified in the configuration. It has no business putting that \B\ in there. I say again, the additional directories was specified as an absolute path, not a relative one. The original solution had both the dot CPP and the dot H file added. All were shown in the solution explorer.
Edit:
While in that configuration section of VS and with Additional Directories selected, press F1. In there it has an example that includes MAIN.C. I do not see it as limited to dot H or dot HPP files.
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
modified 24-Mar-13 20:21pm.
|
|
|
|
|
Alright, so it may not be limited to header files, but I cannot remember ever seeing it used for .cpp files. I will refer back to my original answer, the problem is not with your Additional Include Directories, but with the way file references are stored when added to a project.
You may have a point that Visual Studio should use the Additional Include Directories path and save file references without paths (although I would not trust the "find first match" scheme to always find the correct file in case of multiple files with the same name in different Include Directories), but the way you can fix it now seems obvious to me: Correct the paths of the files in your project file. You can even try to just remove the paths completely and see if the files are found using the Additional Include Directories.
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
This has nothing to do with include directories, since the file in question is a .cpp not a header file. You need to remove the relevant file(s) from the project and add them in again, using the absolute paths.
Use the best guess
|
|
|
|
|
RE: This has nothing to do with include directories, since the file in question is a .cpp not a header file.
As noted in an earlier reply, the VS help utility has an example that includes MAIN.C. I disagree with that fundamental concept. The dialog does not explicitly or implicitly restrict the use to dot H / HPP files.
Per MacCutchan's reply, removing the files and adding them back in does work. It works, but I am not at all fond of that solution.
That said, and in my not so humble opinion, I find this to be a defect in Visual Studio.
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
|
|
|
|
|
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
|
|
|
|
|
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:
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.
|
|
|
|
|
You haven't shown all of the structures involved, but perhaps the memcpy() should be:
memcpy( &m_carry_over_buffer,
mp_search_pointer,
m_carry_over_bytes );
--
Harvey
|
|
|
|
|
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/
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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/
|
|
|
|
|
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
|
|
|
|
|
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/
|
|
|
|
|
bkelly13 wrote: That was a stupid error on my part.
Something I have done many times.
Use the best guess
|
|
|
|
|
 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.
|
|
|
|
|
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/
|
|
|
|
|
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.
|
|
|
|
|
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/
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
