|
What if I was to turn that sector selector into a uint32_t so that I can move the "window" freely (even across sector boundaries), does this have a different name? The reason I ask is that I want to name my registers appropriately. Today they are named SLIDING_WINDOW_BUFFER_position, SLIDING_WINDOW_BUFFER_start and SLIDING_WINDOW_BUFFER_endExcl but I have a feeling this is called something else.
|
|
|
|
|
This is starting to sound like the ancient x86 segmented memory. 20 bit addresses (1MB) were made up of a 16 bit segment (shifted left 4) added to a 16 bit offset. The 8086 for example had 4 segment registers IIRC, CS (code), DS (data), SS (stack) and ES (extra).
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
From what I can work out you are still building a Virtual Memory system what you are calling the sector selector is the page index and the memory window size itself is the page size.
Memory segmentation - Wikipedia[^]
Quote: Segmentation with paging
Instead of an actual memory location the segment information includes the address of a page table for the segment.
If that is the case you are building a page table for a Virtual Memory Implementation
Page table - Wikipedia[^]
The Virtual space can be bigger, 1:1 or smaller than the real memory space.
Even on Flash Memory we still call them pages and a group of pages become a block.
That also holds for the old superVGA (VESA) standard where you have blocks being made up of pages of a set granularity
Although in both those cases we do call the selector a "bank selector" or a "block selector" as opposed to a "page index"
Sliding Window tends to be used as a term on transmission protocols
Realistically we understand what you are doing and it's only a name.
In vino veritas
modified 13-Aug-19 12:02pm.
|
|
|
|
|
|
kuleen wrote: how to convert afl to c
What is "afl"?
Australian Football League?
|
|
|
|
|
Probably be rewriting it.
|
|
|
|
|
I'm setting a CTreeCtrl item item font to Italic by handling the NM_CUSTOMDRAW message and setting the font with SelectObject.
This is working.
void MyTree::OnNMCustomdraw(NMHDR *pNMHDR, LRESULT *pResult)
{
NMTVCUSTOMDRAW *itemToDraw = reinterpret_cast<NMTVCUSTOMDRAW*>>(pNMHDR);
switch (itemToDraw->nmcd.dwDrawStage)
{
case CDDS_PREPAINT:
*pResult = CDRF_NOTIFYITEMDRAW;
return;
case CDDS_ITEMPREPAINT:
{
HTREEITEM item = reinterpret_cast<HTREEITEM>(itemToDraw->nmcd.dwItemSpec);
if (!m_IsItalicFontCreated) {
CFont* currentFont = GetFont();
LOGFONT logfont;
currentFont->GetLogFont(&logfont);
logfont.lfItalic = TRUE;
m_ItalicFont.CreateFontIndirect(&logfont);
m_IsItalicFontCreated = true;
}
if (m_IsItalicFontCreated)
{
::SelectObject(itemToDraw->nmcd.hdc, m_ItalicFont);
*pResult = CDRF_NEWFONT;
}
}
return;
}
*pResult = 0;
}
But at some point I need to check an item current font; to see if a tree item is in italic.
The CTreeCtrl's item data (CTreeCtrl::SetItemData) is already used to hold data for each item.
Is it possible to do it ? I can't see in the documentation anything I can use.
There is a lItemlParam in the NMCUSTOMDRAW struct, I'm not certain if I could use this to some some simple data ? or even if it is persistent.
Any suggestions ?
Thanks.
I'd rather be phishing!
|
|
|
|
|
You could implement the method in your MyTree class that would return true if italic font was created.
Something like
bool MyTree::IsItalicFontCreated()
{
return m_IsItalicFontCreated;
}
|
|
|
|
|
That only tells me the font is created, but not if it was set to one particular tree item.
I'd rather be phishing!
|
|
|
|
|
Maximilien wrote: The CTreeCtrl's item data (CTreeCtrl::SetItemData) is already used to hold data for each item.
You could extend your data adding the font type (create a struct containing all the necessary data and set the pointer to the struct instance as an ItemData)
|
|
|
|
|
Yes, I'm looking into that.
Thanks.
I'd rather be phishing!
|
|
|
|
|
Fighting to solve old plan C errors, I met another issue: error C2143: syntax error
I have the following code:
typedef struct test test_t;
struct test
{
const char* name;
const char* name_option;
...
...
};
and
test_t test_123 = {
.name = "Bibi", .name_option = "Bibi_One",
};
How can I get rig of this error ?
|
|
|
|
|
This form of initialization is valid in GNU C, and is valid in other compilers only if they support C99 or later. I don't remember off-hand whether this is supported in C++.
You can make this compatible with C89 by adding the missing initializers, e.g.:
test_t test123 = { "Bibi", "Bibi_one", foo, bar };
Where foo and bar are the values for missing members in the struct.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Get rid of the member names in the initalization, it's not valid in C++. You can only pass values, and these will be used to initialize the members of the struct in the order of their definition. You don't need to provide values for all members - if you don't, the rest will use default values:
test_t test_123 = { "Bibi", "Bibi_One" };Special case: if you try to initialize a C array in this manner with less values than it's size, the remainder of the array will be initialized with the last value of your initializer list. This code will initialize your entire array with 1s:
int my_array[9] = {1};You can read up on this topic in many articles on the web, just use the correct search term: initializer list.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Thank you all of you, it works.
|
|
|
|
|
I have a legacy C code:
char* file_name[0];
which generate a warning: warning C4200: nonstandard extension used : zero-sized array in struct/union
it is correct to write:
char* file_name[_MAX_PATH];
? I don't know the impact of this modify...
|
|
|
|
|
_Flaviu wrote: it is correct to write:
char* file_name[_MAX_PATH];
Yes, it is correct presuming you are going to define the array of pointers
|
|
|
|
|
Or
char* file_name[1];
? anyway, is more than 0 
|
|
|
|
|
Well, it all depends upon what you are going to achieve... 
|
|
|
|
|
_Flaviu wrote: Or
char* file_name[1];
Yes.
The only reason someone would declare zero-length is to dynamic allocate the array. You should change the array length to [1]. If you change it to _MAX_PATH (260) then you will be wasting 1036 bytes on a 32 bit machine and wasting 2072 bytes on a 64 bit machine.
Wasting bytes is punishable by death.
Best Wishes,
-David Delaune
modified 6-Aug-19 5:37am.
|
|
|
|
|
Quote: You should change the array length to [1]
Quote: Wasting bytes is punishable by death
Take your own conclusions. 
|
|
|
|
|
Hmmm,
The law states that wasting bytes less or equal to 1 * sizeof(pointer) is allowed but only in the month of August.
I guess he could remove the array qualifier but then that would probably break his compile.
Best Wishes,
-David Delaune
|
|
|
|
|
Disabling the warning is an option.
|
|
|
|
|
|
Thank you !
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
