Why "so many " - include , forward declaration...
-
This .cpp has me confused. It has @includes some QT specific
QT_FORWARD_DECLARE_CLASS
and plain forward declarations Seems redundant... Why so many "prerequisites" or whatever the correct term for all this is ?
#define TRACE
#include "ui_chat.h"// add library
#include "../BLUETOOTH_LIBRARY/bluetooth_library.h"
#include #include "QtBluetooth/qbluetoothdevicediscoveryagent.h"
#include "QtBluetooth/qbluetoothdeviceinfo.h"
#include "QtBluetooth/qbluetoothlocaldevice.h"#include QT_FORWARD_DECLARE_CLASS(QBluetoothDeviceDiscoveryAgent)
QT_FORWARD_DECLARE_CLASS(QBluetoothDeviceInfo)
QT_USE_NAMESPACEclass ChatServer;
class ChatClient;//! [declaration]
class Chat : public QDialog
{
Q_OBJECTpublic:
explicit Chat(QWidget *parent = nullptr);
~Chat();MainWindow\_ScanAdapters \*MWSA = new MainWindow\_ScanAdapters(); QString text;
signals:
void sendMessage(const QString &message);private slots:
// FROM BTSCANNER
#ifdef BYPASS
void addDevice(const QBluetoothDeviceInfo&);
void on_power_clicked(bool clicked);
void on_discoverable_clicked(bool clicked);
void displayPairingMenu(const QPoint &pos);
void pairingDone(const QBluetoothAddress&, QBluetoothLocalDevice::Pairing);
#endif
void connectClicked();
void sendClicked();void showMessage(const QString &sender, const QString &message); void clientConnected(const QString &name); void clientDisconnected(const QString &name); void clientDisconnected(); void connected(const QString &name); void reactOnSocketError(const QString &error); void newAdapterSelected(); void on\_connectButton\_clicked();
private:
int adapterFromUserSelection() const;
int currentAdapterIndex = 0;
Ui_Chat *ui;ChatServer \*server; QList clients; QList localAdapters;
public:
QBluetoothDeviceDiscoveryAgent *discoveryAgent;
QBluetoothLocalDevice *localDevice;
// Ui_DeviceDiscovery *ui;QString localName;
};
//! [declaration] -
This .cpp has me confused. It has @includes some QT specific
QT_FORWARD_DECLARE_CLASS
and plain forward declarations Seems redundant... Why so many "prerequisites" or whatever the correct term for all this is ?
#define TRACE
#include "ui_chat.h"// add library
#include "../BLUETOOTH_LIBRARY/bluetooth_library.h"
#include #include "QtBluetooth/qbluetoothdevicediscoveryagent.h"
#include "QtBluetooth/qbluetoothdeviceinfo.h"
#include "QtBluetooth/qbluetoothlocaldevice.h"#include QT_FORWARD_DECLARE_CLASS(QBluetoothDeviceDiscoveryAgent)
QT_FORWARD_DECLARE_CLASS(QBluetoothDeviceInfo)
QT_USE_NAMESPACEclass ChatServer;
class ChatClient;//! [declaration]
class Chat : public QDialog
{
Q_OBJECTpublic:
explicit Chat(QWidget *parent = nullptr);
~Chat();MainWindow\_ScanAdapters \*MWSA = new MainWindow\_ScanAdapters(); QString text;
signals:
void sendMessage(const QString &message);private slots:
// FROM BTSCANNER
#ifdef BYPASS
void addDevice(const QBluetoothDeviceInfo&);
void on_power_clicked(bool clicked);
void on_discoverable_clicked(bool clicked);
void displayPairingMenu(const QPoint &pos);
void pairingDone(const QBluetoothAddress&, QBluetoothLocalDevice::Pairing);
#endif
void connectClicked();
void sendClicked();void showMessage(const QString &sender, const QString &message); void clientConnected(const QString &name); void clientDisconnected(const QString &name); void clientDisconnected(); void connected(const QString &name); void reactOnSocketError(const QString &error); void newAdapterSelected(); void on\_connectButton\_clicked();
private:
int adapterFromUserSelection() const;
int currentAdapterIndex = 0;
Ui_Chat *ui;ChatServer \*server; QList clients; QList localAdapters;
public:
QBluetoothDeviceDiscoveryAgent *discoveryAgent;
QBluetoothLocalDevice *localDevice;
// Ui_DeviceDiscovery *ui;QString localName;
};
//! [declaration] -
This .cpp has me confused. It has @includes some QT specific
QT_FORWARD_DECLARE_CLASS
and plain forward declarations Seems redundant... Why so many "prerequisites" or whatever the correct term for all this is ?
#define TRACE
#include "ui_chat.h"// add library
#include "../BLUETOOTH_LIBRARY/bluetooth_library.h"
#include #include "QtBluetooth/qbluetoothdevicediscoveryagent.h"
#include "QtBluetooth/qbluetoothdeviceinfo.h"
#include "QtBluetooth/qbluetoothlocaldevice.h"#include QT_FORWARD_DECLARE_CLASS(QBluetoothDeviceDiscoveryAgent)
QT_FORWARD_DECLARE_CLASS(QBluetoothDeviceInfo)
QT_USE_NAMESPACEclass ChatServer;
class ChatClient;//! [declaration]
class Chat : public QDialog
{
Q_OBJECTpublic:
explicit Chat(QWidget *parent = nullptr);
~Chat();MainWindow\_ScanAdapters \*MWSA = new MainWindow\_ScanAdapters(); QString text;
signals:
void sendMessage(const QString &message);private slots:
// FROM BTSCANNER
#ifdef BYPASS
void addDevice(const QBluetoothDeviceInfo&);
void on_power_clicked(bool clicked);
void on_discoverable_clicked(bool clicked);
void displayPairingMenu(const QPoint &pos);
void pairingDone(const QBluetoothAddress&, QBluetoothLocalDevice::Pairing);
#endif
void connectClicked();
void sendClicked();void showMessage(const QString &sender, const QString &message); void clientConnected(const QString &name); void clientDisconnected(const QString &name); void clientDisconnected(); void connected(const QString &name); void reactOnSocketError(const QString &error); void newAdapterSelected(); void on\_connectButton\_clicked();
private:
int adapterFromUserSelection() const;
int currentAdapterIndex = 0;
Ui_Chat *ui;ChatServer \*server; QList clients; QList localAdapters;
public:
QBluetoothDeviceDiscoveryAgent *discoveryAgent;
QBluetoothLocalDevice *localDevice;
// Ui_DeviceDiscovery *ui;QString localName;
};
//! [declaration]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
andQBluetoothLocalDevice
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.
-
This .cpp has me confused. It has @includes some QT specific
QT_FORWARD_DECLARE_CLASS
and plain forward declarations Seems redundant... Why so many "prerequisites" or whatever the correct term for all this is ?
#define TRACE
#include "ui_chat.h"// add library
#include "../BLUETOOTH_LIBRARY/bluetooth_library.h"
#include #include "QtBluetooth/qbluetoothdevicediscoveryagent.h"
#include "QtBluetooth/qbluetoothdeviceinfo.h"
#include "QtBluetooth/qbluetoothlocaldevice.h"#include QT_FORWARD_DECLARE_CLASS(QBluetoothDeviceDiscoveryAgent)
QT_FORWARD_DECLARE_CLASS(QBluetoothDeviceInfo)
QT_USE_NAMESPACEclass ChatServer;
class ChatClient;//! [declaration]
class Chat : public QDialog
{
Q_OBJECTpublic:
explicit Chat(QWidget *parent = nullptr);
~Chat();MainWindow\_ScanAdapters \*MWSA = new MainWindow\_ScanAdapters(); QString text;
signals:
void sendMessage(const QString &message);private slots:
// FROM BTSCANNER
#ifdef BYPASS
void addDevice(const QBluetoothDeviceInfo&);
void on_power_clicked(bool clicked);
void on_discoverable_clicked(bool clicked);
void displayPairingMenu(const QPoint &pos);
void pairingDone(const QBluetoothAddress&, QBluetoothLocalDevice::Pairing);
#endif
void connectClicked();
void sendClicked();void showMessage(const QString &sender, const QString &message); void clientConnected(const QString &name); void clientDisconnected(const QString &name); void clientDisconnected(); void connected(const QString &name); void reactOnSocketError(const QString &error); void newAdapterSelected(); void on\_connectButton\_clicked();
private:
int adapterFromUserSelection() const;
int currentAdapterIndex = 0;
Ui_Chat *ui;ChatServer \*server; QList clients; QList localAdapters;
public:
QBluetoothDeviceDiscoveryAgent *discoveryAgent;
QBluetoothLocalDevice *localDevice;
// Ui_DeviceDiscovery *ui;QString localName;
};
//! [declaration]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.
-
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.
a subjective thing
Not sure I agree, even with the comment "things grow in complexity ".... The basic C / C++ is header ( #include ) source and that should be all ( objective) what is needed. No place for subjective "opinions" here. I am really not that crazy about "forward declaration" - seems redundant. I am actually starting to use #pragma once much "cleaner" than #ifndef #define ..... #endif But in that case you are right - it is subjective....
-
a subjective thing
Not sure I agree, even with the comment "things grow in complexity ".... The basic C / C++ is header ( #include ) source and that should be all ( objective) what is needed. No place for subjective "opinions" here. I am really not that crazy about "forward declaration" - seems redundant. I am actually starting to use #pragma once much "cleaner" than #ifndef #define ..... #endif But in that case you are right - it is subjective....
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.)