|
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.
|
|
|
|
|
I report you the first sentence of the linked page:
ISO C99 supports compound literals. A compound literal looks like a cast containing an initializer. Its value is an object of the type specified in the cast, containing the elements specified in the initializer; it is an lvalue. As an extension, GCC supports compound literals in C89 mode and in C++.
So:
C99 compilers support it.- Your compiler suopports it even in
C89 mode.
|
|
|
|
|
Unfortunately I have very little knowledge about compilers and I don't know what C89 and C99 are. What I'm worried about is that my code won't compile in the future if we move to a different compiler.
|
|
|
|
|
Quote: Unfortunately I have very little knowledge about compilers and I don't know what C89 and C99 are
It's time to learn, then.
Quote: What I'm worried about is that my code won't compile in the future if we move to a different compiler
If you are really worried about then don't use the feature.
You might also check in advance if the compiler you are planning to use in future supports such a feature (or, generally C99 features).
|
|
|
|
|
CPallini wrote: It's time to learn, then.
Keep in mind that the OP is doing embedded code and consequently what is actually available might be less than strict usage would otherwise suggest.
|
|
|
|
|
Then it is easy enough to make your code simpler:
struct testStruct_s {
int dummy;
int* array;
};
int array1[] = {0, 1, 2, 3};
int array2[] = {0, 1, 2, 3, 4};
struct testStruct_s testStructArray[] = {
{0, array1},
{0, array2}
};
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
