Getting a compile error with ntddscsi.h - c++

I am having a bit of trouble with the following include:
#include <ntddscsi.h>
When I compile (using NetBean 7.1 & Cygwin C++ compiler), I am told that I need to define "SCSI_PASS_THROUGH" before I can use it... in ntddscsi.h however, it is defined:
typedef struct _SCSI_PASS_THROUGH {
SHORT Length;
CHAR ScsiStatus;
CHAR PathId;
CHAR TargetId;
CHAR Lun;
CHAR CdbLength;
CHAR SenseInfoLength;
CHAR DataIn;
LONG DataTransferLength;
LONG TimeOutValue;
LONG_PTR DataBufferOffset;
LONG SenseInfoOffset;
CHAR Cdb[16];
} SCSI_PASS_THROUGH, *PSCSI_PASS_THROUGH;
Anyone have any idea what on earth is going wrong??

This might happen if you have circular dependencies, or for example LONG_PTR is not defined anywhere.

Related

conflict data type quint16_be from QtEndian with stdint.h

I want to use qint16_be, quint16_be, quint32_be etc. as a data type for big endian
what I am trying is something like this
#include <QtEndian>
typedef quint16_be uint16_t;
And I am getting error
C:/Qt/5.15.2/mingw81_64/include/QtCore/qendian.h:429:28: error: conflicting declaration 'typedef QBEInteger<short int> qint16_be'
typedef QBEInteger<qint16> qint16_be;
C:/Qt/Tools/mingw810_64/x86_64-w64-mingw32/include/stdint.h:38:25: note: previous declaration as 'typedef short unsigned int qint16_be'
typedef unsigned short qint16_be;
I have not included stdint.h in my project.
Any idea how would I resolve it
Here we go: an MCVE for qToBigEndian():
#include <QtCore>
int main()
{
const uint16_t sample = 0x0201;
QByteArray data((const char*)&sample, sizeof sample);
qDebug() << data;
const uint16_t sampleBE = qToBigEndian(sample);
QByteArray dataBE((const char*)&sampleBE, sizeof sampleBE);
qDebug() << dataBE;
}
Output:
"\x01\x02"
"\x02\x01"
I ran this sample in VS2019 on my Intel laptop which has little-endian architecture.
Respectively, the byte order was changed due to the call of qToBigEndian().
The conversion to QByteArray was a quick hack.
Nevertheless, conversion of const uint16_t* to const char* is allowed (with the intention to get access to the byte representation of something).
memcpy() is another permitted way to achieve this.

Using function declared in C++ dll and its VB declarations

There is a .dll and .lib file for the evaluation board AD5501 after installing its drivers. It contains the functions to use to connect to the board and send instructions to it.
A quick search in analog's website (https://ez.analog.com/thread/11121) revealed a document that contains the commands in the above mentioned DLL file. And it is mentioned that the DLL is written in C++. At the end of the page there is a pdf containing VB6 function declarations of the DLL.
I have no knowledge of VB6 but the fact that the DLL has been written in C++ led me to assume that I should be able to access the function in the DLL or LIB file if i know the function prototype in a C++ program. Is this a correct assumption?
And the website has description of the function prototype. So i made a test C++ program as given below :
#include <iostream>
using namespace std;
unsigned int Search_For_Boards (unsigned int VID, unsigned int PID, unsigned int *Num_boards, char *PartPath[]);
int Connect(unsigned int VID, unsigned int PID, char PartPath, unsigned int *Handle);
int Download_Firmware(unsigned int Handle, char pcFilePath[]);
int Vendor_Request(unsigned int Handle, unsigned char Request, unsigned short Value, unsigned short Index, unsigned char Direction, unsigned short DataLength, unsigned char *Buffer[]);
int Disconnect (unsigned int Handle);
int main(){
char *partpath[2];
unsigned int *num;
unsigned int vid = 1110;
unsigned int pid = 45617;
unsigned int error = Search_For_Boards(vid, pid, num, partpath);
cout<<"Hello\n"<<error<<endl;
return 0;
}
And on compiling the code in the following command:
g++ C:\test.cpp -L "C:\Program Files\Analog Devices\USB Drivers" -lADI_CYUSB_USB4
I get the error
Undefined reference to Search_For_Boards(unsigned int, unsigned, int, unsigned int*, char**)
meaning apparently the function prototype is not correct.
Now all this is ASSUMING that i can use the DLL in a C++ program. Seeing the document for VB6 function declaration made me thinking if my assumption is wrong. So my 2 questions are :
1) Is my assumption correct?
2) If the assumption is correct, What is the blunder i am doing here? I feel like I linked the library properly and to my best declared the prototype according to what is described.

Redefinition of type in different libraries

I get byte redefinition error when I try to compile my application. One is defined in Crypto++ library and the other one in rpcdnr.h of Windows Kit. I tried many things but none worked. Any idea to solve the problem is appreciated.
typedef unsigned char byte;
Thanks
P.S. I'm using Qt on Windows.
Namespaces were created for this reason so to avoid interference between identifiers define them under a namspace:
namespace crypto{
typedef unsigned char byte;
};
namespace rpcndr{
typedef unsigned char byte;
};
int main(){
crypto::byte bValue = 7;
rpcndr::byte bvalue2 = 10;
ret
}

Char Followed by a char is illegal (qglobal.h)

I searched this forum already and found a same question but it didn't solve and not even gave any clue in solving my problem. I am doing one project in which i am using Templates.
Firstly i used C++ map like this
typedef map<int ,cal_point*> p_mMap2D;
and it worked perfectly. Then i tried to make a GUI using Qt, but when i used "QMap", it gave an error that
typedef QMap<int ,cal_point*> p_mMap2D;
Error 25 error C2632: 'char' followed by 'char' is illegal C:\Qt
\4.7.4\include\QtCore\qglobal.h 897
Then i tried to use only map as i used before but still it is giving error. I searched net but didn't get any clue related to it. If i don't use Qt then its working perfectly.
Code from qtglobal.h
QT_BEGIN_INCLUDE_NAMESPACE
typedef unsigned char uchar;
typedef unsigned short ushort;
typedef unsigned int uint;
typedef unsigned long ulong;
QT_END_INCLUDE_NAMESPACE
Inside /src/corelib/global/qglobal.h Qt 4.8.5 contains following strings:
# define QT_BEGIN_INCLUDE_NAMESPACE }
# define QT_END_INCLUDE_NAMESPACE namespace QT_NAMESPACE {
And when preprocessor expands this macro with for example QT_NAMESPACE=qt result will be:
}
typedef unsigned char uchar;
typedef unsigned short ushort;
typedef unsigned int uint;
typedef unsigned long ulong;
namespace qt {
Looks like an error of definition QT_BEGIN_INCLUDE_NAMESPACE and QT_END_INCLUDE_NAMESPACE.
It is hard to tell because you have not included the definition of cal_point*, but the problem is where it is defined or somewhere among those lines. Check them. It might be in an external file that makes it break, and so on.

C++ link error LNK2005

I am new to C++ programing and I'm trying to make a program that simulates Conway's game of life. I'm almost done but when I made each function have it's own file I keep on getting this linker error.
1>algorithm_change.obj : error LNK2005: "unsigned short height" (?height##3GA) already defined in algorithm.obj
My code is at https://github.com/rupertsteel/Life/tree/master/Life
Without looking at the code, do you have a global unsigned short height; in any header file? If yes, replace that with extern unsigned short height; and put a unsigned short height; in a source file that includes the specific header.
A few comments:
1) array_length in life.h needs to be externed
2) All the externed variables (width, height, ticks, count_array, change_array, error_check, algorithm_length, array_length) need to be defined somewhere.
In your code you've basically told the compiler that those variables exist somewhere but haven't actually placed them in existence anywhere. In one of your .cpp files in the global scope you need to put:
unsigned short int width;
unsigned short int height;
unsigned long int ticks;
unsigned short int count_array[10923][10923];
bool change_array[10923][10923];
int error_check;
unsigned long int algorithm_length;
unsigned long int array_length;
Which is exactly the same as what you have in life.h, except without the extern keyword. This will actually create the variables, as opposed to now where they have no concrete implementation.
If you make the changes I suggest your code will compile (tested using gcc). That being said, the actual error you're seeing doesn't make sense.