Latest update: the bug is gone after I run cmd console, instead of the new Terminal console. Case closed. Thanks everybody for checking and testing.
I found a cout bug with Visual C++ 2022 on Windows 11. VC++ 2019 does not have this bug. When I try to debug, the problem goes away. I have produced a small repo that reproduces the issue. Please help me check so that I can report this bug to Microsoft. Thanks.
Mine also has a tabbed interface, so I have three tabs: cmd, PowerShell and Linux under WSL. It seems just as fast as anything else. I can only assume there is another interface that is the default in the 11 version. Unfortunately (or maybe not) my PC does not support Windows 11.
I am trying to play an mp3 file from a WinAPI/C++ application. I'm using 32-bit MinGW on Windows 10.
I found an example program which uses the MCI (winmm) interface to play the file; I found an example command-line program which implements this using mciSendString() calls...
I had some problems handling paths to the mp3 file, and *thought* I had fixed it by converting the paths to 8.3 short format... the command-line program plays the files just fine, but when I import exactly the same code into my WinAPI dialog-box application, although the MCI functions all return success, no sound plays...
Does anyone have any idea what is missing here?? Or does this library just not work from a Windows dialog app?
Well, all of the Windows-supported libraries present problems, especially if one is building using MinGW rather than Visual C++. Generally, they cannot be built at all without a massive amount of hacking the code bases to make them MinGW-compatible. No DirectShow apps will build, neither will the more-recent MS audio interface (don't recall the name at the moment).
However, I found a freeware library called zplay, which is easy to build, open source, and nice, compact code... it also has the ability to play other formats, such as flac... so I'll just go with that...
Here is definition of function taken from an example:
void SettingsDialog::pairingDone(QBluetoothAddress ,QBluetoothLocalDevice::Pairing)
I need to verify the actual address and having a tough time understanding this "syntax".
I do understand that the function parameters are "objects" but when I RTFM it really does not explain the syntax. All I get is "passing by value or by reference" - so what are the parameters actually passed to "pairingDone" ?
please show me how to get the address - post actual C code
point me to good resource to learn something about the syntax
recommend a C++ book so I can retire my "K&R" book
I can do without opinions and innuendos insults or RTFM replies.
I lost my copy of K&R a long time ago. My version was pre-ANSI, which meant that there was no void, and no function prototypes, among other things, and function definitions looked like
/* function body */
I'd be willing to bet even K&R that old explained the difference between "pass by value" and "pass by reference" i.e the difference between making a copy of an object and passing that to the function (pass by value, possibly expensive), and passing a pointer to a an object (pass by reference, usually cheap. But at least in C may lead to off-by-one and other assorted bugs. NB. An array is always passed by reference.). In C++ we have references. [Reference declaration - cppreference.com]
So what is "QBluetoothAddress" - value or reference?
Who knows? It could be a reference, a pointer or an object. e.g.
using mc = myClass &; // mc is a reference to class myClass
using mc = myClass *; // mc is a reference to class myClass
typedef myClass mc; // mc is a myClass object
// or even
using mc = myClass && // mc is a rvalue reference
You need to check the documentation for whatever SettingsDialog::pairingDone() is to see. I tried, but googling for SettingsDialog::pairingDone did not return anything useful. Nor did looking at QBluetooth (or something similar).
Keep Calm and Carry On
Last Visit: 31-Dec-99 18:00 Last Update: 2-Oct-23 19:24