|
I would assume that the forward declarations are required because you have:
public:
QBluetoothDeviceDiscoveryAgent *discoveryAgent;
QBluetoothLocalDevice *localDevice;
in your class. And these two pointers refer to the QBluetoothDeviceDiscoveryAgent and QBluetoothLocalDevice classes. However, you also have the include files:
#include "QtBluetooth/qbluetoothdevicediscoveryagent.h" // ?
#include "QtBluetooth/qbluetoothdeviceinfo.h"
#include "QtBluetooth/qbluetoothlocaldevice.h" // ?
before your class definition, where one would assume that the aforementioned are actually declared. So maybe they are not really needed.
|
|
|
|
|
Member 14968771 wrote: Why so many
That is usually a subjective thing. In general it should not be required.
But what happens, over time, is that as complexity grows so does the definitions.
And there are only two choices
1. Include the actual source of the definition
2. Include a short cut.
The first solution, in general requires that the compiler reread (parse, tokenize, etc) the full included source files every time and then likely the includes for those as well and that can continue for a while. That takes time. Compilers, now, tend to attempt to optimize that by using various caching strategies. But, at least in the past, some of those were less than reliable.
So people might want to avoid that by using short cuts. Thus the compiler can do far less work. And that is what that is.
Ideally of course the design should minimize all of that. Even at times to the point of perhaps reducing clarity. One trick that I used to use was to create two includes. One that was only for public consumption and the other for internal consumption (for example internal structs) and then the public visible items used something like a 'void *' and then I used casts for the internals. That did allow the external include to be smaller it size but it was a solution that only worked in some cases.
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
Member 14968771 wrote: even with the comment "things grow in complexity "....
Have you worked with legacy systems? Systems that have been in continued use for 20 years with ongoing changes throughout that time period?
And for a product that has started with a small customer base but which has grown to many?
Google for example...
"span a whopping 2 billion lines of code that stretch across 1 billion files and require 86 terabytes of storage,"
Don't you suppose there are some less than ideal code in that?
Or if you prefer GCC is roughly 15 million lines of code.
Member 14968771 wrote: and that should be all ( objective) what is needed
That is of course specifically subjective.
And you will not find any non-trivial application code base in C++ where the vast majority of files follow that model. Most will have many include files. Sometimes there are even include files that are nothing but a container for other include files (and that can recurse.)
|
|
|
|
|
Hi
I resolved all the initial heap errors still receiving some but I think I know the cause the Assembler listing I am streaming is 153 pages with 54 lines to page and about 130 characters across so that's a little bit over a meg large, Can I use LimitText to give myself the space?
|
|
|
|
|
|
|
I am working at blitting to back frame buffers a changing variety of bitmaps to create animations. When completed, that would be sent to the screen. I want to do this with minimum processing and minimum RAM.
Svetoslav Chekanov, on another page Fast 2:1 Image Shrink (Scale Down)[^] said,
Quote: Device dependent format is blitted faster to the screen.
I did not know that. I have been using Device Independent because it seemed to be easier to work with. I will now consider this Dependent vs Independent.
I found a discussion with some interesting observations. C++ Windows API: Is there any alternative of the SetDIBits for device-dependent Bitmap?[^] In that I found: Quote: The difference is insignificant, more than swamped by the time it takes to
copy the bitmap to the frame buffer.
May I have some feedback on this "is insignificant" comment (from the Windows API link) if it is correct or not?
I also read on that page, Quote: In a DIB, each scanline is always a multiple of 4 bytes. In a 24-bit DIB,
that means you will have extra padding bytes unless the width is a multiple
of 4.
I did not know that. I will now have that to consider.
Looking forward to learning more about this.
|
|
|
|
|
|
Since many have been so kind as to help me out i will spell out exactly what I am doing
The Windows Program is a client to Z/os Mainframe program. I download a file (variable blocked) the output of a MainFrame Assembler program listing. This on the mainframe is called a sysadata file.
The Windows exe calls the dll to basically convert the binary representation of the listing into readable format
The routine I having the exception in is a subroutine called by another routine in the DLL The file i/o is done in the DLL.
I think I am going to take out all the storage allocation out of the DLL is just causing me all sorts of problems the structure I'll pass from the exe to the dll will
have the maximum amount of storage I need I do a number of STL objects such as maps in the DLL basically a number of map objects I have already generated them I hoping that when
the exe needs the information from the DLL I dont have issues referencing them
|
|
|
|
|
Quote: The Windows exe calls the dll to basically convert the binary representation of the listing into readable format
A simple workaround would be moving that code inside the executable.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
A little bit of a background I am basically a mainframe assembler language programmer I have worked for software vendor and IBM on their OS after 2000 I started getting layed off all over the place. it was it was suggested to me that I learn something new I started with C then Windows then MFC, along the way I got a Job with the US federal govt the IRS it is my day job Im on the east cost in NY. When It came to renew my IBM MainFrame yearly license and I inquired why the cost was higher than others they told me I have a right to sell the software I develop. I then started to focus my attention on that The z/os as a server and a Windows client
Back to why I didnt make this code part of the .exe. The .DLL would be invoked by multiple user. Every user of the .exe would need to perform this functionality
Again thank you for help I could never have gotten this far without the kindness of people like yourself
|
|
|
|
|
You are welcome.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I don't know the details of your application, but in the PC/Windows world it's rare to have more than one user running on the same machine. Even if you have more than one user, each process (.exe program) has it's own separate memory space. Using a DLL instead of a single program to save memory makes little sense these days. I know some people might disagree with me, but this is a broad brush picture. Anyway it doesn't pay off in terms of complications it adds to your project, doubly so if you are a newcomer to this field.
In short, my recommendation would be to give up on having a DLL and putting everything in a single program. If latter on, when the program is working well, you discover that using a DLL makes sense, you can change it. In the meantime you would have gained more familiarity with the OS/tools/programming language and it would be easier for you to transition.
Just my $0.02
Mircea
|
|
|
|
|
I removed all of the storage allocations out of my DLL and it seemed to worked by tonite I should be able put this piece to rest.
if not i will consider and/or take your advice
thanks
|
|
|
|
|
Hi
I have the following code which I basically take a hex array and convert it to a ascii char * e.g 0X47F0F01A so the array becomes 303770307030316500
I marked off where I get dialogbox message from CRT and I cannt for the life of me figure out why
the memcpy where I mark off the string with a null is 8 bytes into the 70 bytes allocated
char* convertToString(unsigned char* a, int size)
{
int i;
char ch;
char getch(char);
char* t = new char[70];
char* k = t;
char thenullptr = 0x00;
char* s;
if (size == 80)
__debugbreak();
for (i = 0; (i < size && i < 62); i++) {
ch = a[i];
ch = ch >> 4;
ch = ch & 0x0f;
ch = getch(ch);
memcpy(k, &ch, 1);
k++;
ch = a[i];
ch = ch & 0x0f;
ch = getch(ch);
memcpy(k, &ch, 1);
k++;
}
if (i >= 62)
{
s = new char[63];
::memcpy(s, t, 62);
k = s + 62;
::memcpy(k, &thenullptr, 1); <------- call which causes read exception or overwrite
delete t;
return s;
}
::memcpy(k, &thenullptr, 1);
s = new char(strlen(t) + 1);
;
::memcpy(s, t, strlen(t) + 1);
delete t;
return s;
}
char getch(char ch)
{
if (ch <= 0x09)
ch += 48;
else
ch += 55;
return ch;
}
|
|
|
|
|
ForNow wrote:
s = new char[63];
::memcpy(s, t, 62);
k = s + 62;
::memcpy(k, &thenullptr, 1); <------- call which causes read exception or overwrite
why are you doing it so complicated?
Why not just
s = new char[63] {0};
::memcpy(s, t, 62);
and you won't need to copy the terminated 0x00 byte.
Or just set it form the very begin:
s = new char[63];
s[62] = '\0';
::memcpy(s, t, 62);
modified 10-Jan-23 11:17am.
|
|
|
|
|
Ok let me redo it thanks for responding thing is it doesn’t happen the first time the sub gets called only after a number if calls
Thank you again
|
|
|
|
|
That would suggest you probably have a bug elsewhere in you program. Maybe a buffer overflow or an uninitialized variable is writing where it shouldn't. If you haven't already, turn up the warning level on the compiler, and then fix everything it flags. If this still happens, you'll need to dig into your debugger and look into watch points and the like.
Keep Calm and Carry On
|
|
|
|
|
You are using new[], so you must use a matching delete[]:
char* t = new char[70];
delete[] t;
This might not be the cause of the problem you are having, but it will cause problems.
|
|
|
|
|
Just saw that but that is only for C++ as I build this DLL as C
Before thank you
|
|
|
|
|
C doesn't have new/delete at all - you are writing C++
|
|
|
|
|
|
that's is my scenario I pass a hex array pointer to DLL function and allocate the storage there and pass the pointer back to the application I have to read what you sent I have Dr appointment in 15 min but thanks for the info
|
|
|
|
|
You are welcome.
BTW, Good luck with the doctor.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
