|
Start by looking at how to would do it manually: get a pen and paper, and start playing with numbers.
Work out how you do it yourself, and an algorithm should become apparent.
Working this out is part of the task - heck, it is the task, you aren't supposed to implement it yet, if ever. It's an exercise in logical thinking and analysis, intended to start you thinking in "appropriate" ways. If you don't do it yourself, the "thought patterns" that you will use later don't start to form, and things can be a load harder later.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: Start by looking at how to would do it manually: get a pen and paper...
I wholeheartedly agree.
"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
|
|
|
|
|
Wel,
I agree with all the others. Every Computer Program starts with understanding the problem you are trying to resolve. This is quite fundamental! If you do not understand the problem, you will be unlikely to write a program that will resolve the issue at hand. the best start is possibly to write the question down, and in your mind break it down into the fundamental decisions program has to make. ( I have spent weeks with problems like this spinning through my head, trying to find the right approach to the problems I faced at the time)
Your question although wordy is quite basic. If you can resolve it, good and well, in that case Just consider yourself happy that you are (for now) not required to recover from "Fault" conditions.
If you can not, well, maybe you are not programmer material, and, you should possibly make another career choice.
Regards,
Bram van Kampen
|
|
|
|
|
|
Member 13478986 wrote: Can anyone please help?
Start with the chair only. So A, B and H. (Ignore S)
Figure that out.
Then add S.
After that add C and D. It might help to only do C, D, H and S first. However after you did it for A and B this should be trivial.
|
|
|
|
|
I have a heating control application that is based on some C++ code and some Arduino code. Having "woken up" to the 2038 timebomb, I am currently converting my code to cope with this (even though I shall in all probablity be "pushing up the daisies" by then !! ). As I believe Arduino uses 32 bit unsigned time variables, I believe it is OK after 2038 I am running MSVC 6.0 and, being of limited means, do not want to upgrade to 7.0 (or higher ) which I believe introduces a 64-bit version of the CTime class whicjh will cope with the situation. Having discovered an alternative solution ( Time64 - 64 bit Times for 32 bit Windows Apps[^] )I am doing this by abandoning CTime and replacing the code with 64-bit variables and using system calls. However, does anybody know if the MFC class CMonthCalCtrl is susceptible to the 2038 problem (as it DOES use CTime objects as parameters to it's functions) or am I 2038-safe by only employing calls using the SYSTEMTIME parameter ? I could test this but thought that I would ask the experts anyway!! Any help appreciated !
|
|
|
|
|
Member 13459733 wrote: I am running MSVC 6.0 and, being of limited means, do not want to upgrade to 7.0 (or higher ) which I believe introduces a 64-bit version of the CTime class...
Visual C++ .NET 2002 (a.k.a., MSVC++ 7) was strictly 32-bit.
Have you considered Visual Studio Community 2017? It's fee structure might be more accommodatable to you.
"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
|
|
|
|
|
The MFC CMonthCalCtrl class is just a wrapper for the corresponding Windows system control. You might also have a look at the MFC sources (winctrl5.cpp) which are usually installed with Visual Studio. Then you will see that the class just sends messages using SYSTEMTIME parameters. The functions accepting CTime and COleDateTime parameters will convert those to SYSTEMTIME.
So you have to check the documentation for the used types:
Note
Windows does not support dates prior to 1601. See FILETIME for details.
The month-calendar control is based on the Gregorian calendar, which was introduced in 1753. It will not calculate dates that are consistent with the Julian calendar that was in use prior to 1753.
wYear
The year. The valid values for this member are 1601 through 30827.
COleDateTime uses the DATE Type | Microsoft Docs[^] internally.
For CTime see also the source (atltime.h). The oldest version I have here is VS 2003 (MSVC 7.1) which already uses __time64_t.
Result:
If you still want to use software from the last millenium to handle dates beyond 2038 you can use the CMonthCalCtrl when using only functions that accept SYSTEMTIME and COleDateTime parameters.
|
|
|
|
|
Quote: If you still want to use software from the last millenium to handle dates beyond 2038 you can use the CMonthCalCtrl when using only functions that accept SYSTEMTIME and COleDateTime parameters.
I had thought that that MIGHT be the case and seems like a good solution for me ! Thank you !
|
|
|
|
|
Hello everyone.
I have asked around all forums and cannot seem to get a satisfying answer as to how I can create a LinkedList stack or queue using classes not structures.
I would love to post my number for a more personal response on whatsapp, thats if it is allowed.
0714815219
|
|
|
|
|
|
Exactly the same way you create a LinkedList of anything.
|
|
|
|
|
Member 13478479 wrote:
I have asked around all forums and cannot seem to get a satisfying answer as to how I can create a LinkedList stack or queue using classes not structures.
I find that really hard to believe, unless you limited your search to less than two sites. Since lists, stacks, and queues are the basis for any data structures class/book, you'd have a hard time finding a site that did NOT talk about them.
The main difference between a struct and a class is the former has public members by default whereas the latter has private members by default.
"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
|
|
|
|
|
Member 13478479 wrote: I would love to post my number
I would suggest removing your number. You can edit your post to do that.
|
|
|
|
|
Find the optimum rectangular size of the box to pack all the Small rectangular boxes.
|
|
|
|
|
|
I think you've hit a local optimum there.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
|
This sounds like the "bin packing problem."
"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
|
|
|
|
|
I am working with an embedded microcontroller (ARM) and I'm building with GCC. The following is fully possible for me to:
struct testStruct_s {
int dummy;
const char* string;
};
struct testStruct_s testStructArray[] = {
{0, "Hello World"},
{0, "Hello World Again"}
};
But why isn't the following possble?
struct testStruct_s {
int dummy;
int* array;
};
struct testStruct_s testStructArray[] = {
{0, {0, 1, 2, 3}},
{0, {0, 1, 2, 3, 4}}
};
Is there a workaround to achieve this? I do not want to specify the array values outside the struct so the following is not what I want:
int array1[] = {0, 1, 2, 3};
int array2[] = {0, 1, 2, 3, 4};
struct testStruct_s testStructArray[] = {
{0, array1},
{0, array2}
};
-- modified 17-Oct-17 7:50am.
|
|
|
|
|
In your first example, the struct member is a char *, that is, a pointer. Its size is fixed, although the string it points to (which is stored elsewhere) may be of variable size.
A debugger will show you what lives where at run time.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Yes, char* is a pointer. But I believe int*, in the second example, is also a pointer.
|
|
|
|
|
(1, 2, 3} is 3 int's. It is not a pointer to an array of 3 int's.
The string/char * fudge dates from the early days of C before they realised they needed string as a first class data type.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Using 'compound literals[^]', you can:
#include <stdio.h>
struct testStruct_s {
int dummy;
int* array;
};
struct testStruct_s testStructArray[] = {
{ 0, (int[]){0, 1, 2, 3, -1}},
{ 0, (int[]){0, 1, 2, 3, 4, -1}}
};
int main()
{
for (int i=0; i<sizeof(testStructArray)/sizeof(testStructArray[0]); ++i)
{
printf("dummy = %d\n", testStructArray[i].dummy);
for (int k=0; testStructArray[i].array[k] != -1; ++k)
printf("array[%d]=%d\n", k, testStructArray[i].array[k]);
printf("\n");
}
}
|
|
|
|
|
Is this a compiler-specific feature or is it part of standard C? And is there a way that I can obtain the size of the arrays? The following simply returns the size of the pointer, not the array:
sizeof(testStructArray[0].array)
-- modified 17-Oct-17 8:20am.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
