|
One thought that's just occurred to me is that you could learn C while programming an Arduino. It's technically a superset of C (it has a string type) but if you buy a starter kit[^] you'll have a set of tutorials to complete that may (or may not) help you to learn as you go. Some people say they find it easier to stay motivated when they have some tangible result.
I can't really say how good the learning tutorials are though, because when I got my first Arduino I already knew a reasonable amount of C so I didn't really need to learn any language specific stuff from the documentation - just hardware specifics.
|
|
|
|
|
I am trying to implement coroutines in c++ (I had to reinvent the wheel for my project).
coroutine.h
class coroutine {
public:
void (*action1)(int);
Stack local_stack;
coroutine(void (*action)(int ), int id);
coroutine.cpp
coroutine *global_coro;
fcontext_t context_array[2];
coroutine :: coroutine(void (*action)(int), int id)
{
global_coro=this;
action1=action;
fcontext_t f_ctx = make_fcontext(global_coro->local_stack.local_stack, 1000, global_coro->action1);
context_array[0]=f_ctx;
}
coroutine::~coroutine(){}
void coroutine::yield(){
transfer_t tr = jump_fcontext(context_of_current_corotine, context_of_next_coroutine );
Following is my stack class which allocates a block of memory to every coroutine from a global Memory pool
stack.h
extern MemoryPool memPoolObj;
class Stack {
public:
void *local_stack;
MemoryPool& m_memPool=memPoolObj;
Stack();
~Stack();
};
Stack.cpp
#include "Stack.h"
MemoryPool memPoolObj;
Stack::Stack() {
auto *local_stack= m_memPool.Allocate();
}
Stack::~Stack() {}
Context.h
typedef void* fcontext_t;
struct transfer_t
{
fcontext_t fctx;
void * data;
};
extern "C"
transfer_t jump_fcontext( fcontext_t const to, void * vp);
extern "C"
fcontext_t make_fcontext( void * sp, std::size_t size, void (* fn)( int) );
Main.cpp
#include "coroutine.h"
void workPackage(int id){
printf("Coroutine with id %d is called\n", id);
coroutine::yield();
printf("Coroutine with id %d is resumed after first yield\n", id);
coroutine::yield();
printf("Coroutine with id %d is resumed after second yield\n", id);
}
int main() {
coroutine Coro1(workPackage, 1);
coroutine Coro2(workPackage, 2);
printf("Main is finished \n");
}
My program compiles but gives segmentation fault during execution. Valgrind gives the following information and i am not able to solve the problem. I will provide the assembly file also if needed. Any help would be appreciated
Use of uninitialised value of size 8
==24145== at 0x10922B: make_fcontext (in /home/user1/eclipse-workspace/coroutines/Debug/coroutines)
==24145== by 0x10912D: main (main.cpp:32)
==24145==
==24145== (action on error) vgdb me ...
==24145== Continuing ...
==24145== Invalid write of size 8
==24145== at 0x10922B: make_fcontext (in /home/user1/eclipse-workspace/coroutines/Debug/coroutines)
==24145== by 0x10912D: main (main.cpp:32)
==24145== Address 0xffffffffffffffe8 is not stack'd, malloc'd or (recently) free'd
|
|
|
|
|
Where is the code for make_fcontext , which is shown as the place where the error occurs?
|
|
|
|
|
My project structure in eclipse is as follows
Coroutines
Src
Debug
Code for make_fcontext is in src folder in file "make_x86_64_sysv_elf_gas.S"
.text
.globl make_fcontext
.type make_fcontext,@function
.align 16
make_fcontext:
movq %rdi, %rax
andq $-16, %rax
leaq -0x40(%rax), %rax
movq %rdx, 0x28(%rax)
stmxcsr (%rax)
fnstcw 0x4(%rax)
leaq trampoline(%rip), %rcx
movq %rcx, 0x38(%rax)
leaq finish(%rip), %rcx
movq %rcx, 0x30(%rax)
ret
trampoline:
push %rbp
jmp *%rbx
finish:
xorq %rdi, %rdi
call _exit@PLT
hlt
.size make_fcontext,.-make_fcontext
.section .note.GNU-stack,"",%progbits
|
|
|
|
|
You will need to use the information from the stack trace to figure out which line caused the SEGV, and which value has not been set.
|
|
|
|
|
A quick glance brings up a problem here:
Stack::Stack() {
auto *local_stack= m_memPool.Allocate();
}
Perhaps I misunderstand the intention, but shouldn't this be:
Stack::Stack()
: local_stack(m_memPool.Allocate())
{}
|
|
|
|
|
Good catch; I missed that completely.
|
|
|
|
|
|
Can anybody help me? I want to launch a word processor(MS Word) in an MS Visual C++ dialog based application. How this can be done exactly. Thanks in advance for your help.
|
|
|
|
|
Would you like to embed MS Word into your dialog or just spawn the MS Word application from your dialog?
|
|
|
|
|
open MS Word from the dialog
|
|
|
|
|
Then use ShellExecute(Ex).
|
|
|
|
|
|
Don't have much idea about it...
|
|
|
|
|
Have you considered ShellExecute() ?
"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
|
|
|
|
|
Trying now...
Thanks for your help
|
|
|
|
|
I want to print a bitmap. To avoid printing small bitmap I set CScrollView mode as MM_LOMETRIC with sizes 3830x1995. I have created the bitmap and made the bitblt to the screen. There were everythig just like I want on the screen and on the print preview but when I printed the document I`ve got very bad result.
It seems to me that printer does not see a bitmap the same way as print preview does. Pay attantion that the first ractangle puts directly on the DC and memDC puts into it. Are there any ideas how to fix this mismatch between print previw and the real printing?
MFC_T_Print_1.zip[^]
void OnDraw()
{
CPen pen;
pen.CreatePen(PS_SOLID, 1, RGB(0, 0, 0));
CPen* OldPen = pDC->SelectObject(&pen);
CRect rcView;
GetClientRect(rcView);
int iClientWidth = rcView.right;
int iClientHeight = rcView.bottom;
int iMemWidth = 1900;
int iMemHeight = 950;
CDC memDC;
CBitmap memBitmap;
memDC.CreateCompatibleDC(pDC);
memBitmap.CreateCompatibleBitmap(pDC, iMemWidth, iMemHeight);
memDC.SelectObject(&memBitmap);
memDC.SetMapMode(MM_LOMETRIC);
CPen pen1;
pen1.CreatePen(PS_SOLID, 3, RGB(0, 0, 0));
memDC.SelectObject(&pen1);
CBrush brBK;
brBK.CreateSolidBrush(RGB(255, 255, 255));
memDC.SelectObject(&brBK);
RECT rc;
rc.left = 0;
rc.top = 0;
rc.right = iMemWidth;
rc.bottom = iMemHeight;
memDC.FillRect(&rc, &brBK);
memDC.Rectangle(rc.left, rc.top, rc.right, -rc.bottom);
memDC.MoveTo(0, 0);
memDC.LineTo(1900, -950);
memDC.MoveTo(0, -950);
memDC.LineTo(200, -750);
CFont font;
font.CreateFont(
50,
0,
0,
0,
FW_NORMAL,
FALSE,
FALSE,
0,
ANSI_CHARSET,
OUT_DEFAULT_PRECIS,
CLIP_DEFAULT_PRECIS,
DEFAULT_QUALITY,
DEFAULT_PITCH | FF_SWISS,
_T("Arial"));
memDC.SelectObject(&font);
memDC.TextOut(100, -100, _T("Hello"));
pDC->BitBlt(10, -10, iMemWidth, -iMemHeight, &memDC, 0, 0, SRCCOPY);
font.DeleteObject();
brBK.DeleteObject();
memDC.DeleteDC();
memBitmap.DeleteObject();
pen.DeleteObject();
pen1.DeleteObject();
}
void OnInitialUpdate()
{
CScrollView::OnInitialUpdate();
CSize sizeTotal;
sizeTotal.cx = 3830;
sizeTotal.cy = 1995;
SetScrollSizes(MM_LOMETRIC, sizeTotal);
}
MFC
|
|
|
|
|
You need to set the mapping mode in the actual device context where you are writing the data. In this case you need to set it into the PrinterDC to make it consistent with the screen settings, and the actual image. See Mapping Modes and Translations | Microsoft Docs[^].
|
|
|
|
|
Mapping mode (MM_LOMETRICETRIC) has been set both in OnPrepareDC() and in OnPrint(). The result is the same - we still have mismatch between print preview and the real printing.
|
|
|
|
|
The screen works on 96DPI unless you are in a DPI aware app which if you want to confirm
HDC screen = GetDC(0);
long hPixelsPerInch = GetDeviceCaps(screen,LOGPIXELSX);
long vPixelsPerInch = GetDeviceCaps(screen,LOGPIXELSY);
So it's setup that 96 pixels = 1 inch, not in the real world but that is what 96 pixel represents on screen
When you map it to 0.1mm per device space 25.4mm = 1 inch so 254 pixels now = 1 inch
Now the same works for the resolution of your printer depending on it's resolution
So lets say you are printing at 150dpi on the printer so when you set it to 0.1mm per device unit
1500 pixels = 1 inch on the printer
Normallly the printer select dialog goes close because it knows the screen is 96DPI and it knows what the
printer DPI is but you have messed about with the modes and thrown it out by a fair bit.
It's usually pretty close all by itself
Anyhow the scaling is easy .... correct size = size * effective Printer DPI / effective Screen DPI;
When you select the printer you can get it's DC and pass it into the code above and get it's hPixelsPerInch
and vPixelsPerInch just as you did the screen. Hence you can work out the scale.
In vino veritas
modified 12-Sep-18 13:16pm.
|
|
|
|
|
Thak you for the answer but there is a problem with the bitmap that is inscribed in the ractangle.
If you look at the print preview - you will see this bitmap well. But if you print the real page you will see that ractangle is printed perfectly but the bitmap (inscribed into ractangle) was cut from the right side and the bottom.
If there was a problem with dpi we would have problems both with the ractangle and with the bitmap.
Print preview: Preview[^]
Real print: Printed page[^]
|
|
|
|
|
And there is nothing surprising about that you only made your DC a fixed size based on screen,
Rough guess your printer is running at 300 DPI, confirm what resolution you have on printer?
let me jog your memory with your memory bitmap/DC (which matches the screen)
===> memBitmap.CreateCompatibleBitmap(pDC, iMemWidth, iMemHeight);
then you only transfer that screen size
====> pDC->BitBlt(10, -10, iMemWidth, -iMemHeight, &memDC, 0, 0, SRCCOPY);
Those sizes are in screen pixels the printer DC is different to iMemWidth, iMemHeight pixels,
It is hardly surprising you only get the top left corner, it is telling you the same thing
Remember the sizes on the transfer are in the DC pixels of the DC you use for the function.
You have pDC vs memDC and those are not the same DPI.
You would either need to StretchBlt or get the printer DC and work out the size to make the memory
bitmap that size because it has a different DPI.
If you can set the printer to 100 DPI which is as close to 96 DPI you will get close to what you want .
In vino veritas
modified 13-Sep-18 7:21am.
|
|
|
|
|
Nice idea but
I tried to make different Width and Height for display and printer. It broke Print Preview[^].
But when I`ve printed document the result was the same[^] .
int iMemWidth = 1900;
int iMemHeight = 950;
...
if (pDC->GetDeviceCaps(TECHNOLOGY) == DT_RASDISPLAY)
{
pDC->BitBlt(10, -10, iMemWidth, -iMemHeight, &memDC, 0, 0, SRCCOPY);
}
else if (pDC->GetDeviceCaps(TECHNOLOGY) == DT_RASPRINTER)
{
pDC->BitBlt(10, -10, 3830, -1950, &memDC, 0, 0, SRCCOPY);
}
Here is the source code:
MFC_T_Print_LOMETRIC.zip[^]
|
|
|
|
|
You aren't getting that memory DC's are basically free you aren't limited to just one and why they exist
Lets see if I can make you understand.
This stuff is only important for bitmaps you can print text all day and never need to know this stuff
1.) When you print bitmaps you make a new memory DC to match the printer not the screen!!!!
HDC SecondDC = CreateCompatibleDC( >>> PrinterDC <<<);
2.) Put your image on the memory DC and you use it to print .. just like you did the screen DC
3.) Now print it.
4.) Now you destroy the memory DC that matches the printer you are done with it.
At no point in that did I change or alter your screen bitmap/DC
What you aren't grasping is why you need a memory DC .. so lets deal with that because it is important.
So a true device DC may have a different planes and colour layout to your image and if that was done
at a driver level, every driver would have to know how to deal with every colour format. So they don't
do that the driver generally knows exactly one colour format usually RGB. The memory context is the
thing that knows all the different formats and is essentially device independent. So when you want to
print what a bitmap what you want is a memory context that matches the PRINTER DC not the screen.
That is all covered here .. I want you to carefully read the paragraph that starts with
"The original bitmap in a memory DC is simply a placeholder"
Memory Device Contexts | Microsoft Docs[^]
Now here is a tutorial on bitmap printing I want you to go to Part 9
https://www.dreamincode.net/forums/topic/261009-bitmap-printing-tutorial-in-c-win32/
I want you to take particular note of lines 9 to 13 which does this
prn = GetPrinterDC(hwnd);
cxpage = GetDeviceCaps (prn, HORZRES);
cypage = GetDeviceCaps (prn, VERTRES);
hdcMem = CreateCompatibleDC(prn);
HBITMAP hbmOld = (HBITMAP)SelectObject(hdcMem, hBitmap);
If you understood the above you will understand what they are doing but lets walk thru it
1.) They got the printer DC because that is our device NOT the screen
2.) They got the width and height of the printer from that DC.
3.) They made a memory DC to the printer DC to transfer the image onto (printer DC not screen DC)
4.) They selected the bitmap you want to print to the memory context so it initializes how
to convert the bitmap for the printer.
Then they will transfer all the image and stuff onto the memory DC, then they will copy it to
the printer and then they will throw the memory context away it isn't needed anymore.
The important part here is the memory context that matches the printer is the right scale
and it has the right colour plane organization and it has nothing to do with your display
memory context which is dangling around elsewhere in your code.
In vino veritas
modified 13-Sep-18 11:47am.
|
|
|
|
|
Hi, I met a thread synchronization scenario in a small code.
if (rcvd == true)
{
read rcv_buffer
...
rcvd = false;
}
dataCB(int ch_id, char *buf, int len, char stat)
{
rcvd = true;
receivenotify(chid, rcv_buffer, sizeof(rcv_buffer), dataCB,0);
}
here, rcvd = false in task A, can't stop task B produce data. how can I let task A, B synchronized.
add if (rcvd == false) in task B before receivenotify()? is that a dead lock ?
Thanks
|
|
|
|
|