|
Got caught by "bluez" library...and I will leave it alone...
Apparently "hci_devba" does not "return" device address and crashes when "dev_id" is passed to it.
When "socket" is build using
sock = hci_open_dev( dev_id );
it makes little sense ( to me) to pass "socket" to
hci_devba
BUT at least it does not crash...
<pre> bdaddr_t *bdaddr_1={0};
result = hci_devba(sock, bdaddr_1);
if(result == 0)
{
text = "SUCCESs local device address ";
//CONVERT char to string
ba2str(bdaddr_1, addr);
text = addr;
}
else
{
text = "FAILED to get local device address (socket) ";
}
qDebug()<< text;
PS
I do not get why your definition ) of
hci_devba and mine do not match.
|
|
|
|
|
My "definition" of hci_devba (e.g. hci_devba()) was only meant to convey that the "object" referred to was a "function", and not meant to be a full "prototype" for same.
Salvatore Terress wrote: it makes little sense ( to me) to pass "socket" to
I can only assume that's the requirement of the function, as written by its author. It's no more mysterious than requiring a file descriptor when calling read() or write() (n.b. those are just indications that read() and write() are functions, and not some other object type ... )
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
I have verified that the first parameter is indeed "dev_id" , unfortunately "bluez" does not brother to farther identify it . I "assume" it is "file descriptor"...
Since I cannot identify what causes the run to crash I am going to cheat, for now , and use "hcitool dev" to identify the local Bluetooth device.
I may get ambitious and find the source for "hcitool" and verify what somebody else coded to identify local device , and its address...
cheers
|
|
|
|
|
So, I'm lifting a VC6++ code base to VS2022. It's tedious. Lot's of landmine opportunities, and to say VS2022 is more particular is an understatement... but this code snippet has me mystified - here is the beginning of my original code and it throws a "Warning C6011" possible NULL pointer. Okay, so I see that.
void CInfoBar::SetText(LPCTSTR lpszNew)
{
ASSERT(lpszNew && AfxIsValidString(lpszNew));
if (*lpszNew == _T('#'))
{
TCHAR szNum[8];
INT nCount = 0;
.
.
.
per the help page, it encourages me to check the pointer passed before using it. So I changed the code to below (wrapped it in an if statement.
if (NULL != lpszNew)
{
ASSERT(lpszNew && AfxIsValidString(lpszNew));
if (*lpszNew == _T('#'))
{
TCHAR szNum[8];
INT nCount = 0;
.
.
.
It still throws the warning. I only have a couple of hundred of these things in code the original developer lifted from Microsoft 20 years ago, so... 
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.
|
|
|
|
|
oh ffs. In a small spot of inspiration, I changed my if statement from:
"
if (NULL != lpszNew)
{
to
if (lpszNew != NULL)
{
and the warning goes away. The first form is a time honored coding tradition to prevent typos in conditionals. You obviously cannot assign a value to NULL, so you catch it when you mistype the conditional.
Fine, I'm moving on. In about 6 months, I'm going to be fishing.
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.
|
|
|
|
|
It's nice to know that even well-seasoned developers like you can have these kinds of moments.
I thought I was alone.  
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
charlieg wrote: The first form is a time honored coding tradition to prevent typos in conditionals.
I wonder if anyone ever has remembered to write the conditional backwards, yet used '=' rather than '=='. My impression is that those who turns the condition around never mixes up assignment and equality operators.
I prefer the natural way of writing conditionals, emphasizing readability over dogmas. (I never say 'if 1979 is the vintage', but 'if the vintage is 1979', or 'if green is the car' but 'if the car is green'.)
And, I can't remember as far back as to when the C compiler did not give a warning at 'if (lpszNew != NULL)', something like 'Possibly unintended assignment'.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
trønderen wrote: those who turns the condition around never mixes up assignment and equality operators.
Well, then the backwards writing of the conditional served its purpose, right? If it makes you give extra attention to the code, then that's a good thing.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
At the cost of reduced readability. No, I prefer more readable code.
And I trust that the compiler will warn me about 'Possibly unintended assignment' - as it does, maybe once every 2-3 years.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
trønderen wrote: I wonder if anyone ever has remembered to write the conditional backwards, yet used '=' rather than '=='.
Probably not enough to agonize over it.
trønderen wrote: I prefer the natural way of writing conditionals
I do too. Every time I see the other form my brain tends to do a little twist as I try to figure it out.
And of course these days if one is really concerned then add a method 'IsNull()' and use that. That makes it really obvious.
|
|
|
|
|
trønderen wrote: I never say 'if 1979 is the vintage'
... because a Jedi master you are not 
Mircea
|
|
|
|
|
trønderen wrote: I wonder if anyone ever has remembered to write the conditional backwards, yet used '=' rather than '=='. My impression is that those who turns the condition around never mixes up assignment and equality operators.
Right. However I sometimes make a typo.
Quote: I prefer the natural way of writing conditionals,emphasizing readability over dogmas
Me too. Luckily, modern compilers produce a warning.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
#pragma wanring (disable: 6011)
If you know your code is working, you can dispense with the VS silliness.
Mircea
|
|
|
|
|
As the above poster said, I'm a well seasoned developer inheriting a code base that no one has looked at in 20 years. Since I'm not retired or dead yet...
point taken on warnings, but I have been burned too many times by other developers turning off warnings. I take the phrase "Here be dragons..." seriously.
Still I'm amazed that the MS compiler would distinguish between either version of the source.
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.
|
|
|
|
|
charlieg wrote: I take the phrase "Here be dragons..." seriously.
And so you should. Seems the author of the code in question also took it seriously:
void CInfoBar::SetText(LPCTSTR lpszNew)
{
ASSERT(lpszNew && AfxIsValidString(lpszNew));In this case assert seems the proper way to handle a failing precondition: the function cannot work with a NULL pointer. Fullstop!
In the new variant something has changed:
if (NULL != lpszNew)
{
ASSERT(lpszNew && AfxIsValidString(lpszNew));The ASSERT after the if is clearly not needed (or it could be simplified to keep just the second condition). Also, more importantly the contract conditions of the function have changed: previously the function said "I cannot deal with NULL values for lpszNew". Now it says "if you pass me a NULL value I'm going to do something about it (possibly an else clause for the if statement or something)".
I'm not saying this is wrong but is something to consider carefully.
PS:
charlieg wrote: Still I'm amazed that the MS compiler would distinguish between either version of the source.
It's the artificial intelligence 
Mircea
|
|
|
|
|
I know my code is correct. But is my code completing all the demands of the question.
Q2: Let A[n] be an array of n distinct integers. If i < j and A[i] > A[j], then the pair (i, j)
is called an inversion of A. Write a C/C++ program that determines the number of
inversions in any permutation on n elements in O(n lg n) worst-case time.
(Hint: Modify merge sort)
Example: A = {4, 1, 3, 2} output is 4
#include<stdio.h>
int total_inversions(int arr[], int n, int count);
int main(){
int arr[] = {4, 1, 3, 2};
int n = sizeof(arr) / sizeof(arr[0]);
int count = 0;
count = total_inversions(arr, n , count);
printf("%d", count);
return 0;
}
int total_inversions(int arr[], int n, int count){
for(int i = 0; i < n-1; i++){
for(int j = i+1; j < n; j++){
if (arr[i] > arr[j]){
count++;
}
}
}
return count;
}
|
|
|
|
|
You're going to have to ask your teacher that question.
|
|
|
|
|
Aryan Gupta 2024 wrote: I know my code is correct. But is my code completing all the demands of the question.
Technically, if it's not "completing all the demands of the question", then it's not "correct". 
For example, this random number generator code[^] is "correct" in the sense that it compiles and works. But it's not "correct" in the sense of fulfilling the requirements of an RNG function.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
'Your' random generator code is simply fantastic!
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I have a cloned "wrapper'
header file containing other headers.
The compiler fails to find one of them.
But file manager has no problem opening it.
I checked the contents of the file and it looks similar to
other headers.
\
<pre>#ifndef DBUS_H
#define DBUS_H
#define DBUS_INSIDE_DBUS_H 1
#include <dbus/dbus-arch-deps.h>
#include <dbus/dbus-address.h>
#include <dbus/dbus-bus.h>
#include <dbus/dbus-connection.h>
#include <dbus/dbus-errors.h>
#include <dbus/dbus-macros.h>
#include <dbus/dbus-message.h>
#include <dbus/dbus-misc.h>
#include <dbus/dbus-pending-call.h>
#include <dbus/dbus-protocol.h>
#include <dbus/dbus-server.h>
#include <dbus/dbus-shared.h>
#include <dbus/dbus-signature.h>
compiler l,fails to "find" this file ONLY
#include <dbus/dbus-syntax.h>
#include <dbus/dbus-threads.h>
#include <dbus/dbus-types.h>
#undef DBUS_INSIDE_DBUS_H
here is FULL compiler error
<pre>/usr/include/dbus-1.0/dbus/dbus.h:42: error: 'dbus/dbus-syntax.h' file not found
In file included from BT_CONNECT.cpp:14:
In file included from ../../A_BT_LIBRARY/SimpleBluetooth/SimpleBLE-main/simplebluez/include/simplebluez/Adapter.h:2:
In file included from ./../../A_BT_LIBRARY/SimpleBluetooth/SimpleBLE-main/simpledbus/include/simpledbus/advanced/Proxy.h:3:
In file included from ../../A_BT_LIBRARY/SimpleBluetooth/SimpleBLE-main/simpledbus/include/simpledbus/advanced/Interface.h:3:
In file included from ../../A_BT_LIBRARY/SimpleBluetooth/SimpleBLE-main/simpledbus/include/simpledbus/base/Connection.h:18:
/usr/include/dbus-1.0/dbus/dbus.h:42:10: fatal error: 'dbus/dbus-syntax.h' file not found
#include <dbus/dbus-syntax.h>
^~~~~~~~~~~~~~~~~~~~
I am asking for suggestion(s) how to convince the compiler that the file does exists.
Or what could be wrong with the header source, and way to temporary bypass it so ,I can compile the code.
PS
If it helps I could post the header source here...
|
|
|
|
|
Have you updated the "additional include directories" in the project settings ?
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
That is not (very) logical.
There is series of "includes" from same resource and they are "found".
I can open the file, so what is stopping the compiler to "find" it?
|
|
|
|
|
Where exactly did you find that file?
|
|
|
|
|
Salvatore Terress wrote: #include <dbus/dbus-signature.h>
compiler l,fails to "find" this file ONLY
#include <dbus/dbus-syntax.h>
You can verify this by deleting the first file - then you should get the error for that first file. If you delete it and the error does NOT occur then you are looking at the wrong directory.
But if those two files are in the same directory then the problem is a permission problem.
Probably with the file.
But there are other possible variations such as that the file is actually a link and the link location (hierarchy) has a permission problem.
|
|
|
|
|
!!! pkg-config is your friend !!!
Here's a very simple program that #includes <dbus/dbus.h>
#include <iostream>
#include <dbus/dbus.h>
int main()
{
std::cout << "Hello World\n";
}
Clearly, this does nothing but print "Hello World", but does ask the compiler to #include <dbus/dbus.h>
If we try to compile this naively, the compiler complains that it can't find the requested headers
k5054@localhost:~/tmp $ g++ hello.cpp
hello.cpp:2:10: fatal error: dbus/dbus.h: No such file or directory
2 | #include <dbus/dbus.h>
| ^~~~~~~~~~~~~
compilation terminated.
pkg-config --cflags dbus-1 returns the magic needed to find the headers:
k5054@localhost:~/tmp $ pkg-config --cflags dbus-1
-I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include I've been over this before in answer to your question in QA I think, so I'm not going to repeat it here.
We can use some shell "magic" to tell the compiler to use pkg-config to find the headers:
k5054@localhost:~/tmp$ g++ $(pkg-config --cflags dbus-1) hello.cpp
k5054@localhost:~/tmp$ ./a.out
Hello World
k5054@localhost:~/tmp$ This clearly finds the requested headers and compiles the program successfully. I'd recommend that you try this from the command line exactly as shown here. If you get a successful compile, you need to dig into your IDE and find out how to configure it correctly. If this doesn't work for you, then you've probably ![Elephant | [mastadon]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/elephant.gif) ed up your linux installation, and my best recommendation would be to back anything you want to keep, purge your drives, then reinstall. Before recovering your backed up files, make sure that the above simple program will compile. If not, you need to figure out why.
In over 30 years of working with Unix like systems, the only time I've copied headers under /usr/include, or /usr/local/include to a local project was when I've been trying to do something weird, like trying to compile a new package on an obsolete OS [think trying to get a new version of GCC to compile on RedHat 9 (circa 2003)] or vice versa, e.g getting gcc-2.95 to compile on RedHat Fedora 37. If you find yourself copying includes from the system include directories then IMHO you're making a mistake, and clearly don't understand the build process. That would be true if you find yourself doing this on a Windows system as well.
Don't forget that in order to link to the dbus libraries, you'll need to add pkg-config --libs dbus-1 somewhere so that the link phase knows where to find the needed libraries.
Knowing that the -I flag tells the compiler where to look for include files is simple, basic unix developer course 101 stuff. You shouldn't have any issues understanding that if you've spent more than a couple of weeks doing any Linux or Unix development. The only thing I can think is that you've become over dependent on your IDE and you're not understanding the basic Linux development ecosystem. It might be worth while to break out one or two of the functional parts of your project from the UI/IDE and get them to compile using nothing more sophisticated than a Makefile. If you can get that done, and your IDE keeps breaking the build, you'll probably be better equipped to dig into the IDE settings and figure out what needs to be altered to get it to work.
Good Luck
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
