|
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.
|
|
|
|
|
Awesome! Thanks.
Will try monday.
I'd rather be phishing!
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
-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
|
|
|
|
|
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".
|
|
|
|
|
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.
|
|
|
|
|
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?
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);
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
|
|
|
|
|
Where is the code for CGdiPlusBitmapResource? I can only assume that it returns the wrong values for height and width.
|
|
|
|
|
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.
graphics.DrawImage(*pPngChannel, 0, 0, 800, 50);
sdancer75
|
|
|
|
|
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.
|
|
|
|
|
You're probably trying to link in an x86-64 version of the lib, not ARM.
|
|
|
|
|
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
|
|
|
|
|
Bummer
-m32 does not compute as ARM option
|
|
|
|
|
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.
|
|
|
|
|
I am sorry.
Yes, I got it all mixed up as far as architecture. .
From the start of this project I did not like terms "server / client".
Now I got caught in my own trap.
I am renaming my projects
RPI_BT_SERVER_X86 - runs on PC X86-64
RPI_BT_CLIENT_ARM runs on ARM7 32 bits
Cheers
|
|
|
|
|
The task is to replace - looks for all occurrences of string from and replaces it with string to.
It is possible to specify one or more files on which to perform the replace
operation(s) in a single replace command.
and this is my code:
void replace(char* OldWord, char* NewWord)
{
char *result = NULL;
char buff[1000];
char c;
char line[1000];
FILE * f = fopen ("file1.txt", "r+");
int count=0;
while (fgets(buff, sizeof(buff), f))
{
result = replaceWord(buff, OldWord, NewWord);
//
}
//
//free(result);
}
char *replaceWord(const char *s, const char *oldW,const char *newW)
{
char *result;
int i, cnt = 0;
int newWlen = strlen(newW);
int oldWlen = strlen(oldW);
static int k=0;
k++;
char newline[1000];
FILE * fp;
// printf("%s\n",oldW);
//printf("%s\n",newW);
// Counting the number of times old word
// occur in the string
for (i = 0; s[i] != '\0'; i++)
{
if (strstr(&s[i], oldW) == &s[i])
{
cnt++;
// Jumping to index after the old word.
i += oldWlen - 1;
}
}
// Making new string of enough length
result = (char *)malloc(i + cnt * (newWlen - oldWlen) + 1);
i = 0;
while (*s)
{
// compare the substring with the result
if (strstr(s, oldW) == s)
{
strcpy(&result[i], newW);
i += newWlen;
s += oldWlen;
fp = fopen ("file1.txt", "w");
rewind(fp);
fseek(fp,i-newWlen,SEEK_SET);
fprintf(fp,"%s\n",result);
}
else
{
result[i++] = *s++;
}
}
result[i] = '\0';
fp = fopen ("file1.txt", "w");
fprintf(fp,"%s\n",result);
// printf("%d\n",k);
return result;
}
the replace function does not give the desired output
The command line looks like:
./a.out replace old_word new_word files.txt
must replace old_word with the new_word in all files.
|
|
|
|
|
Member 12957547 wrote: It is possible to specify one or more files on which to perform the replace
operation(s) in a single replace command.
Why "in a single replace command"?
Why not just open your files in the loop and perform the replacement in each file? 
|
|
|
|
|
because I do not know how many items get from the CLI
|
|
|
|
|
Member 12957547 wrote: because I do not know how many items get from the CLI |
Yes, you do, or at least main() does.
int main(int argc, char **argv)
argc is the number of arguments passed to main, and argv is an array of strings containing the command line arguments. Remeber that argv[0] is the program name, so argc is always > 0.
The following will print all the command line arguments
#include <stdio>
int main(int argc, char **argv)
{
for(int i = 0; i < argc; ++i)
printf("argv[%d] = \"%s\"\n", i, argv[i];
return0;
}
|
|
|
|
|
Haven't tried to run your code, but I do notice a couple things:
1: you call fopen() several times, but there's no corresponding fclose(). If you had a large file (say the text of the bible), and wanted to replace, "god" with "jimmy", you would probably run out of file handles before completing the task.
2: you continually call fopen on the same file. fopen("file1.txt", "w") truncates the file, so some future read may return EOF unexpectedly. [NB not necessarily the next read, as the call to fgets might fill an input buffer, which following calls use, rather than continually reading from the file] My suggestion would be to open a temporary file and write your output there, then copy or replace the input file with the temp file. tmpfile() might be useful, here.
3: fgets() reads up to size-1 bytes from the input stream. What happens if you have very long lines (over 999 chars, in your case), and the word you want occupies chars 996-1003? You'll get the first 3 chars in one read and the remaining 4 in the next, missing an occurrence. Might I suggest you look at getline().
4: do you need to concern yourself with word case? Do you need to replace "babble" with "brook", "Babble" with "Brook" and "BABBLE" with "BROOK"?
|
|
|
|
|
Member 12957547 wrote:
the replace function does not give the desired output
If that is the case, I'd take a step back and get it working before worrying about files. Just send the function a string of characters, and the find/replace terms. After that, then rope the file contents back in.
"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
|
|
|
|
|
A couple of things I've noticed:
1. You are always using 'file1.txt' in your code, not the filename(s) passed as argument
2. As has been pointed out, lines can be longer than 1000 chars.
3. You never close the file you've opened. That will cause changes in one file buffer to overwrite previous changes once the files are closed (or at the end of the program).
4. You only check for one occurence of a word per line. What if there are multiple occurrences?
Suggestions:
- As already pointed out, start with your replace functions and make sure they work as intended, before dealing with files!
- Make sure you always close the files you've opened
- Write the modified text into another, temporary file. Later erase the original file, and rename the temporary one. That way you can just keep on reading/writing without needing to close/open the file over and over again.
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)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
