|
bkelly13 wrote: if I could find anyone else around here that uses Visual Studio.
Just about everyone who comes here uses Visual Studio on a daily basis. As stated by two other posters your project was in a mess, which was why you got that problem, but the information you originally provided did not show it up. In fact from your original question it was not possible to figure out what you were doing, hence my comments.
|
|
|
|
|
Hi,
Just a Comment.
I assume that you understand that each 'C' or 'CPP' File, gets compiled into One and only One '.obj' module.
The Linker stitches all those 'Obj' modules together, to create an Exe or DLL, your Target. In doing so, your program needs to link with other libraries and DLL's already on the system. For Instance, your program uses the keyboard, and uses the mouse. You did not have to write the code inside your program to track the mouse movements, register the clicks, etc. That was already done by Microsoft, and comes as part of the Windows Package. Now, Microsoft wrote all that stuff, but, the compiler needs to know what is available from Microsoft, I.e.: the function and other specifications that the Windows API provides. These specifications are included in the System Headers. If you change these specifications to suit your own purpose, well, it Might work if you also 'Re Compiled Windows'
If you mess with your system header files, you are actually telling your compiler that Windows works different than that it actually does.
Your Compiler caught you out, and stopped you writing a disaster.
include files do not make your program larger, at most it slows down your compiler and linker
All Software Engineers should Learn and Train Machine and Assembly Language, so as to really Understand how a computer Works
Bram van Kampen
|
|
|
|
|
sdfesrgdth
modified 21-May-17 13:11pm.
|
|
|
|
|
No.
We do not do your homework: it is set for a reason. It is there so that you think about what you have been told, and try to understand it. It is also there so that your tutor can identify areas where you are weak, and focus more attention on remedial action.
Try it yourself, you may find it is not as difficult as you think!
If you meet a specific problem, then please ask about that and we will do our best to help. But we aren't going to do it all for you!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I would go with Zod,Clod and ZooDude some aliens from outerspace came down and ate my programming assignement .. and that is why it's not ready for hand-in sir.
In vino veritas
|
|
|
|
|
Wasn't a question the first time this was asked, and still not a question now. If you do not understand your homework assignment. ask your teacher. It's their job to teach you, not ours.
Speed of sound - 1100 ft/sec
Speed of light - 186,000 mi/sec
Speed of stupid - instantaneous.
|
|
|
|
|
hello,
Can anyone help me out in writing large number of files(almost 8000) parallely in a directory using openMP support in VC++
I am also using a recursive function inside WriteFile to do the writng texts to the corresponding file
My code snippet is as below
===========================
#pragma omp parallel private(i)
{
#pragma omp for schedule(dynamic, 1)
for ( i= 0; i< 10000; i++)
{
WriteFiles("directory path..", "w+");
}
}
But it is not working and crashing particularly inside recursive function.
Can anyone help me out?
Thanks in advance
asdsa
|
|
|
|
|
Ashish Ranjan Mishra wrote: it is not working and crashing
You will need to provide much more detail if you want help with this. We have no idea what "not working" means, or where it is crashing. Also, you need to understand that trying to write that many files at the same time will run extremely slowly as the system tries to schedule the different threads.
|
|
|
|
|
Apart from the problem, you also did not show the WriteFiles function that you have. The function that you have is not recursive, it does not call itself, or does it? If that does, remove the recursion as soon as possible.
Secondly, also show the code of that function.
OpenMP is helpful in most cases, but multithreading can be overkill in majority of the cases. Use with caution.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
Until your code works with 1 file, non-recursively, don't bother adding the complexity of multiple files, in parallel, using recursion.
Start small until you have a firm understanding, and then bother building it up.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Hi,
Ashish Ranjan Mishra wrote: But it is not working and crashing particularly inside recursive function.
Can anyone help me out?
Unfortunately you did not give any error message or debug information.
Also wanted to point out that you will need to avoid the C runtime if you plan on opening more than 512/2048 files at a time. If you use the C wrappers you will be limited to 512 file handles which can be extended to 2048 via the _setmaxstdio function[^].
Best Wishes,
-David Delaune
|
|
|
|
|
Hello all... I have this C code which I can compile and modify using NetBeans. But problems come when I try to separate some of the code to new files (.h & .c). I get these Unresolved External Symbols xxxxx. Example
int add(int a, int b);
int add(int a, int b)
{ return a + b; }
#include "newFile.h"
int main()
{
int result = add(5,6);
_getch();
return 0;
}
How do I overcome this error....thanks for anything you share.
|
|
|
|
|
You have to make sure that newfile.obj (or whatever it compiles to) is being linked during the build process.
|
|
|
|
|
Get yourself a copy of Visual Studio, it is much better for building C/C++/C# projects.
|
|
|
|
|
Hi all of you. How can I convert COleVariant to COLORREF ?
I have used CMFCPropertyGridColorProperty to store a colorref into CMFCProperrtyGrid, but I need to retrieve correctly the colorref value, because CMFCPropertyGridColorProperty have been filled with COleVariant ...
I get the value just like this:
CMFCPropertyGridProperty* pProp = m_wndPropList.FindItemByData(TRM_PROPERTYGRID_COLORWINDOW);
pProp->GetValue();
but GetValue get me COleVariant, and I have there COLORREF value ... how can overcome this ? I get the following error:
error C2440: 'return' : cannot convert from 'const COleVariant' to 'COLORREF'
Thank you.
|
|
|
|
|
Since COLORREF is a DWORD, can't you just access the ullVal member of COleVariant?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
|
|
Hello all... how do I create array of char*. At the moment I have hardcoded the number of instances (large enough to hold tokens) but this should be generic. Example
int temp_array[2] = {0};
char* token1;
char* token2; As you can see, I might not know how many tokens I need at run time. I want something like this
char* [] tokens; How could I fix this? Thanks
modified 12-May-17 6:00am.
|
|
|
|
|
Create a variable for the array that is initially empty and a variable holding the size:
char **tokens = NULL;
unsigned tokenSize = 0;
Once you know the required number of items, allocate the array. How to do that depends if you are using C or C++:
tokenSize = items_to_store_in_array;
tokens = new char *[tokenSize];
tokens = (char **)malloc(sizeof(char*) * tokenSize);
If you need to change the size use realloc with C.
With C++ you should then avoid arrays and use a container like vector - C++ Reference[^] instead.
|
|
|
|
|
Jochen Arndt wrote: How to do that depends if you are using C or C++:
Well I should have mentioned that earlier..... I am using C. Can you please edit your question (or append the code for C)
|
|
|
|
|
The C code is there (the malloc call).
Use something like this (for two tokens):
tokenSize = 2;
tokens = (char **)malloc(sizeof(char*) * tokenSize);
tokens[0] = token1;
tokens[1] = token2;
free(tokens);
tokens = NULL;
tokenSize = 0;
|
|
|
|
|
Only addition to Jochens answer is to remove confusion to you typedef the char* pointer
ptrCount = 2;
typedef char* CHARPTR;
CHARPTR* charPtrArray = (CHARPTR*)malloc(sizeof(CHARPTR)*ptrcount);
Now it looks like any other array
The confusion exists because char** can be a couple of things in C you can't distinguish them without looking at the initialization code
1.) A pointer to a char* (always true)
2.) An array of char* (if initialized as such)
3.) A multidimensional char array (if initialized as such)
Number 3 in particular usually causes mass confusion with students learning C.
The typedef doesn't stop you assuming the wrong thing but it does give you language cues to what it is and is easier to read.
In vino veritas
modified 14-May-17 22:51pm.
|
|
|
|
|
std::vactor<char*> m_myArrayOfString ;
m_myArrayOfString.push_back(new char[17]);
...
...
in the end loop through vector and delete them one by one
for(auto ptr : m_myArrayOfString)
delete [] ptr ;
m_myArrayOfString.clear();
huzifa
|
|
|
|
|
Think of an array of chars as a 2d map.
So along the bottom the x axis can be considdered as an array of char pointers, each one pointing to a vertical array of chars going up in the y direction.
So point 0,0 is a char**
You can of course extend this to a 3 d map, with char***
Any point on the 2d map can be referenced by data[x][y]
SO first you alloc how many you need in the x direction: char** data = alloc(xMax)
Now each vertical collum can be alloced as data[0] = alloc(y1Max) data[1] = alloc(y2Max)
And so on.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
