|
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)
|
|
|
|
|
Hope it is OK to make new post.
I am still working on this assumption:
other
An object file to be fed straight into linking. Any file name with no recognized suffix is treated this way.
Adding full path to desired library to be added to existing library resolved the
"cannot find " issue.
Now the gcc++ needs to be told to actually link, contrary to the "other" instruction taken from Linux documentation.
I get same error when using libbluetooth.a.
'MODULE/M_TEST/CTEST.o' '-o' 'MODULE/M_TEST/CTEST.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
Finished building: ../MODULE/M_TEST/CTEST.cpp
g++: warning: /usr/lib/x86_64-linux-gnu/bluetooth: linker input file unused because linking not done
Building file: ../MODULE/M_SOCKET/CSOCKETCOMMON.cpp
Invoking: GCC C++ Compiler
|
|
|
|
|
You need to show us the command you are using to do the build. The message above suggests that you are only invoking the compile of some source module(s), so no library is needed.
|
|
|
|
|
Some very odd things here:
Vaclav_ wrote: 'MODULE/M_TEST/CTEST.o' '-o' 'MODULE/M_TEST/CTEST.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
That looks wrong. That looks like your compiler command could be boiled down to
g++ CTEST.o -o CTEST.o You're passing in and producing the same .o file, not creating an executable, only an intermediate object. In which case the g++ warning makes sense, since its telling you that the lib wasn't used to create the .o file. In which case you should be getting a g++ fatal error input file is same as output file.
Second thing is the warning itself. The path given is /usr/lib/x86_64-linux-gnu/bluetooth. Normally that would be libbluetooth.a. In which case the linker should be able to pick it up as -lbluetooth, since its in the expected location. It just doesn't have a name format that the linker recognizes as a library. I'd say say something messed up when installing the library, if this is indeed the case and you've not just messed up copying the output from your system to the forum.
|
|
|
|
|
As already noted by k5054, you (-o option) are asking the g++ to NOT perform the linking step.
Nevermind.
(thanks to k5054)
modified 28-Jan-20 15:54pm.
|
|
|
|
|
Oops, Ha Ha, actually, we both got that wrong. The compiler is quite happy to link an executable into a file named foo.o e.g.
$ g++ hello.cpp -o hello.o
$ ./hello.o
Hello World!
$
Its the -c option that compiles but does not link, so that must have been included in the command sent to the compiler.
|
|
|
|
|
Yes, of course you are right. Thank you for pointing out.
|
|
|
|
|
Stand-by.
I build some more test apps and "discovered" that type .so library has STANDARD IDE options for linker , but type .a , which I have been messing with, does NOT.
Also neither one of them show -l option, only -L.
Basically - forget IDE, back to GCC raw options.
|
|
|
|
|
Vaclav_ wrote: type .so library has STANDARD IDE options for linker , but type .a , which I have been messing with, does NOT.
That makes no sense, there are no such things as standard IDE options for compiling and/or linking. The options are determined by the specific compiler and linker in use. You may have an IDE that is set up to use the most common options for gcc, but you still need to modify it depending whether you are trying to create a static archive (.a), or shared object library (.so).
|
|
|
|
|
Post-mortem FYI
SOLVED(?)
1.Both projects ( IDE terminology) works as expected.
NOT REALLY SURE WHY.
2.The “mother” executable - project has -lbluetooth -lRPI_BT_LIB, but ONLY
-L "${workspace_loc:/RPI_BT_LIB/Debug}" optioned.
3. There are NO references / options to “bluetooth” in RPI_BT_LIB, only source includes.
3. Adding “bluetooth” as per this ( no -l or -L !)
other
An object file to be fed straight into linking. Any file name with no recognized suffix is treated this way.
Creates “cannot find ...” error
4. Adding “/usr/…/bluetooth” creates “ did not link ...” error but has no effect on processing.
(It was pointed out that GCC was not optioned to link )
5. running “make clear” idefinites full library file name - “libRPI_RT_LIB.a”
6. Using “standard IDE” ( I am calling IDE UI form "standard" ) to build type .a library gives NO linking options, however building .so gives ALL options.
7. Using “standard IDE form” to build a project – executable or library – creates “system” default includes.
NOT sure if they are used only for source or linking libraries.
As far as I can tell this whole mess was because I could not tell if I was using
wrong GCC options
or
wrong syntax
It was NEVER about (-l / -L ).
The unanswered question remains - how does the RPI_BT_LIB library manages to use "bluetooth" library.
|
|
|
|
|
Vaclav_ wrote: how does the RPI_BT_LIB library manages to use "bluetooth" library.
The same way that any code uses any library. Define the external references and add the library to the build process. Take a look at gcc library - Google Search[^] for more detailed information.
|
|
|
|
|
I am posting this here because I hope the actual output will help to solve the issue , and it is not small!
I have an app using bluetooth - linked to library "bluetooth". It works fine.
I need to identify the actual type of library ( Linux .a or .so ).
GCC options do not require prefix, such as "lib." or suffix - .a or .so thus GCC output cannot tell me the library file full name.
I also need the (-L) path to the library and GCC does not correlate -L with -l.
Help will be appreciated.
PS Please ignore the "undefined.." error.
Here is the actual GCC linker output
make all
Building target: RPI_BT_SERVER
Invoking: GCC C++ Linker
g++ -L/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_COMMON/src/MODULES/M_SOCKET_COMMON -L"/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_LIB/Debug" -v -o "RPI_BT_SERVER" ./src/MODULES/M_FILE_CLASS/CFILECLASS.o ./src/RPI_BT_SERVER.o -lbluetooth -lRPI_BT_LIB
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-6ubuntu1~16.04.12' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.12)
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/5/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-L/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_COMMON/src/MODULES/M_SOCKET_COMMON' '-L/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_LIB/Debug' '-v' '-o' 'RPI_BT_SERVER' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/5/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/5/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper -plugin-opt=-fresolution=/tmp/ccoEji8m.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --sysroot=/ --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro -o RPI_BT_SERVER /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/5/crtbegin.o -L/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_COMMON/src/MODULES/M_SOCKET_COMMON -L/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_LIB/Debug -L/usr/lib/gcc/x86_64-linux-gnu/5 -L/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/5/../../.. ./src/MODULES/M_FILE_CLASS/CFILECLASS.o ./src/RPI_BT_SERVER.o -lbluetooth -lRPI_BT_LIB -lstdc++ -lm -lgcc_s -lgcc -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
/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_LIB/Debug/libRPI_BT_LIB.a(CSOCKETCOMMON.o): In function `std::C_SOCKET_COMMON::SelectDevice(int)':
/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_LIB/Debug/../MODULE/M_SOCKET/CSOCKETCOMMON.cpp:144: undefined reference to `str2ba'
|
|
|
|
|
Knowing "why" helps to motivate people; otherwise, it sounds like "make work". Seems like knowing what OS you're running under would be more useful.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
OK, isn’t all of that info in posted output ?
|
|
|
|
|
Just check the directory where this library is installed and you will see which type it is.
|
|
|
|
|
try ldd myprog. If the library shows up in the output, then it is dynamically linked, e.g. a .so library. If it doesn't, then its a static library (.a).
Usually the linker (ld, not gcc), will prefer the dynamic library over the static, so the resulting executable will a) use new versions of the library, if it gets updated, and b) (less important these days) have a smaller on-disk footprint. If you are linking to the .so and you want to force the linker to use the static library you can do that with the following options to gcc
-Wl,-Bstatic -lsome_lib -Wl,-Bdynamic
If you don't add the -Wl,-Bdynamic at the end, then libc gets statically linked in, too, which is probably not what you want. Of course you could just pass -static to gcc for the final linking stage, and that will produced a static binary (no shared libs), which should run on most linux boxes of with the same architecture (e.g X86 or ARM). I say most, because if you compiled on say Ubuntu 18.04, and tried to run on something ancient, like maybe RedHat 9 (shrike), you would probably get a execution error.
But it would be helpful to know why you want to know this. Normally, we don't care whether we're linking to a dynamic or static library, just as long as the program works. Your question suggests to me that you're bumping up against an issue and are trying to force the OS into doing what you think it should, rather than working with the OS
|
|
|
|
|
The library works, was build few years back and I do not remember how I did it.
Reason for all this is that I need to implement same library in another project , therefore I need to identify the type and location. Hence "reverse engineering".
|
|
|
|
|
pick it in the makefile
ifeq (,$(wildcard somelibpath/sonelibrary.a))
endif
ifeq (,$(wildcard somelibpath/sonelibrary.so))
endif
You can even pick it out of a list of filenames in the makefile .. that is after all what the makefile is there for
In vino veritas
|
|
|
|
|
|
Hi
I read some articles on how to make a win32 prog DPI aware. I want to make a dialog which has
windows controls, bitmaps and gdiplus objects combined.
I am using VS2019 and started a MFC app from scratch.
What would be the right way to get a DPI aware app, because I set DPI to high in the MFC app setting and used GetDeviceCaps to draw the lines. But when DPI is set to HIGH the lines do not match with the controls anymore. When I switch it off, the graphics look blurry, but are on the right position.
I made some screenshots to show what I mean:
Windows 100%, DPI aware to HIGH
Windows 150%, DPI aware to HIGH
Windows 150%, DPI aware to NO
What would be the right approach, so windows controls and graphics match on all resolutions?
thanks
regards
Erich
|
|
|
|
|
In Windows 10 you make your apps "fluent" and don't worry about that stuff. The user controls text size through "Ease of Access" in the control panel.
Stick to Segoe UI fonts; use the "standard resources" for headings and body; size everything divisible by 4; stick to PNGs, using transparent backgrounds when necessary to reduce size.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Hi
Thanks, but that didnt answer my question. How should I draw Gdiplus graphics and controls so that they are always drawn correctly (same position) on all Dpi settings?
The code that I use can be seen in the first screenshot.
Regards
Erich
|
|
|
|
|
Short answer you scale everything long answer you scale everything
Okay to get scale factor you need the DPI of the screen which you use Win32 API
HDC Dc = GetDC(GetDesktopWindow());
int DpiX = GetDeviceCaps(Dc, LOGPIXELSX);
int DpiY = GetDeviceCaps(Dc, LOGPIXELSY);
ReleaseDC(GetDesktopWindow(), Dc);
if (DpiX != 96 || DpiY != 96)
{
double ScaleX = (double)DpiX/96;
double ScaleY = (double)DpiY/96;
}
In vino veritas
|
|
|
|
|
Hi
Thanks for your reply. I already tried to calculate the coord with GetDeviceCaps, but that does not work correctly! When I set 150% font size in windows I get a ratio of 144/96=1.5 as expected, but the controls and the dialog itself do not scale that way!
Here a different example:
I have drawn two red rectangles, one with the size of the dialog and an inner one which is the size of a group box. For the size of the dialog rectangle I use GetClientRect. It works on all font sizes (DPI scalings) correct.
For the inner rectangle inside the group box I tried to recalculate the coords with GetDeviceCaps, but that does not work. If I change scaling in windows the inner rectangle is completely off.
So I tried to figure out the correct coords for the inner rectangle by trial and error. Below are the coords which draw the correct rectangles in relation to the group box.
But how can I calculate them, I get some weird values? In the x axis I would get a factor of 1.3328 and on the y axis a factor of 1.62 with 150% scaling, not 1.5 as expected!?
Screenshot at 100%
// coords at 100%
Dialog rectangle coord = 0/0 - 1445/832
group box rectangle coord = 624/9 - 1247/581
Screenshot at 125%
// coords at 125%
Dialog rectangle coord = 0/0 - 1685/1088
group box rectangle coord = 728/11 - 1456/761
Screenshot at 150%
// coords at 150%
Dialog rectangle coord = 0/0 - 1926/1344
group box rectangle coord = 831/13 - 1664/941
How can I calculate the right coordinates for these elements ?
thanks
regards
Erich
|
|
|
|
|
You are obviously loading the dialog from a resource file or template.
Those have a normal DPI scale of 48 and yes it gets messy.
1.) Don't do it .... manually create the dialog and insert the items.
or
2.) If you don't want to do it manually on window entries that draw on the WM_CREATE grab the size and scale of the window just like you did. Which is basically what Gerry is saying below and contain your draws to windows. That means if you want to draw something on the dialog background make an transparent invisible window in the resource so it scales with the rest of the dialog and draw on it.
You are sort of creating a mountain out of a molehill.
In vino veritas
modified 25-Jan-20 1:50am.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
