|
|
I have run out of options to resolve this in another forum.
The "conclusion " was - it is a linker error...
I am asking for help to actually correct the error.
There are no other errors posted.
This is ALL (of the errors ) I have to go by.
I will be happy to provide RELEVANT info , barring " what are you trying to do...".
I am deliberately NOT adding more info , for now, I just do not want to
derail / influence your ideas of fixing it.
lib/libQt5SerialPort.so /home/nov25-1/Qt/5.15.2/gcc_64/lib/libQt5Core.so -lGL -lpthread
/usr/bin/ld: /usr/bin/ld: DWARF error: invalid or unhandled FORM value: 0x23
mainwindow.o: in function `MainWindow::MainWindow()':
mainwindow.cpp:(.text+0x270): undefined reference to `ORIGINAL_TERMINAL_MainWindow::ORIGINAL_TERMINAL_MainWindow(QWidget*)'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: Leaving directory '/mnt/A_BT_DEC10/BT__PROGRAMS/A_APR9_MAR7_MAR19_CLEAN/A_BT_LIBRARY/mdi'
make[1]: *** [Makefile:293: mdi] Error 1
make: *** [Makefile:569: sub----A_BT_LIBRARY-mdi-make_first] Error 2
13:13:54: The process "/usr/bin/make" exited with code 2.
Error while building/deploying project A_Apr9_Mar7_MAR17_CLEAN (kit: Qt 5.15.2 (gcc_64))
When executing step "Make"
13:13:54: Elapsed time: 00:52.
|
|
|
|
|
Salvatore Terress wrote: I just do not want to
derail / influence your ideas of fixing it.
Is this a quiz?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Look at the error message (again):
mainwindow.cpp:(.text+0x270): undefined reference to `ORIGINAL_TERMINAL_MainWindow::ORIGINAL_TERMINAL_MainWindow(QWidget*)
In your mainwindow.cpp source you are calling the constructor of the ORIGINAL_TERMINAL_MainWindow class. But the linker did not find a definition of that constructor anywhere in the modules and libraries that are being used to build your application. So you need to find out exactly where it is defined and why the linker cannot find it.
|
|
|
|
|
Calling break inside nested for loops breaks all loops or just the inner loop where break is found?
Do I need to do this to exit all loops?
bool breakouter = false;
for(int x=0;x<count;x++)
{
for(int y=0;y<count;y++)
{
breakouter = true;
break;
}
if(breakouter)
break;
}
modified 11-Apr-24 7:46am.
|
|
|
|
|
Only the inner loop.
If you want to break out of more loops you can do something like:
for(int x=0;x<count && !breakouter;x++)
{
for(int y=0;y<count;y++)
{
breakouter = true;
break;
}
}
Mircea
|
|
|
|
|
Probably one of the last valid usecase for goto.
Especially if more than 2 inner loops.
Obviously, if your loops are doing many resources allocations, you'll need to do manual cleaning.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
|
Nah, using C++, that's horribile visu, but we could make an exception for you... 
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Maximilien wrote: Probably one of the last valid usecase for goto. Especially if more than 2 inner loops.
There were lots of valid 'goto' use cases cases, before for loops, while loops, and arbitrarily nested if-else, were invented.
Structured exit from multiply nested loops were invented 40+ years ago. In 1980 vintage CHILL, you could do
outermost: <loop control outermost>
<outermost statements>
intermediate: <loop control intermediate>
<intermediate statements>
inner: <loop control inner>
<statements>
exit intermediate;
<end inner>
<more intermediate statements>
<end intermediate>
<more outermost statements>
<end outermost>exit intermediate; would skip the "more intermediate statements" as well as further intermediate iterations, going directly to "more outermost statements" and continue with further outermost iterations.
If it rather said exit outermost;, the "more outermost statements" would be skipped as well, and the outermost loop would be left.
exit would be a short form of exit innermost;
This construct never made it into mainstream language such as the C derived ones. One partial explanation is differences in label semantics: In CHILL, a label identifies a block, not a point in the code. Furthermore, a statement is a block; it need not be embraced to be labeled.
I would be willing to trade a lot of other 'improvements' in more recent language extensions in favor of something like this.
Some concepts were not well developed in 1980. If a language of today were to introduce such a multi-level exit, it would probably come with something 'finally'-like mechanisms to do required cleanup operations regardless of loop exit method.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
The proprietary language in which I worked for many years had exactly what you describe. A label was for a BLOCK/ENDBLOCK that you could EXIT. A label could also precede IF, DO, and the equivalents of switch) without using the BLOCK keyword. The language was designed in the late 70s. This was in the telecom sector, so they probably took the design from CHILL.
|
|
|
|
|
Whenever I have such questions and I have them often I experiment w/ brief simple code and observe the behavior.
|
|
|
|
|
If my preprocessor define / undefine code hierarchy is in this sequence:
#define TEST
#undefine TEST
#define TEST
assuming it is read "top to bottom "
is "TEST" defined?
|
|
|
|
|
Salvatore Terress wrote: is "TEST" defined?
Most certainly
PS. By #undefine I assume you mean #undef. #undefine is not a standard preprocessor keyword
Mircea
|
|
|
|
|
It's easy enough to test it with a few lines of code. But why would you want to do this in the first place?
|
|
|
|
|
Sorry, I mixed up C and make.
THANKS
|
|
|
|
|
Sorry, I mixed up C and make.
THANKS
|
|
|
|
|
I rely on "intelisense" to help me to add CORRECT #include header file.
It sort of works in "left to right " fashion .
If I need to add "header_.h" file I have to step thru all options BEFORE I have "header_.h "
option.
#include "../ now intlesence gives all options after "/".
The "problem is " - until CORRECT , valid option is presented and selected I still have no way to see if it actually have an option to select desired header.
It would be nice to have option to determine required path BEFORE going thru the intelisense steps.
Sort of in reverse direction, opposite intelisense way.
Is there?
|
|
|
|
|
Since you are using #include " ... (double quotes) rather than #include < ... (angle brackets), you should know what the path is, as you are referring to local headers. But you could simplify things by adding the required header locations to the list of include directorie for the compiler to search.
|
|
|
|
|
For standard include files, doc pages for the function usually show what include file to use. For your own, or other dependencies, not much luck. You can try to grep function name in *.h files. Another strategy is to use an “uber include” that includes all or a lot of other h files, but it can slow down compilation.
Mircea
|
|
|
|
|
Mircea Neacsu wrote: Another strategy is to use an “uber include” that includes all or a lot of other h files, but it can slow down compilation.
I could challenge you to create a setup to prove the significance of this: A compilation that would consistently take noticeably (more than 1%) longer compilation time with an "uber include" than with individual includes for what you really need. I am quite sure that for an example showing significant higher compilation times, you would have to make a system wide search for .h files and include them all in the "uber" file 
There are other good reasons for avoiding the "uber" approach, though: Pollution of the name space. Not because I worry about symbol table sizes, but about too many symbols being acceptable. Sort of in the same class as languages that doesn't require declaration: If you misspell a name, it is not a misspelling, but creation of a new variable. Or, if your language lets you make local redefinitions of names in an outer scope: Remove the local (re)definition, and your code will reference a completely different variable. The "uber"
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
Mircea Neacsu wrote: Another strategy is to use an “uber include” that includes all or a lot of other h files, but it can slow down compilation.
I could challenge you to create a setup to prove the significance of this: A compilation that would consistently take noticeably (more than 1%) longer compilation time with an "uber include" than with individual includes for what you really need. I am quite sure that for an example showing significant higher compilation times, you would have to make a system wide search for .h files and include them all in the "uber" file
There are other good reasons for avoiding the "uber" approach, though: Pollution of the name space. Not because I worry about symbol table sizes, but about too many symbols being acceptable. Sort of in the same class as languages that doesn't require declaration: If you misspell a name, it is not a misspelling, but creation of a new variable. Or, if your language lets you make local redefinitions of names in an outer scope: Remove the local (re)definition, and your code will reference a completely different variable. The "uber" approach makes available to you a whole lot that you are not aware of, not its origins. You won't have an error message that a declaration is missing. You don't know what you are making use of. One day someone adds a similarly defined function to your project, doing things in a different way, and your code fails ...
Ideally, you should know every single instruction your code executes. That is of course impossible; we have to rely on libraries, OS functions etc., but we select them, deliberately and concerned. The "uber" approach invites to introducing a lot of code that is not at all selected, neither deliberately nor concerned, it just is there, ready to manipulate your data in ways that you do not know.
Blackboxing principles go both ways: Your class, module, namespace or whatever should not expose more of itself that what is absolutely necessary for others to know. But at the same time: Inside that black box, you should not see more of the environment than absolutely necessary for the blackbox to know. One of the nice features of VS is that it tells when you are using namespaces, but not using any names from them!
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
Sort of in reverse direction, opposite intelisense way.
Is there?
concluding from discussion which "went sideways" ( am I allowed to have an opinion ?)
there is no such option
|
|
|
|
|
Fair enough, but your quote is not from the post that you have attached your comment to. (I am not offended, I just want to point it out.)
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
May I please inquire are you stating the compiler you are utilizing provides no means to specify a list of directories to search for #include's. That is difficult to believe. May I please inquire compiler purveyor.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
