C / C++ / MFC

Re: Regular expression confusion (std::regex_replace).

31-Jan-20 9:27

(the pre tag seems to be broken with the code)

const std::wstring expression( L"Value stored = $(_VARIABLE_NAME_)");
const std::wstring tmp(LR"(\$\(([^\(\)\$]*?)\))");
const std::wregex rx(tmp);
const std::wstring variableValue(L"A2347X$01GBFC");

std::match_results<std::wstring::const_iterator> matchResult;
const bool found = std::regex_search(expression, matchResult, rx);
if ( found )
{
    const std::wstring expressionOut = std::regex_replace(expression, rx, variableValue, std::regex_constants::format_first_only);
    std::wcout << "expressionOut  = " << expressionOut << "!\n";
}

When I run the above code (or use Regex Tester )

(I added the bold)
expressionOut = Value stored = A2347X_VARIABLE_NAME_GBFC

I was expecting (or I am wanting) the result to be

expressionOut = Value stored = A2347X$01GBFC

Is there a way to treat the input "A2347X$01GBFC" as a "raw" input and not something to be parsed by the std::regex_replace ?

In our case, the string "A2347X$01GBFC" is something that a user can input manually.

I'm certain there is an way to do it, but I cannot see it.

Thanks.

I'd rather be phishing!

k505431-Jan-20 10:17

Re: Regular expression confusion (std::regex_replace).

31-Jan-20 10:17

I can't see it either. It seems you've got two options, either use format_sed, if you know that you wont have \1 in the replacement string, or you'll have to turn any single $ into $$ before passing in to regex_replace There really should be a format_no_format flag to turn off format replacements.

Maximilien31-Jan-20 12:21

Re: Regular expression confusion (std::regex_replace).

31-Jan-20 12:21

Awesome! Thanks.

Will try monday.

I'd rather be phishing!

Maximilien3-Feb-20 13:14

Re: Regular expression confusion (std::regex_replace).

3-Feb-20 13:14

The format_sed option seems to work; I will make the changes and push that to the test suites.

Thanks.

I'd rather be phishing!

k50544-Feb-20 3:35

Re: Regular expression confusion (std::regex_replace).

4-Feb-20 3:35

Be aware that sed_format uses "\0" to replace matches. In your case if the user input was "A2347\01GBFC", you'd get the same output as for "A2347X$01GBFC" with format_default. If that's not an issue, then you're good to go.

Joe Woodbury31-Jan-20 11:58

Joe Woodbury

31-Jan-20 11:58

Interesting. You could drop the capture group by eliminating the parentheses before the square bracket and after the question mark.

Edit: It seems the more correct way is to create a non-capturing group by adding "?:" after the group's opening parentheses:

const std::wstring tmp(LR"(\$\((?:[^\(\)\$]*?)\))");

Added: You could also scan the input and double up any dollar signs.

modified 31-Jan-20 18:06pm.

Re: Regular expression confusion (std::regex_replace).

Maximilien31-Jan-20 12:21

31-Jan-20 12:21

Awesome! Thanks.

Will try monday.

I'd rather be phishing!

gcov linker errors

Vaclav_30-Jan-20 9:05

30-Jan-20 9:05

I have now build both project and its library using ARM architecture.
The library compiles and links - no error.
The library contains one test C++ class with only constructor / destructor implemented.
This is important to note - see the NOTEs at the end of the post.

The main program compiles but fails to link with errors indicating problem with "gcov".

The attached partial crosscompiler make output of library build indicates addition of "gcov" related options.
They have been put there as standard IDE options for building library.
I did NOT added these options.

make -j4 all 
Building file: ../MODULE/M_ARM_TEST/CARMTEST.cpp
Invoking: Cross G++ Compiler
arm-linux-gnueabihf-g++ -O0 -g3 -p -pg -ftest-coverage -fprofile-arcs -Wall -c -fmessage-length=0 -v -MMD -MP -MF"MODULE/M_ARM_TEST/CARMTEST.d" -MT"MODULE/M_ARM_TEST/CARMTEST.o" -o "MODULE/M_ARM_TEST/CARMTEST.o" "../MODULE/M_ARM_TEST/CARMTEST.cpp"
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-g++

The attached partial output of main program posts the "gcov" errors.

lRPI_BT_LIB_ARM -lbluetooth
/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_LIB_ARM/Debug/libRPI_BT_LIB_ARM.a(CARMTEST.o): In function `_GLOBAL__sub_I_65535_0__ZNSt10C_ARM_TESTC2Ev':
/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_LIB_ARM/Debug/../MODULE/M_ARM_TEST/CARMTEST.cpp:42: undefined reference to `__gcov_init'
/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_LIB_ARM/Debug/libRPI_BT_LIB_ARM.a(CARMTEST.o):(.data+0x28): undefined reference to `__gcov_merge_add'
collect2: error: ld returned 1 exit status

NOTE The library source code line #42 is where error is actually indicated in output , at the closing bracket of "std" namespace comment

NOTE 42 } /* namespace std */

1. What is the purpose of having -ftest-coverage -fprofile-arcs option SPECIFICALLY for library? I do not have them in any other IDE build programs.
I did not try to delete them, perhaps after I have some more knowledge about their purpose.
2. I did try to add -lgcov to program linker but it did not work.
I understand that gcov is some kind of utility tracking application and not sure why I need it.

Any help woudl be appreciated.
Cheers

Richard MacCutchan30-Jan-20 9:15

Richard MacCutchan

30-Jan-20 9:15

It is not clear where that reference is coming from, but most likely in one of the header files if you did not make a specific call to it. Or did you call to some other library which in turn requires gcov? Take a look at __gcov_init - Google Search[^] for some similar issues.

Vaclav_30-Jan-20 9:49

30-Jan-20 9:49

Thanks for reply,
I did ask Mrs Google - and this is a common , used by others, way to fix the error.

# compile with coverage
CFLAGS += -g -fprofile-arcs -ftest-coverage
LDFLAGS += -lgcov

I did added -lgcov , but it did not work.

This error showed up after I added the new library which has no code , no headers, except one test class.

There are no other library referenced in this new add.

Richard MacCutchan30-Jan-20 9:55

Richard MacCutchan

30-Jan-20 9:55

Vaclav_ wrote:
This error showed up after I added the new library

Well that should give you a clue. The only way to find out what is happening is to look into the addition that caused the message. For some reason that new library must be calling the error.

leon de boer30-Jan-20 21:43

leon de boer

30-Jan-20 21:43

-lgcov is not a linker directive it's a library link and it won't work in LDFLAGS

The library links needs to go on the extreme right of the final linker call
So I am clear that is the last call that joins all the individual compiles up.

So there is exactly one line it needs to go on which is the final line executed to link

In vino veritas

Vaclav_31-Jan-20 5:32

SOLVED Re: gcov linker errors

31-Jan-20 5:32

Leon,
I got sidetracked by another issue, and this one was "FIXED" - see my next post.
From my research - it is optioned / initialized in the library I have build and I really do not understand what it supposedly doing with just the options being set. It is definitely incomplete.
I did try to delete the options, but it is "built-in".

Vaclav_30-Jan-20 10:30

PNG image shown is missing 1 pixel right and 1 pixel bottom

30-Jan-20 10:30

SOLVED
Added --coverage to main program linker options.
From description it should make no difference if it is
complier or linker option.

Still not sure if I ever use if it supposedly created (where?) the "gconv" utility "executable" which I did not program.

sdancer7530-Jan-20 2:53

sdancer75

30-Jan-20 2:53

Using the code below (called from void CLoadPngDlg::OnPaint()) I am trying to view a PNG file that already included in the resource (IDB_FULLSCRINFOBAR_OPAQ_TEST).

As you can see in the image attached the bottom red line and the rightmost column of pixels are not shown.

https://i.imgur.com/Ug6gYjr.jpg

Image Attached[^]

What seems to be the problem here?

C++

BOOL CLoadPngDlg::ShowPngAt(CDC *dcWnd) {	

	CGdiPlusBitmapResource		*pPngChannel;
	UINT						nWidth,nHeight;
	CRect						rectClient;
	CBitmap						Bitmap, *pOldBitmap;	
	CDC							bitmapDC;
	CDC							*dialogDC;

	pPngChannel	= NULL;
	pPngChannel = new CGdiPlusBitmapResource;

	if (!pPngChannel->Load(IDB_FULLSCRINFOBAR_OPAQ_TEST, _T("PNG"))) {
		delete pPngChannel;
		return TRUE;
	}

	GetWindowRect(&rectClient);

	// Get size of bitmap.
	nWidth = pPngChannel->m_pBitmap->GetWidth();
	nHeight = pPngChannel->m_pBitmap->GetHeight();

	bitmapDC.CreateCompatibleDC( dcWnd ); 
	Bitmap.CreateCompatibleBitmap(dcWnd, nWidth, nHeight);
	pOldBitmap = bitmapDC.SelectObject(&Bitmap);	

	Gdiplus::Graphics graphics(bitmapDC.GetSafeHdc());										
	graphics.DrawImage(*pPngChannel, 0, 0);

	dcWnd->BitBlt(0, 0, rectClient.Width(), rectClient.Height(), &bitmapDC,   0,  0,   SRCCOPY );

	bitmapDC.SelectObject( pOldBitmap );
	bitmapDC.DeleteDC();


	if (pPngChannel != NULL)
		delete pPngChannel;


	return FALSE;

}

sdancer75

Re: PNG image shown is missing 1 pixel right and 1 pixel bottom

Richard MacCutchan30-Jan-20 6:29

Richard MacCutchan

30-Jan-20 6:29

Where is the code for CGdiPlusBitmapResource? I can only assume that it returns the wrong values for height and width.

Re: PNG image shown is missing 1 pixel right and 1 pixel bottom

sdancer7530-Jan-20 6:53

sdancer75

30-Jan-20 6:53

Thanks for your answer. The CGdiPlusBitmapResource is part of an older codeproject.com article at
Loading JPG & PNG resources using GDI+[^]

Anyway, I found the root of the problem. I had to call DrawImage with the size of the image. Now all works just fine.

C++

graphics.DrawImage(*pPngChannel, 0, 0, 800, 50);

sdancer75

IGNORE THIS !!! file not recognized: File format not recognized

Vaclav_29-Jan-20 5:45

Re: file not recognized: File format not recognized

29-Jan-20 5:45

THIS IS embarrassing
SOMEHOW MY MAIN PROJECT BECAME PLAIN gcc
I NEED TO REVERt BACK TO CROSSCOMPiled GCC!

Build the library for ARM, easy task in Eclipse ( for a change).
Still no go. missing some option.

Never mind it is simple

the library is compiled on x86 ,
now I need it to compile it for ARM.

Any opposing opinions are welcome.
I wish I could do it on x86.

Any file .a ,or .so perfectly working , and linked using -l / -L , in GCC compiled application CANNOT be accessed in crosscompiled version of the SAME project.

See attached highlighted part of the " make " output text.

Building target: RPI_BT_CLIENT
Invoking: Cross G++ Linker
arm-linux-gnueabihf-g++ -L"/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_LIB/Debug" -L/media/z/MISC_COPY_LABEL/RPI_library/lib -L"/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/LIB_SHARED/Debug" -
....
bluetooth_sample_SDP.o   -lbluetooth -lLIB_SHARED
.....
/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/LIB_SHARED/Debug/libLIB_SHARED.so: file not recognized: File format not recognized

Does crosscompiler expect some other option ??

Please no more "how to use -l / -L"

modified 29-Jan-20 13:13pm.

k505429-Jan-20 6:03

Re: file not recognized: File format not recognized

29-Jan-20 6:03

You're probably trying to link in an x86-64 version of the lib, not ARM.

Vaclav_29-Jan-20 6:44

Re: file not recognized: File format not recognized

29-Jan-20 6:44

and you are probably correct.

I am getting this error

lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/5/crtend.o /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crtn.o
/usr/bin/ld: skipping incompatible /media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_LIB_ARM/Debug/libRPI_BT_LIB_ARM.a when searching for -lRPI_BT_LIB_ARM
/usr/bin/ld: cannot find -lRPI_BT_LIB_ARM

The error is little confusing - skipping and cannot find it - both ?

And indeed my X86 is 64 bits and the RPI is 32.

But it only bothers the additional library.
I'll add -m32 and watch for smoke

Vaclav_29-Jan-20 6:58

Re: file not recognized: File format not recognized

29-Jan-20 6:58

Bummer
-m32 does not compute as ARM option

k505429-Jan-20 7:15

Re: file not recognized: File format not recognized

29-Jan-20 7:15

Vaclav_ wrote:
The error is little confusing - skipping and cannot find it - both ?

Not really. The linker found a copy of the lib, but it has the wrong architechture, so it skipped over that one, but then did not find a suitable candidate. If you had x86, x86-64, PowerPC and MIPS versions of that lib, I expect you would get skipped messages for each.

I notice you're calling /usr/bin/ld. If you are cross compiling for an rpi, should that be calling /usr/bin/arm-linux-guneeabihf-ld? I think maybe you've misconfigured your project to produce X86 output, and not ARM.

Vaclav_29-Jan-20 15:39