|
No that doesn't help at all. Making it as simple as I can...
There is a set (one or more) objects that use the configuration.
There is another set (one or more) objects that manage the configuration (lets say read it from a file.)
The two sets must not be the same.
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
The part in <> should be a type and the compiler is complaining that it doesn't know what data_list is. If it is a type, make sure you include the correct header so that it can be found.
If what you actually meant was for data_list to be the name of the function argument, it should be more like this:
explicit Form_SetupLocalAdapter(QList<*DataListType> data_list);
- replacing DataListType with the type (or base type) of data_list.
|
|
|
|
|
|
You probably meant something similar to
explicit Form_SetupLocalAdapter(QList <QString> * data_list);
(where the type you're actually storing in the list should replace the QString in the angular brackets)
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Member 14968771 wrote: So here is my latest attempt to resolve it and I sill need some real help , no RTFM PLEASE.
Just noting that many years ago I would spend time on a specific forum for the Perl language.
One of the leading authorities and author/co-author of a number of books would attend.
And his answers often were RTFM and sometimes (or often) ranting about it quite a bit.
So not much you can do about complaining about the quality or type of answers that you get. Although you might want to point out in any such question, explicitly, that you already did do some research but you did not find anything that actually answered the question. That might stop such answers.
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
Member 14968771 wrote: folks who continually reply with "RTFM" are immune to any suggestions / request to stop such behavior
That may be because that is the best answer. It is up to you to demonstrate that you have actually read what was recommended. The above question and its predecessor are two cases in point, where the answer was simply to read the documentation.
|
|
|
|
|
To add to Richard's comments about the manual. Very often the manual, or the resource suggested (e.g. cppreference.com) has a clearer and more accurate description of what's going on than the respondent could give "from scratch", as it were. If you've actually read the manual and/or consulted the suggested resource and don't understand the description given, you might be a bit more explicit about that. Which question would you be more likely to respond to?
I have a problem with widgets. Don't tell me to RTFM. I need an answer!
or:
I'm looking at the manual for widgets and it says blah. I don't understand the part about bippity-bah, and my google-fu has failed me. Does bippty-bah mean that a widget needs to be frobincated, or does it do that when it's constructed?
Keep Calm and Carry On
|
|
|
|
|
Someone had to RTFM ... all your rant telegraphs is that you're above it and expect someone else to give you the Cole's Notes version. Your attitude makes anyone that actually knows anything not bother because they're not interest in your (negative) responses.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Gerry Schmitz wrote: our attitude makes anyone that actually knows anything not bother
Correction. It makes some of them not bother.
|
|
|
|
|
Member 14968771 wrote: are immune to any suggestions / request to stop such behavior ,
Except I said nothing about that.
Repeating what I said again, and what others said, is that you should point out what you already did (what part of the documentation you read) as part of your original post.
|
|
|
|
|
I totally understand you must be frustrated but look at it from the perspective of someone new seeing your post. Can't say I'm thrilled to spend time looking into your issue given the tone. And you may be 100% correct. I don't know. All we can see is someone was told to read a manual and they're upset. This same person couldn't even be bothered with filling out a name for their account.
Wish you the best buddy. It can be frustrating. Just hope you see it from our perspective.
Jeremy Falcon
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
Member 14968771 wrote: you and everybody else have a choice to ignore it and you are not my mother to criticize my "tone".
Ok cool. You're a child and you'll never get help from me in the future. Enjoy your tantrum.
Jeremy Falcon
|
|
|
|
|
So we're going way back in time here. Windows Embedded Compact 7 and maybe, just maybe one of the old timers have seen this. Searches via google have proved fruitless, as I think MS siloed all their data into their own websites. I cannot even find info there - it's all archived.
I support a WEC7 application. The OEM's old panel OS works reasonably well, but they had to change the hardware. As a result, they need to rebuild the OS image according to the new hardware. They're eating the learning curve, so to speak - it's a completely new team.
Setting aside random exceptions I'm working through, I keep getting this error in debug: "ERROR!!! calling xxx_GetProcessIndexFromID". Searching all of the mfc code supplied with the SDKs yields nothing. At first, I thought it was an ActiveX control thing (yeah, we're going that far back), but I've created a simple default dialog with a standard mfc pushbutton - and I get 21 of these errors.
Ever seen this?
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
i've been working w/ C++ includes lately . whilst examining those utilized in llvm i examined several h header files and found they are not templated and are not merely a declaration but a definition containing code and to my surprise are included in several cpp source files . closer examination revealed they define classes only which i suppose is okeedokee to include in multiple cpp files however does this not result in code bloat as each source must now generate the binary for each class's implementation . in my own work i insist placing the implementation of any non-templated class in it's own cpp source file and let the linker sort it out. i assumed this was sine qua non . is there something i do not understand as the writers of llvm are of course much more knowledgeable/experienced/clever/intelligent than myself . thank you kindly
|
|
|
|
|
Lately, it seems to be a move toward header-only libraries. Most probably, this is a reaction to Dependency hell (I'm a survivor of "DLL hell"). As each project has more and more dependencies, it becomes more difficult to make sure binaries are built properly and consistently and the easiest way out is to put everything in header files as inline functions and let compiler deal with it. This makes horrendous compile times and is clearly not a scalable solution, but for the time being, that's the way the cookie crumbles.
Mircea
|
|
|
|
|
i do not understand how placing the inner workings of each classes or function in the header w/o separating the two would make things easier . just the opposite has been my experience as then more possibly external identifiers are exposed which is why in my work i place as stated non-templated definitions in cpp source . templated classes and functions are separated into declaring h files and implementing impl.h files . each cpp source first includes all the declaring h files templated or not in the proper order to obtain a clean compile . below these are all the impl.h files in any order . one of my current projects is to automate the elimination of unneeded includes . the first prototype which i got working last night resulted in a project build time being reduced from 2m to 10s .
|
|
|
|
|
BernardIE5317 wrote: i do not understand how placing the inner workings of each classes or function in the header w/o separating the two would make things easier
You know those pesky defines that you have in a header file? Imagine you have a library built with
#define OPTION_A 1
#define OPTION_B 0
but your coworker needs the same library built with different options:
#define OPTION_A 0
#define OPtION_B 1
Now you have two different libraries lib_opt10.lib and lib_opt01.lib.
Another project cannot be switched from Visual Studio 2019 to Visual Studio 2022. So now you have lib_opt01_19.lib, lib_opt10_19.lib, lib_opt01_22.lib and lib_opt10_22.lib. And so on and so forth (debug, release, x86, x64, arm, etc.). Congratulations for graduating from "DLL hell" and welcome to the new and improved "dependency hell".
Now if you have everything in the header file, all of a sudden there are no more libraries to manage and the only "small" side-effect is that you drink humongous amounts of coffee while waiting for your project to build. 
Mircea
|
|
|
|
|
thank you for kindly explaining the benefit of header only libraries . i must conclude programmers other than myself know how to define their classes w/ no external dependencies so order of declaration is not important which for me has proven a nightmare but one which i have finally overcome to my satisfaction - Kind Regards
|
|
|
|
|
BernardIE5317 wrote: whilst examining those utilized in llvm i examined several h header files and found they are not templated and are not merely a declaration but a definition containing code
It would of course depend on what they were exactly doing.
Been many years but at least way back when a 'template' ended up creating its own source for each usage. Probably necessary because it was not up to the compiler to figure out where overlaps might cause problems.
But excluding actual templates then no I am not a fan of putting a lot of code in header files.
BernardIE5317 wrote: much more knowledgeable/experienced/clever/intelligent than myself
Perhaps...Or they just have a high opinion of their own opinion.
|
|
|
|
|
A C# program is compiled with a compiler written in c++
A C++ program is compiled with a compiler written in assembly
An assembly program is compiled with a compiler written with machine instructions
Is that roughly how it works?
How does programming with machine instructions take place?
Let’s say I have the ASM MOV command, translated to machine instructions that’s probably one or two numbers. One telling the processor it’s an operation rather than a register or memory address and the other: which type of operation exactly it is. I’m making up stuff for how thing could work.
To get the above functioning on all processors a standard should be required where the numbers/machine instructions for MOV are recognized everywhere. I mean it should work like a hardware resource with the same ID present on old and new processors.
|
|
|
|
|
Calin Negru wrote: A C# program is compiled with a compiler written in c++
A C++ program is compiled with a compiler written in assembly
An assembly program is compiled with a compiler written with machine instructions
Is that roughly how it works?
Not exactly. It isn't a hierarchy where each language is translated in a lower level language. Let's put aside the C# for the moment because it isn't not exactly compiled (I'll explain in a bit). For the other languages the compiler is a machine language program (the processor cannot execute anything else) that translates the source code directly into machine language. In general you don't care in what language the compiler was written. These days it's rare to have an assembler or compiler written in assembly language. Most/all of them are written in C, C++ or other high level languages.
C# is a bit different because the compiler translates the source program into code for a virtual machine. This is called IL (intermediate language). When the program gets executed, the parts that need to be executed are translated into machine code. This is called Just-In-Time (JIT) compiling.
Edit: I left out a lot of details and exceptions. For instance the first C++ "compiler" was actually a preprocessor that translated C++ to plain C. This is a very rough sketch.
Mircea
|
|
|
|
|
Calin Negru wrote: A C# program is compiled with a compiler written in c++
A C++ program is compiled with a compiler written in assembly
An assembly program is compiled with a compiler written with machine instructions
Is that roughly how it works?
Nope, that's not how it works. For example, the Roslyn compiler platform for .NET is written in C#. The very first C# compiler was probably written in C/C++, but not subsequent versions.
A MOV instruction is not the same size on all platforms. For example, a MOV instruction, with operands, on an 8-bit CPU is not the same size as it is on 64-bit CPU's. What the op-code value is determined by comes down to available addressing modes for the instruction, available registers and their width, instruction decode logic and hardware in the CPU, data bus width, address bus width, and a sprinkle of arbitrary. Since there are vast differences in CPU design, the hardware makes it impossible to have the same representation across all CPU's.
Think about it. On a 64-bit CPU, how are you going to have a "MOV r, imm" (MOVe immediate to register) be represented and work exactly the same on an 8-bit CPU when it doesn't have registers that can hold a 64-bit integer?
There's far more to this than what I've posted, but this scratches the surface of why that idea will never work.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
