[newbie] visibility again

[Soviet_Mario]

I'm getting different errors when compiling and changing the
order of the files.
Now I still have clear enough notion of SCOPE of object, but
I must admit I have none about the sequence of scopes (the
"order" the files are compiled or, maybe, linked).
Is this relevant ?

For a proof I merged the content of four files that
generated errors (type not defined and so) and as a
monolitic file it compiles and links without error, so the
problem is in the order of declarations, but I don't know
well this topic.

If there is sb using QT creator, how is possible to control
this in the IDE ?
Or even better (but I'm not optimistic) : is it possible to
embed in CODE itself directives, pragmas or else, to control
the flow of compilation or linking ?

I tried to resort to include, but it didn't work ...

TY


--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[Sam]

Soviet_Mario writes:

> I'm getting different errors when compiling and changing the order of the
> files.
> Now I still have clear enough notion of SCOPE of object, but I must admit I
> have none about the sequence of scopes (the "order" the files are compiled
> or, maybe, linked).
> Is this relevant ?

The only thing that can be stated for certain here, is that the file
compilation order is always irrelevant.

Nothing further can be stated withut specific, concrete, examples.

> I tried to resort to include, but it didn't work ...

Trying random things, without a clear understanding of what the problem is,
is very unlikely to be very productive.

The first step towards solving a problem is understanding what the actual
problem is. Your entire vague, nebulous description indicates that you don't
seem to understand what the actual problem is, and can't even communicate
it, clearly.

[Soviet_Mario]

Il 01/07/2018 15:21, Sam ha scritto:
> Soviet_Mario writes:
>
>> I'm getting different errors when compiling and changing
>> the order of the files.
>> Now I still have clear enough notion of SCOPE of object,
>> but I must admit I have none about the sequence of scopes
>> (the "order" the files are compiled or, maybe, linked).
>> Is this relevant ?
>
> The only thing that can be stated for certain here, is that
> the file compilation order is always irrelevant.
>
> Nothing further can be stated withut specific, concrete,
> examples.

I had a project (autogenerated) by QT creator, consisting of
two files : one with MAIN app, the other for initing the GUI

Then I added a MY.CPP further file with some generic class
declaration.

Building all I obtained errors like "type class XXX is not
defined".

When I embedded the same code and declarations from MY.CPP
either in Main.CPP or in MainWindow.CPP, the build went
plain without errors.

So I'm trying to understand where to put code and why
splitting it in handy files won't work.
There might be wrong link settings ? I can't find them (I
used to use VStudio, but I'm trying to move to QTcreator and
I'm less than newbie in this IDE).
There might be other aspect in declarations I miss / forgot
(like extern directives ?)


I've a vague memory that extern variables without static had
global scope (with static they were restricted to file
scope). As far as class declaration I've no memory of their
scope and if/how to alter it.

>
>> I tried to resort to include, but it didn't work ...
>
> Trying random things, without a clear understanding of what
> the problem is, is very unlikely to be very productive.

I'm asking in order to understand

>
> The first step towards solving a problem is understanding
> what the actual problem is. Your entire vague, nebulous
> description indicates that you don't seem to understand what
> the actual problem is,

true

> and can't even communicate it, clearly.

a consequence of the former :)

I tried to explain with a generic example ... I dunno if it
will be useful

Ciao

[Paavo Helde]

On 1.07.2018 19:52, Soviet_Mario wrote:
> Il 01/07/2018 15:21, Sam ha scritto:
>> Soviet_Mario writes:
>>
>>> I'm getting different errors when compiling and changing
>>> the order of the files.
>>> Now I still have clear enough notion of SCOPE of object,
>>> but I must admit I have none about the sequence of scopes
>>> (the "order" the files are compiled or, maybe, linked).
>>> Is this relevant ?
>>
>> The only thing that can be stated for certain here, is that
>> the file compilation order is always irrelevant.
>>
>> Nothing further can be stated withut specific, concrete,
>> examples.
>
> I had a project (autogenerated) by QT creator, consisting of
> two files : one with MAIN app, the other for initing the GUI
>
> Then I added a MY.CPP further file with some generic class
> declaration.
>
> Building all I obtained errors like "type class XXX is not
> defined".

First you need to figure out if these were compiler errors or linker
errors as this will narrow the location of the bug (in broad terms, is
the problem in .h or in .cpp files).

In C++, everything used by the code must be first declared, typically in
included header files; if it's not, then you get compiler errors.

The declared things must be also actually defined, typically in cpp
files. For linking the whole program the linker needs to have all used
symbols defined somewhere; if this is not the case, you get linker errors.

Most people in this group can say by a single glance on an error message
if it is coming from the compiler or linker, but of course it never did
occur to you to post an actual error message.

>
> When I embedded the same code and declarations from MY.CPP
> either in Main.CPP or in MainWindow.CPP, the build went
> plain without errors.

Seems like either a namespace problem or that you did not include MY.CPP
in the build properly.

Construct a minimal example demonstrating the problem, post the code and
the actual error messages.

[Soviet_Mario]

Il 01/07/2018 19:45, Paavo Helde ha scritto:
> On 1.07.2018 19:52, Soviet_Mario wrote:
>> Il 01/07/2018 15:21, Sam ha scritto:
>>> Soviet_Mario writes:
>>>
>>>> I'm getting different errors when compiling and changing
>>>> the order of the files.
>>>> Now I still have clear enough notion of SCOPE of object,
>>>> but I must admit I have none about the sequence of scopes
>>>> (the "order" the files are compiled or, maybe, linked).
>>>> Is this relevant ?
>>>
>>> The only thing that can be stated for certain here, is that
>>> the file compilation order is always irrelevant.
>>>
>>> Nothing further can be stated withut specific, concrete,
>>> examples.
>>
>> I had a project (autogenerated) by QT creator, consisting of
>> two files : one with MAIN app, the other for initing the GUI
>>
>> Then I added a MY.CPP further file with some generic class
>> declaration.
>>
>> Building all I obtained errors like "type class XXX is not
>> defined".
>
> First you need to figure out if these were compiler errors
> or linker errors as this will narrow the location of the bug
> (in broad terms, is the problem in .h or in .cpp files).

I'm not sure ... I append the full code (it's not long, and
I'm not sure what is essential and what's not).
Actually, I'm not even sure the code is really wrong and I
don't feel sure to exclude some "mismatch" /
misconfiguration somewhere in the IDE.

>
> In C++, everything used by the code must be first declared,
> typically in included header files; if it's not, then you
> get compiler errors.
>
> The declared things must be also actually defined, typically
> in cpp files. For linking the whole program the linker needs
> to have all used symbols defined somewhere; if this is not
> the case, you get linker errors.
>
> Most people in this group can say by a single glance on an
> error message if it is coming from the compiler or linker,
> but of course it never did occur to you to post an actual
> error message.
>
>>
>> When I embedded the same code and declarations from MY.CPP
>> either in Main.CPP or in MainWindow.CPP, the build went
>> plain without errors.
>
> Seems like either a namespace problem or that you did not
> include MY.CPP in the build properly.
>
> Construct a minimal example demonstrating the problem, post
> the code and the actual error messages.
>

well I'm not able to : I post the code as is :\
If it is too long, no problem, thanks anyway


HEADER mainwindow.h (autogenerated by QT)
#############################################################
#ifndef MAINWINDOW_H
#define MAINWINDOW_H

#include <QMainWindow>

namespace Ui {
class MainWindow;
}

class MainWindow : public QMainWindow
{
Q_OBJECT
public:
explicit MainWindow(QWidget *parent = 0);
~MainWindow();
private slots:
void on_pushButton_clicked(bool checked);
void on_btnGo_clicked(bool checked);
private:
Ui::MainWindow *ui;
};
#endif // MAINWINDOW_H
#############################################################

#############################################################
HEADER disk_scanner_05.H (coded by myself)
#############################################################
#ifndef DISK_SCANNER_05_H
#define DISK_SCANNER_05_H

#include <QCoreApplication>
#include <QtCore>
#include <QDateTime>
#include <QString>
#include <QDir>
#include <QFileInfo>

// {};

//@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

class clsDiskMap;

class clsFileAttributes
{
friend class clsDiskMap;
friend class clsAssocFileNameToAttributes;

public:
static bool ExcludePathFoldersFromComparison;
const char * const DateTimeFormat =
"yyyy_MM_dd___HH_mm_ss";

public:
QDateTime LastModified; // QDateTime::fromTime_t(uint
seconds, const QTimeZone & timeZone)
QDateTime LastAccessed;
quint64 Dimensions;

QString * ptrPathFolder; // dato PESANTE, ma presente
solo come puntatore, lo spazio è consumato altrove


static bool ExcludePathFoldersFromComparisons ();

static bool IncludePathFoldersInComparisons ();

bool operator == (const clsFileAttributes & Arg) const;

bool operator != (const clsFileAttributes & Arg) const;

// friend ESTERNA
bool FzGetFileAttributes (const QString &, const
QString &);

QString To_String (bool IncludeDimensions = true, bool
IncludeLastModified = true, bool IncludeLastAccessed = true,
bool IncludePathFolder = true);
};

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

// bool clsFileAttributes ::
ExcludePathFoldersFromComparison = false;

// bool FzGetFileAttributes (const QString & FolderPath,
const QString & FileName, clsFileAttributes & Attribs);

//@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

class clsAssocFileNameToAttributes
{
friend class clsMappaAssocsFileNamesToTheirAttributes;
friend class clsDiskMap;

private:
const QString * zzFileNameKey;
QList <clsFileAttributes>
zzListaAttributiAndFoldersOfFileName;

public:
clsAssocFileNameToAttributes ();

clsAssocFileNameToAttributes (const QString &
ArgFileNameKey);

const QList <clsFileAttributes> & GetListaAttributiFile ();

int CercaAttributiFile (const clsFileAttributes &
AttributiFileCercati) const;

bool AggiungiNuoviAttributiFile (const
clsFileAttributes & ArgNuoviAttributiFile);

bool EliminaAttributiFile (const clsFileAttributes &
ArgAttributiFile);

const QString & GetFileName () const;

const QString & SetFileName (const QString & NewFileName);

bool operator == (const QString & Op2);
bool operator != (const QString & Op2);

bool operator == (const clsAssocFileNameToAttributes &
Op2);
bool operator != (const clsAssocFileNameToAttributes &
Op2);

QString To_String (bool IncludeDimensions = true, bool
IncludeLastModified = true, bool IncludeLastAccessed = true,
bool IncludePathFolder = true);
};

//@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

class clsMappaAssocsFileNamesToTheirAttributes
{
friend class clsDiskMap;
friend class clsAssocFileNameToAttributes;
private:
QList <clsAssocFileNameToAttributes> zzMappa;

public:
int AggiungiFileNameKeySeManca (const QString &
NewFileNameKey);

bool AggiungiFilesAttributes (const QString & FileName,
const clsFileAttributes & NewFileNameAttribute);

const QList <clsFileAttributes> & GetAttributiFile
(const QString & FileNameKey);

QString To_String (bool IncludeDimensions = true, bool
IncludeLastModified = true, bool IncludeLastAccessed = true,
bool IncludePathFolder = true);
};

//@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

class clsDiskMap
{
private:
QStringList DB_FullPathnamesFoldersTree;
// clsDizionario <QString>
DB_FromUnivocFilenamesToTheirPathFolders; // = QMap
<QString, QStringList> ("", QStringList (""));
clsMappaAssocsFileNamesToTheirAttributes
DB_FromUnivocFilenamesToTheirAttributes; // = QMultiMap
<QString, QList <clsFileAttributes> > ("", QList (""));
QString zzErrMsg;

public:

bool FzScanPathFoldersRecursively (const QString &
StartPath);

bool SaveToFile (const QString & OutFileName, bool
IncludeDimensions = true, bool IncludeLastModified = true,
bool IncludeLastAccessed = true, bool IncludePathFolder = true);
};
//@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
//@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

#endif // DISK_SCANNER_05_H
#############################################################


#############################################################
Source Code main.CPP (autogenerated by QT)
#############################################################
#include "mainwindow.h"
#include <QApplication>
#include "disk_scanner_05.h"

int main(int argc, char *argv[])
{
QApplication a(argc, argv);
MainWindow w;
w.show();

return a.exec();
}
#############################################################

#############################################################
Source Code mainwindow.CPP (GUI, autogenerated by QT)
#############################################################
#include <QCoreApplication>
#include "mainwindow.h"
#include "ui_mainwindow.h"
#include "disk_scanner_05.h"

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
clsDiskMap GloDiskMap;
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::MainWindow)
{
ui->setupUi(this);
}

MainWindow::~MainWindow()
{
delete ui;
}

void MainWindow::on_btnGo_clicked(bool checked)
{
QString StartPath (ui->txtStartPath->text());
QString OutFileName (ui->txtOutputFileName->text());

GloDiskMap . FzScanPathFoldersRecursively (StartPath);

GloDiskMap . SaveToFile (OutFileName);

}
#############################################################

#############################################################
Source code disk_scanner_05.CPP (my code)
#############################################################
#include <QCoreApplication>
#include <QtCore>
#include <QDateTime>
#include <QString>
#include <QDir>
#include <QFileInfo>


// extern DiskScanner::clsDiskMap GloDiskMap;
// extern clsDiskMap GloDiskMap;
// DiskScanner::clsDiskMap GloDiskMap;
// clsDiskMap * GloDiskMap = new clsDiskMap ();

// {};

//@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

class clsDiskMap;

class clsFileAttributes
{
friend class clsDiskMap;
friend class clsAssocFileNameToAttributes;

public:
static bool ExcludePathFoldersFromComparison;
static const char * const DateTimeFormat;

public:
QDateTime LastModified; // QDateTime::fromTime_t(uint
seconds, const QTimeZone & timeZone)
QDateTime LastAccessed;
quint64 Dimensions;

QString * ptrPathFolder; // dato PESANTE, ma presente
solo come puntatore, lo spazio è consumato altrove


static bool ExcludePathFoldersFromComparisons ()
{
bool OldValue = ExcludePathFoldersFromComparison;
ExcludePathFoldersFromComparison = true;
return OldValue;
}

static bool IncludePathFoldersInComparisons ()
{
bool OldValue = ExcludePathFoldersFromComparison;
ExcludePathFoldersFromComparison = false;
return OldValue;
}

bool operator == (const clsFileAttributes & Arg) const
{
if (Dimensions != Arg . Dimensions) return false;
if (LastAccessed != Arg . LastAccessed) return false;
if (LastModified != Arg . LastModified) return false;
if (ExcludePathFoldersFromComparison = true)
return true;
if (QString :: compare ((* ptrPathFolder), (*(Arg .
ptrPathFolder))) != 0) return false;
return true;
}

bool operator != (const clsFileAttributes & Arg) const
{
if (Dimensions != Arg . Dimensions) return true;
if (LastAccessed != Arg . LastAccessed) return true;
if (LastModified != Arg . LastModified) return true;
if (ExcludePathFoldersFromComparison = true)
return false;
if (QString :: compare ((* ptrPathFolder), (*(Arg .
ptrPathFolder))) != 0) return true;
return false;
}

bool FzGetFileAttributes (const QString & FolderPath,
const QString & FileName)
{
try
{
QString FullName (FolderPath);
if (!(FullName . endsWith (QChar ('/'))))
FullName . append ("/");
ptrPathFolder = & FullName; // sarebbe il
FolderPath TERMINATO da SLASH;
FullName . append (FileName);
QFileInfo Infos (FullName);
Dimensions = Infos . size ();
LastModified = Infos . lastModified ();
LastAccessed = Infos . lastRead ();
return true;
}
catch (...)
{
return false;
}
}

QString To_String (bool IncludeDimensions = true, bool
IncludeLastModified = true, bool IncludeLastAccessed = true,
bool IncludePathFolder = true)
{
QBuffer Buf;
Buf . open (QBuffer :: WriteOnly);
if (IncludeDimensions = true)
{ Buf . write ("[Size : "); Buf . write
(QString :: number (Dimensions) . toUtf8 ()); Buf . write
("]"); }
if (IncludeLastModified = true)
{ Buf . write ("[Last Modified : "); Buf .
write (LastModified . toString (DateTimeFormat) . toUtf8
()); Buf . write ("]"); }
if (IncludeLastAccessed = true)
{ Buf . write ("[Last Accessed : "); Buf .
write (LastAccessed . toString (DateTimeFormat) . toUtf8
()); Buf . write ("]"); }
if (IncludePathFolder = true)
{ Buf . write ("["); Buf . write (ptrPathFolder
-> toUtf8 ()); Buf . write ("]"); }
Buf . write ("\n");
Buf . close ();
return (QString (Buf . buffer ()));
}
};

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - -
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - -

const char * const clsFileAttributes :: DateTimeFormat =
"yyyy_MM_dd___HH_mm_ss";

bool clsFileAttributes :: ExcludePathFoldersFromComparison =
false;

//@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

class clsAssocFileNameToAttributes
{
friend class clsMappaAssocsFileNamesToTheirAttributes;
friend class clsDiskMap;

private:
const QString * zzFileNameKey;
QList <clsFileAttributes>
zzListaAttributiAndFoldersOfFileName;

public:
clsAssocFileNameToAttributes () : zzFileNameKey (NULL),
zzListaAttributiAndFoldersOfFileName ()
{ return; }

clsAssocFileNameToAttributes (const QString &
ArgFileNameKey) : zzFileNameKey (& ArgFileNameKey),
zzListaAttributiAndFoldersOfFileName ()
{ return; }

const QList <clsFileAttributes> & GetListaAttributiFile ()
{ return zzListaAttributiAndFoldersOfFileName; }

int CercaAttributiFile (const clsFileAttributes &
AttributiFileCercati) const
{
try
{
for (int J = 0; J <
zzListaAttributiAndFoldersOfFileName . size (); J ++)
{
if (AttributiFileCercati ==
(zzListaAttributiAndFoldersOfFileName . at (J)))
return J;
}
return -1;
}
catch (...) { return false; }
}

bool AggiungiNuoviAttributiFile (const
clsFileAttributes & ArgNuoviAttributiFile)
{
// nota : aggiunge solo se non già presente
if (CercaAttributiFile (ArgNuoviAttributiFile) >=
0) return true;
try { zzListaAttributiAndFoldersOfFileName .
append (ArgNuoviAttributiFile); return true; }
catch (...) { return false; }
}

bool EliminaAttributiFile (const clsFileAttributes &
ArgAttributiFile)
{
// nota : elimina valore solo se già presente
try
{
int Posiz = CercaAttributiFile (ArgAttributiFile);
if (Posiz < 0) return true;
zzListaAttributiAndFoldersOfFileName . removeAt
(Posiz);
return true;
}
catch (...) { return false; }
}

const QString & GetFileName () const
{ return (* zzFileNameKey); }

const QString & SetFileName (const QString & NewFileName)
{ return (*(zzFileNameKey = & NewFileName)); }

bool operator == (const QString & Op2) { return ((*
zzFileNameKey) == Op2); }
bool operator != (const QString & Op2) { return ((*
zzFileNameKey) != Op2); }

bool operator == (const clsAssocFileNameToAttributes &
Op2) { return ((* zzFileNameKey) == Op2 . GetFileName ()); }
bool operator != (const clsAssocFileNameToAttributes &
Op2) { return ((* zzFileNameKey) != Op2 . GetFileName ()); }


QString To_String (bool IncludeDimensions = true, bool
IncludeLastModified = true, bool IncludeLastAccessed = true,
bool IncludePathFolder = true)
{
QBuffer Buf;
Buf . open (QBuffer :: WriteOnly);
Buf . write ("{FileName : "); Buf . write ((*
zzFileNameKey) . toUtf8 ()); Buf . write ("}"); Buf . write
("\n");
Buf . write ("{"); Buf . write ((QString :: number
(zzListaAttributiAndFoldersOfFileName . size ())) . toUtf8
()); Buf . write (" INSTANCES}"); Buf . write ("\n");
Buf . write ("{\n");
for (int J = 0; J <
zzListaAttributiAndFoldersOfFileName . size (); J ++)
{
Buf . write
((zzListaAttributiAndFoldersOfFileName . value (J)) .
To_String (IncludeDimensions, IncludeLastModified,
IncludeLastAccessed, IncludePathFolder) . toUtf8 ());
}
Buf . write ("\n");
Buf . write ("}");
Buf . write ("\n");
Buf . close ();
return (QString (Buf . buffer ()));
}

};

//@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

class clsMappaAssocsFileNamesToTheirAttributes
{
friend class clsDiskMap;
friend class clsAssocFileNameToAttributes;
private:
QList <clsAssocFileNameToAttributes> zzMappa;

public:
int AggiungiFileNameKeySeManca (const QString &
NewFileNameKey)
{
try
{ // cerca la chiave
for (int J = 0; J < zzMappa . size (); J ++)
{
if (zzMappa . value (J) . GetFileName () ==
NewFileNameKey)
return J;
}
zzMappa . append (* new
clsAssocFileNameToAttributes (NewFileNameKey));
return (zzMappa . size () - 1); // DA
VERIFICARE che l'indice sia davvero l'ultimo
}
catch (...)
{ return -1; };
return true;
}

bool AggiungiFilesAttributes (const QString & FileName,
const clsFileAttributes & NewFileNameAttribute)
{
try
{
int Position = -1;
if ((Position = AggiungiFileNameKeySeManca
(FileName)) < 0) return false;
return (zzMappa . value (Position) .
AggiungiNuoviAttributiFile (NewFileNameAttribute));
}
catch (...)
{ return false; };
return true;
}

const QList <clsFileAttributes> & GetAttributiFile
(const QString & FileNameKey)
{
try
{
for (int J = 0; J < zzMappa . size (); J ++)
{
if (zzMappa . at (J) . GetFileName () ==
FileNameKey)
return (zzMappa . value (J) .
GetListaAttributiFile ());
}
return * new QList <clsFileAttributes>;
}
catch (...)
{ return * new QList <clsFileAttributes>; };
}

QString To_String (bool IncludeDimensions = true, bool
IncludeLastModified = true, bool IncludeLastAccessed = true,
bool IncludePathFolder = true)
{
QBuffer Buf;
Buf . open (QBuffer :: WriteOnly);
Buf . write ("<<MAPPA : "); Buf . write ((QString
:: number (zzMappa . size ())) . toUtf8 ()); Buf . write ("
ELEMENTI>>"); Buf . write ("\n");
Buf . write ("<<\n");
for (int J = 0; J < zzMappa . size (); J ++)
{
Buf . write ((zzMappa . value (J)) . To_String
(IncludeDimensions, IncludeLastModified,
IncludeLastAccessed, IncludePathFolder) . toUtf8 ());
}
Buf . write ("\n");
Buf . write (">>\n");
Buf . close ();
return (QString (Buf . buffer ()));
}
};

//@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

class clsDiskMap
{
private:
QStringList DB_FullPathnamesFoldersTree;
// clsDizionario <QString>
DB_FromUnivocFilenamesToTheirPathFolders; // = QMap
<QString, QStringList> ("", QStringList (""));
clsMappaAssocsFileNamesToTheirAttributes
DB_FromUnivocFilenamesToTheirAttributes; // = QMultiMap
<QString, QList <clsFileAttributes> > ("", QList (""));
QString zzErrMsg;

public:

bool FzScanPathFoldersRecursively (const QString &
StartPath)
{
try
{
int Posiz = -1;
QString CurDir, CurFil;
clsFileAttributes FilAttr;
QDir::Filters FiltroDirs (QDir::AllDirs);
QDir::SortFlag FlagOrdinamento = QDir::NoSort;
QDir Directory (StartPath);
// DB_FullPathnamesFoldersTree = QStringList
(Directory . entryList ("", FiltroDirs, FlagOrdinamento));
DB_FullPathnamesFoldersTree = Directory . entryList
(QStringList(), FiltroDirs, FlagOrdinamento);
for (int J = 0; J < DB_FullPathnamesFoldersTree .
size(); J ++)
{
CurDir = DB_FullPathnamesFoldersTree . at (J);
if (CurDir . isEmpty ())
continue;
QDir TmpDirFiles (CurDir, QString (),
FlagOrdinamento, QDir::Files);
QStringList Files = TmpDirFiles . entryList
(QStringList()) ;
for (int Q = 0; Q < Files . size (); Q ++)
{
CurFil = Files . at (Q);
if (CurFil . isEmpty ())
continue;
if (! FilAttr . FzGetFileAttributes
(CurDir, CurFil))
throw ("FzScanPathFoldersRecursively >>
FzGetFileAttributes = non riesco a leggere gli attributi del
file");
// cerca nella QMultiMap
if ((Posiz =
DB_FromUnivocFilenamesToTheirAttributes .
AggiungiFileNameKeySeManca (CurFil)) < 0)
throw ("FzScanPathFoldersRecursively >>
FzGetFileAttributes = non riesco ad aggiungere una chiave
mancante al DB");
DB_FromUnivocFilenamesToTheirAttributes .
zzMappa . value (Posiz) . AggiungiNuoviAttributiFile (FilAttr);
};
};
return true;
}
catch (...)
{
zzErrMsg = "FzScanPathFoldersRecursively";
};
}


bool SaveToFile (const QString & OutFileName, bool
IncludeDimensions = true, bool IncludeLastModified = true,
bool IncludeLastAccessed = true, bool IncludePathFolder = true)
{
if (OutFileName . isEmpty ()) return false;
QBuffer Buf;
Buf . open (QBuffer :: WriteOnly);
Buf . write ("<<MAPPA : "); Buf . write ((QString
:: number (DB_FromUnivocFilenamesToTheirAttributes . zzMappa
. size ())) . toUtf8 ()); Buf . write (" ELEMENTI>>"); Buf .
write ("\n");
Buf . write ("<<\n");
for (int J = 0; J <
DB_FromUnivocFilenamesToTheirAttributes . zzMappa . size ();
J ++)
{
Buf . write
((DB_FromUnivocFilenamesToTheirAttributes . zzMappa . value
(J)) . To_String (IncludeDimensions, IncludeLastModified,
IncludeLastAccessed, IncludePathFolder) . toUtf8 ());
}
Buf . write ("\n");
Buf . write (">>\n");
Buf . close ();
QFile File (OutFileName);
File . open (QFile::ReadWrite);
File . write (Buf . buffer ());
File . close ();
return (true);
}
};
//@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
#############################################################

OUTCOME OF BUILD ALL command from IDE menu

#############################################################
compile output
17:01:04: Running steps for project Prova_QT_00...
17:01:04: Configuration unchanged, skipping qmake step.
17:01:05: Starting: "/usr/bin/make"
g++ -m64 -o Prova_QT_00 main.o mainwindow.o
disk_scanner_07.o moc_mainwindow.o
-L/usr/lib/x86_64-linux-gnu -lQtGui -lQtCore -lpthread
mainwindow.o: In function `MainWindow::on_btnGo_clicked(bool)':
/home/gattovizzato/B/SourceCode/QT5/build-Prova_QT_00-Desktop-Debug/../Prova_QT_00/mainwindow.cpp:28:
undefined reference to
`clsDiskMap::FzScanPathFoldersRecursively(QString const&)'
/home/gattovizzato/B/SourceCode/QT5/build-Prova_QT_00-Desktop-Debug/../Prova_QT_00/mainwindow.cpp:30:
undefined reference to `clsDiskMap::SaveToFile(QString
const&, bool, bool, bool, bool)'
Makefile:108: recipe for target 'Prova_QT_00' failed
collect2: error: ld returned 1 exit status
make: *** [Prova_QT_00] Error 1
17:01:05: The process "/usr/bin/make" exited with code 2.
Error while building/deploying project Prova_QT_00 (kit:
Desktop)
When executing step "Make"
17:01:05: Elapsed time: 00:00.
#############################################################

ISSUES :

/home/gattovizzato/B/SourceCode/QT5/Prova_QT_00/mainwindow.cpp:28:
error: undefined reference to
`clsDiskMap::FzScanPathFoldersRecursively(QString const&)'

/home/gattovizzato/B/SourceCode/QT5/Prova_QT_00/mainwindow.cpp:30:
error: undefined reference to
`clsDiskMap::SaveToFile(QString const&, bool, bool, bool, bool)'

:-1: error: collect2: error: ld returned 1 exit status

#############################################################


As I said, I have used only Visual Studio since long, and
I'm not familiar with QT Creator

Ciao
and tnx for attention

[Soviet_Mario]

Il 01/07/2018 19:45, Paavo Helde ha scritto:

> On 1.07.2018 19:52, Soviet_Mario wrote:
>> Il 01/07/2018 15:21, Sam ha scritto:
>>> Soviet_Mario writes:
>>>

uh I forgot the PROJECT file (generated by QT Creator)

#-------------------------------------------------
#
# Project created by QtCreator 2018-06-21T16:21:34
#
#-------------------------------------------------

QT += core gui

greaterThan(QT_MAJOR_VERSION, 4): QT += widgets

TARGET = Prova_QT_00
TEMPLATE = app


SOURCES +=\
main.cpp \
mainwindow.cpp \
disk_scanner_07.cpp

HEADERS += mainwindow.h \
disk_scanner_05.h

FORMS += mainwindow.ui

[Sam]

Soviet_Mario writes:

> Il 01/07/2018 15:21, Sam ha scritto:
> > Soviet_Mario writes:
> >
> >> I'm getting different errors when compiling and changing
> >> the order of the files.
> >> Now I still have clear enough notion of SCOPE of object,
> >> but I must admit I have none about the sequence of scopes
> >> (the "order" the files are compiled or, maybe, linked).
> >> Is this relevant ?
> >
> > The only thing that can be stated for certain here, is that
> > the file compilation order is always irrelevant.
> >
> > Nothing further can be stated withut specific, concrete,
> > examples.
>
> I had a project (autogenerated) by QT creator, consisting of
> two files : one with MAIN app, the other for initing the GUI
>
> Then I added a MY.CPP further file with some generic class
> declaration.
>
> Building all I obtained errors like "type class XXX is not
> defined".
>
> When I embedded the same code and declarations from MY.CPP
> either in Main.CPP or in MainWindow.CPP, the build went
> plain without errors.

So far, you've provided no evidence that compilation order matters.

> So I'm trying to understand where to put code and why
> splitting it in handy files won't work.
> There might be wrong link settings ? I can't find them (I
> used to use VStudio, but I'm trying to move to QTcreator and
> I'm less than newbie in this IDE).
> There might be other aspect in declarations I miss / forgot
> (like extern directives ?)

Declarations have nothing to do with compilation order.

My current project consists of 422 .C files. They can be compiled in any
order, and when it comes to link time, no matter what order they get built
in, everything links correctly. Actually, every time I build it things
always get built in slightly different order. I use a parallel build, so the
next file gets compiled as soon as one of the current modules finishes
compiling; so the compilation order varies slightly, every time.

> I've a vague memory that extern variables without static had
> global scope (with static they were restricted to file
> scope). As far as class declaration I've no memory of their
> scope and if/how to alter it.

If you are seeking assistance with your compilation troubles, it will be
necessary to provide something more substantive than vague memories and
recollections.

> >
> >> I tried to resort to include, but it didn't work ...
> >
> > Trying random things, without a clear understanding of what
> > the problem is, is very unlikely to be very productive.
>
> I'm asking in order to understand

All C++ books provide detailed information about scoping, and how header
files work. If there's

>
> >
> > The first step towards solving a problem is understanding
> > what the actual problem is. Your entire vague, nebulous
> > description indicates that you don't seem to understand what
> > the actual problem is,
>
> true
>
> > and can't even communicate it, clearly.
>
> a consequence of the former :)
>
> I tried to explain with a generic example ... I dunno if it
> will be useful

No, it's not. "Generic examples" are rarely useful. What is useful are
concrete, specific examples. Vaguely describing files by name, like
"my.cpp", with generic description of what they look like is like calling an
auto mechanic, providing a generic description like "my car doesn't move
when I press the gas pedal", and expect to achieve productive results with
that.

[Paavo Helde]

On 2.07.2018 18:13, Soviet_Mario wrote:
> //@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>
>
> class clsDiskMap
> {
> private:
> QStringList DB_FullPathnamesFoldersTree;
> // clsDizionario <QString>
> DB_FromUnivocFilenamesToTheirPathFolders; // = QMap <QString,
> QStringList> ("", QStringList (""));
> clsMappaAssocsFileNamesToTheirAttributes
> DB_FromUnivocFilenamesToTheirAttributes; // = QMultiMap <QString, QList
> <clsFileAttributes> > ("", QList (""));
> QString zzErrMsg;
>
> public:
>
> bool FzScanPathFoldersRecursively (const QString & StartPath);
>
> bool SaveToFile (const QString & OutFileName, bool
> IncludeDimensions = true, bool IncludeLastModified = true, bool
> IncludeLastAccessed = true, bool IncludePathFolder = true);
> };
>
> //@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>
>

> class clsDiskMap
> {
> private:
> QStringList DB_FullPathnamesFoldersTree;
> // clsDizionario <QString>
> DB_FromUnivocFilenamesToTheirPathFolders; // = QMap <QString,
> QStringList> ("", QStringList (""));
> clsMappaAssocsFileNamesToTheirAttributes
> DB_FromUnivocFilenamesToTheirAttributes; // = QMultiMap <QString, QList
> <clsFileAttributes> > ("", QList (""));
> QString zzErrMsg;
>
> public:
>
> bool FzScanPathFoldersRecursively (const QString & StartPath)
> {
> try
> {
> int Posiz = -1;

...

> /home/gattovizzato/B/SourceCode/QT5/Prova_QT_00/mainwindow.cpp:28:
error: undefined reference to
`clsDiskMap::FzScanPathFoldersRecursively(QString const&)'

'undefined reference' means a linker error.

Apparently, you have defined class clsDiskMap in two places, once
containing member function declarations and the second time definitions.
This is a violation of the ODR (one definition rule) and will cause UB.

Instead, the member function definitions should go into the cpp file
without no enclosing class:

// clsDiskMap.cpp:
#include "clsDiskMap.h"

bool clsDiskMap::FzScanPathFoldersRecursively (const QString & StartPath)
{
try
{
...

[Soviet_Mario]

oh, one thing solved, at least ! TY

>
> Apparently, you have defined class clsDiskMap in two places,
> once containing member function declarations and the second
> time definitions. This is a violation of the ODR (one
> definition rule) and will cause UB.

this makes me wonder what MUST NOT be declared in headers ...
I put the prototypes (of member functions), that is the
declarations of parameters and return type (I did not erase
the NAMES of formal parameters ... is this relevant ?), but
in the header I removed the BLOCK with the function body,
and semicolon after closed ")".

In the CPP file there where the same declarations (but
without semicolor) were followed by the block of code
(function body) which I thought makes a true definition.

>
> Instead, the member function definitions should go into the
> cpp file without no enclosing class:

I'm not sure to be understanding what you mean).

Do I have to move the (MEMBER) function BODIES outside the
class braces ? Why this, in the same file, changes
visibility to the linker ?

>
> // clsDiskMap.cpp:
> #include "clsDiskMap.h"

another thing I don't understand.
Generally I include the XXX.H header only in OTHER CPP
files, not in the same XXX.CPP.
Is this wrong ? HOW the "self" header helps to see itself ?

Sorry but I'm very rusty, I'm not using this language since
2004 or so, yes I read some material to refresh, but not
everything.

You confirm that a generic XXX.CPP needs its "same" header
XXX.H ? Would you also mind to try to explain me why this ?

TY

I try to experiment meanwhile ...

>
> bool clsDiskMap::FzScanPathFoldersRecursively (const QString
> & StartPath)
>       {
>       try
>           {
>     ...
>
>
>
>

[Soviet_Mario]

hey, friend, I was only suggesting and asking for advice, I
was never stating it was or should be ...

>
>> So I'm trying to understand where to put code and why
>> splitting it in handy files won't work.
>> There might be wrong link settings ? I can't find them (I
>> used to use VStudio, but I'm trying to move to QTcreator and
>> I'm less than newbie in this IDE).
>> There might be other aspect in declarations I miss / forgot
>> (like extern directives ?)
>
> Declarations have nothing to do with compilation order.

ok. Better so !

>
> My current project consists of 422 .C files. They can be
> compiled in any order, and when it comes to link time, no
> matter what order they get built in, everything links
> correctly. Actually, every time I build it things always get
> built in slightly different order. I use a parallel build,
> so the next file gets compiled as soon as one of the current
> modules finishes compiling; so the compilation order varies
> slightly, every time.

If you happen to read the reply of Paavo Helde, or mine to
his, can you clarify me which part of the CPP file must be
stripped in creating the corresponding headers ?

In particular, about function declarations, I assumed that
just stripping away the function BODY (in braces), generated
a forma declaration.
Paavo suggests that, moreover, in CPP files, the body
definition should be moved from within the class body, outside.
I'm not understanding this and how it influences linking.

If I manually merge the files in one, even leving function
definitions within their class block, works.

Why does it no longer work splitting the project in more files ?

I can't find the difference of defining a function entirely
within a class body or just declaring it (like in the
header) and then defining out of the class body (using the
prefix ClassOwner :: MemberFunction (...) { ... };

>
>> I've a vague memory that extern variables without static had
>> global scope (with static they were restricted to file
>> scope). As far as class declaration I've no memory of their
>> scope and if/how to alter it.
>
> If you are seeking assistance with your compilation
> troubles, it will be necessary to provide something more
> substantive than vague memories and recollections.
>

I attached the whole code as you can see.
Maybe Paavo Helde has just found a flaw in it.

>> >
>> >> I tried to resort to include, but it didn't work ...
>> >
>> > Trying random things, without a clear understanding of what
>> > the problem is, is very unlikely to be very productive.
>>
>> I'm asking in order to understand
>
> All C++ books provide detailed information about scoping,
> and how header files work. If there's

I missed this details both on paper book and in some C++
reference online ... that's why i'm trying to resort to the NG

>>
>> >
>> > The first step towards solving a problem is understanding
>> > what the actual problem is. Your entire vague, nebulous
>> > description indicates that you don't seem to understand
>> what
>> > the actual problem is,
>>
>> true
>>
>> > and can't even communicate it, clearly.
>>
>> a consequence of the former :)
>>
>> I tried to explain with a generic example ... I dunno if it
>> will be useful
>
> No, it's not. "Generic examples" are rarely useful. What is

Ok, I was wrong, but later I posted the complete code.
If this can't help, well, tnx anyway for your time (and bye)

ciao

> useful are concrete, specific examples. Vaguely describing
> files by name, like "my.cpp", with generic description of
> what they look like is like calling an auto mechanic,
> providing a generic description like "my car doesn't move
> when I press the gas pedal", and expect to achieve
> productive results with that.
>

[Paavo Helde]

On 4.07.2018 17:14, Soviet_Mario wrote:
> Il 03/07/2018 14:42, Paavo Helde ha scritto:
>> Apparently, you have defined class clsDiskMap in two places, once
>> containing member function declarations and the second time
>> definitions. This is a violation of the ODR (one definition rule) and
>> will cause UB.
>
> this makes me wonder what MUST NOT be declared in headers ...
> I put the prototypes (of member functions), that is the declarations of
> parameters and return type (I did not erase the NAMES of formal
> parameters ... is this relevant ?), but in the header I removed the
> BLOCK with the function body, and semicolon after closed ")".

Compiler sees "compilation units", which are typically cpp files merged
with all included headers. If there are two class definitions in such
files they must be textually identical. So you cannot have it contain
member functions in one case and not in the other.

> In the CPP file there where the same declarations (but without
> semicolor) were followed by the block of code (function body) which I
> thought makes a true definition.

True, but as you messed up the class definition the linker got confused.

>
>
>>
>> Instead, the member function definitions should go into the cpp file
>> without no enclosing class:
>
> I'm not sure to be understanding what you mean).
>
> Do I have to move the (MEMBER) function BODIES outside the class braces

Yes.

> ? Why this, in the same file, changes visibility to the linker ?

Who knows. UB means "undefined behavior", meaning the linker can legally
call your mom and complain about you ;-)

>
>>
>> // clsDiskMap.cpp:
>> #include "clsDiskMap.h"
>
> another thing I don't understand.
> Generally I include the XXX.H header only in OTHER CPP files, not in the
> same XXX.CPP.
> Is this wrong ? HOW the "self" header helps to see itself ?

You definitely need to include XXX.h in XXX.cpp, otherwise the member
function definitions would not compile - because the class would be
undefined. And you cannot put them inside class XXX {...} as this would
create a second incompatible definition of the class.

Suggesting to find a C++ tutorial explaining those things...

[Soviet_Mario]

Il 04/07/2018 17:20, Paavo Helde ha scritto:
> On 4.07.2018 17:14, Soviet_Mario wrote:
>> Il 03/07/2018 14:42, Paavo Helde ha scritto:

so I applied your advices but one (the "self" inclusion of
the header).

Now it compiles and links the project without complaints.

I deem that the .CPP unit compiles smoothly even in the
absence of his equivalent .H because there are not circular
references and the only dependences are "friendship"
declarations solved with a plain forward declaration.
Maybe in the presence of more complex class hierarchy the .H
file could be necessary, I don't know.
Or else, the QT is not completely standard, as sb said
elsewere, and it allows compiling A.CPP who dont include A.H ...

I had to make also a lot of small edits in STATIC members
and extern declarations.
Alas even if now it works, I must admit I've not understood
well WHY and how, even after reading.

Anyway as a question of style, I'll try to put the function
out of the class.
I kept inside just a few function with an only one statement
of kind "return Varname;", but in this case I also added
INLINE prefix.

>>> Apparently, you have defined class clsDiskMap in two
>>> places, once
>>> containing member function declarations and the second time
>>> definitions. This is a violation of the ODR (one
>>> definition rule) and
>>> will cause UB.
>>
>> this makes me wonder what MUST NOT be declared in headers ...
>> I put the prototypes (of member functions), that is the
>> declarations of
>> parameters and return type (I did not erase the NAMES of
>> formal
>> parameters ... is this relevant ?), but in the header I
>> removed the
>> BLOCK with the function body, and semicolon after closed ")".
>
> Compiler sees "compilation units", which are typically cpp
> files merged with all included headers. If there are two
> class definitions in such files they must be textually
> identical.

oh but they did seem such to me, but, evidently ... :\ they
were not or were wrong.

If intresting, I could post again the full code modified ...
I guess nobody would be interested in (it is just in
embrio-state after all)

> So you cannot have it contain member functions in
> one case and not in the other.
>
>> In the CPP file there where the same declarations (but
>> without
>> semicolor) were followed by the block of code (function
>> body) which I
>> thought makes a true definition.
>
> True, but as you messed up the class definition the linker
> got confused.

eh ... it's a bit sad to have solved without having actually
understood how.
But it is simpler to keep it compiling by applying small
changes and testing than to strip away the damned last
couple of errors that prevent to get the very first
buildable solution, starting from scratch with a code that
had never been compiled successfully ... some 12 years after
the last use of the language (and on a brand new, for me, IDE).

I was on VStudio and VB/C# for a long time (and coding only
from time to time actually), and now that I've passed on
linux and QT, a thousands of problems have been to be solved
to get this piece of code showing up in a window with a
couple of buttons :)

>>
>>
>>>
>>> Instead, the member function definitions should go into
>>> the cpp file
>>> without no enclosing class:
>>
>> I'm not sure to be understanding what you mean).
>>
>> Do I have to move the (MEMBER) function BODIES outside the
>> class braces
>
> Yes.
>
>
>> ? Why this, in the same file, changes visibility to the
>> linker ?
>
> Who knows. UB means "undefined behavior", meaning the linker
> can legally call your mom and complain about you ;-)

mmm, as a matter of facts, either the inline directive amend
that mandatory feature, or QR creator allows in some cases
(don't ask me when !), or both, but actually the code
compile and link with some very trivial function embodied in
the class body.

>
>>
>>>
>>> // clsDiskMap.cpp:
>>> #include "clsDiskMap.h"
>>
>> another thing I don't understand.
>> Generally I include the XXX.H header only in OTHER CPP
>> files, not in the
>> same XXX.CPP.
>> Is this wrong ? HOW the "self" header helps to see itself ?
>
> You definitely need to include XXX.h in XXX.cpp, otherwise
> the member function definitions would not compile - because
> the class would be undefined.

sorry I don't understand the point (and I have NOT included
it, and still it links ...)

MAYBE this is due to the fact that the declaration was
maintained ALSO in the .CPP unit, which actually replicates
the header declarations ... with the exception of STATIC
(shared in VStudio terms) members and (shared) member
CONSTS, which are defined only in the CPP module.

oh, one thing : member variables are "indifferent", that is,
I can declare them or not in the .H, and nothing changes on
build.
They are all private and just a CONST shared public.

I think this is due to the fact that they are not
definitions, don'allocate anything, they just describe the
shape of the container.

I can't think of situation where :
1) such variable members declarations WERE NECESSARY in the
.H (and if public, protected or private, or any)
2) such variable members declarations WERE FORBIDDEN in the
.H (and if public, protected or private, or any)

for now it seems INDIFFERENT, but I'd be glad to understand
if the aforementioned cases exist with some example ...

> And you cannot put them inside
> class XXX {...} as this would create a second incompatible
> definition of the class.
>
> Suggesting to find a C++ tutorial explaining those things...

Oh I'm reading some material from StackOverflow and
elsewhere ...

TY
Ciao

[Paavo Helde]

On 4.07.2018 20:11, Soviet_Mario wrote:
> Il 04/07/2018 17:20, Paavo Helde ha scritto:
>> On 4.07.2018 17:14, Soviet_Mario wrote:
>>> Il 03/07/2018 14:42, Paavo Helde ha scritto:
>
> so I applied your advices but one (the "self" inclusion of the header).

Then it probably got included indirectly via another header.

> Now it compiles and links the project without complaints.

Good!

>
> I deem that the .CPP unit compiles smoothly even in the absence of his
> equivalent .H because there are not circular references and the only
> dependences are "friendship" declarations solved with a plain forward
> declaration.

'Circular' and 'friend' only come into play if you have more than one class.

> Anyway as a question of style, I'll try to put the function out of the
> class.
> I kept inside just a few function with an only one statement of kind
> "return Varname;", but in this case I also added INLINE prefix.

This is redundant, member functions defined inside the class definition
are already implicitly considered 'inline'.

Cheers
Paavo

[Soviet_Mario]

Il 04/07/2018 19:51, Paavo Helde ha scritto:
> On 4.07.2018 20:11, Soviet_Mario wrote:
>> Il 04/07/2018 17:20, Paavo Helde ha scritto:
>>> On 4.07.2018 17:14, Soviet_Mario wrote:
>>>> Il 03/07/2018 14:42, Paavo Helde ha scritto:
>>
>> so I applied your advices but one (the "self" inclusion of
>> the header).
>
> Then it probably got included indirectly via another header.

no, actually not.
But, as I said, I'm likely to have duplicated the header in
the CPP file, as EVERYTHING declared in the header, is also
declared (besides defined) in the CPP.
I guess a CPP module is added at most once regardeless of
safeguards #indef / #define / #endif as it is done in .H, so
this redundant declaration is seen in the CPP module as the
only one (not having included corresponding .H), and
elsewhere, the CPP is not included, and then only the .H
declaration is seen.
The two match perfectly (now).

The fact is : i HATE coding while having to look at two
files at a time, and I find it "handy" to have declarations
in the same file where I write their definitions.
I don't know if it is strange or not.

As I discovered today that QT IDE allows for SPLIT VIEW,
then I could also do without this habit :)

>
>> Now it compiles and links the project without complaints.
>
> Good!
>
>>
>> I deem that the .CPP unit compiles smoothly even in the
>> absence of his
>> equivalent .H because there are not circular references
>> and the only
>> dependences are "friendship" declarations solved with a
>> plain forward
>> declaration.
>
> 'Circular' and 'friend' only come into play if you have more
> than one class.

I have four classes, and friendness is overused as they will
heavily access others members

>
>> Anyway as a question of style, I'll try to put the
>> function out of the
>> class.
>> I kept inside just a few function with an only one
>> statement of kind
>> "return Varname;", but in this case I also added INLINE
>> prefix.
>
> This is redundant, member functions defined inside the class
> definition are already implicitly considered 'inline'.

ah, ok, got it.
While if one wants to inline outer members, then he should
declare explicitely, true ?
Ciao

>
> Cheers
> Paavo

[Paavo Helde]

Yes, but if defined in a cpp file they would be visible only in this cpp
file then, potentially causing linker errors if used by other cpp files.

BTW, 'inline' has completely lost its original meaning. Now its only
purpose is to say: yes linker, I am defining this function here in the
common header file included in 1000 cpp files, please shut up and cope
with those 1000 duplicates by yourself!

[Sam]

Soviet_Mario writes:

> In particular, about function declarations, I assumed that just stripping
> away the function BODY (in braces), generated a forma declaration.

No, it doesn't. You have to replace the whole body with a semicolon.
Otherwise it won't compile.

> Paavo suggests that, moreover, in CPP files, the body definition should be
> moved from within the class body, outside.
> I'm not understanding this and how it influences linking.

What you're not understanding, apparently, is how class declarations work,
and how class methods are defined. Functions and class methods have several
important differences. Class methods look like functions, but they're not
functions. They're class methods.

> If I manually merge the files in one, even leving function definitions
> within their class block, works.
>
> Why does it no longer work splitting the project in more files ?

Too vague, and nebulous. to answer specifically.

In general, you can't just take random pieces of code from one file, chop it
up into pieces, and splatter the results into different files, randomly,
without making any other changes, and in addition to making appropriate
changes to the moved code, also writing some additional header files, so
that everything is still properly declared before it's used. It just won't
work. C++ does not work this way.

You can't just say, take:

class Foo {

// Some declarations

void bar()
{
// Some code
}
};

Replace it with

class Foo {

void bar();
};

and then go and write

void Foo::bar()
{
// Some code
}

somewhere else. At least not without including the header file. And even if
you include the header file, you can't do that if the class method is a
template class method.

> I can't find the difference of defining a function entirely within a class
> body or just declaring it (like in the header) and then defining out of the
> class body (using the prefix ClassOwner :: MemberFunction (...) { ... };

That's because there is no difference, provided that everything else is set
up correctly, and wherever the class method (not a function) gets defined,
over there the declarations of everything that the class method uses are
properly declared. And that "wherever" gets linked.

> I attached the whole code as you can see.

No, I do not see anything in your message. You might've included your code
in some other message, that's lost somewhere else in the newsgroup, but when
someone replies to a message that's all they see.

So, I can't really "see" anything, at the moment.

>>> > Trying random things, without a clear understanding of what
>>> > the problem is, is very unlikely to be very productive.
>>>
>>> I'm asking in order to understand
>>
>> All C++ books provide detailed information about scoping, and how header
>> files work. If there's
>
> I missed this details both on paper book and in some C++ reference
> online ... that's why i'm trying to resort to the NG

The only way to rigorously learn C++ is by using a dead tree. It's true that
there are many online resources out there. But they're not a replacement for
a well-written dead tree. Some online C++ web site may seem very attractive,
leading one to believe that all they had to do is read a couple of pages and
they become an instant C++ expert. Sorry, it doesn't work this way.

C++ is the most complicated general purpose programming language in use
today, and its complexity increased, in my estimation, about three-fold in
the last couple of years. C++ never had a reputation for instant
gratification, and now it never will. There is no alternative to setting
aside plenty of time to read through a good book, until you thoroughly
understand how declarations work, how definitions work, and other things.
Randomly cutting and pasting chunks of code, crossing your fingers, then
hope things will compile and link, is unlikely to succeed without a
thorough, complete, fundamental understanding of what you're actually doing.

[Soviet_Mario]

Il 05/07/2018 15:41, Sam ha scritto:
> Soviet_Mario writes:
>
>> In particular, about function declarations, I assumed that
>> just stripping away the function BODY (in braces),
>> generated a forma declaration.
>
> No, it doesn't. You have to replace the whole body with a
> semicolon. Otherwise it won't compile.

I've done this, a statement needs termination ...

>
>> Paavo suggests that, moreover, in CPP files, the body
>> definition should be moved from within the class body,
>> outside.
>> I'm not understanding this and how it influences linking.
>
> What you're not understanding, apparently, is how class
> declarations work, and how class methods are defined.
> Functions and class methods have several important
> differences. Class methods look like functions, but they're
> not functions. They're class methods.

could you please spend some more words on this aspect or
suggest a link ?

I just can think of differences from static members (not
bound to a particular instance), true members (with their
THIS pointer) and friend members, which are external
functions granted of access to data member (I don't remember
if they receive an implicit this pointer or a class object
reference or pointer have to be passed to them, that is they
are like static members but need to be associated with an
instance at runtime via argument explicitely passed).

But I've heard the METHOD word just in C# and VB, never in
C++. So please tell me more about this aspect

>
>> If I manually merge the files in one, even leving function
>> definitions within their class block, works.
>>
>> Why does it no longer work splitting the project in more
>> files ?
>
> Too vague, and nebulous. to answer specifically.

I gave the example here in this same 3D
snews://powernews.libero.it:563/phdffi$hsa$1...@dont-email.me

<phb40c$9o2$1...@dont-email.me>

>
> In general, you can't just take random pieces of code from

oh God, I don't just cut in RANDOM pieces, come on !

> one file, chop it up into pieces, and splatter the results
> into different files, randomly, without making any other
> changes, and in addition to making appropriate changes to
> the moved code, also  writing some additional header files,
> so that everything is still properly declared before it's
> used. It just won't work. C++ does not work this way.

this is futile sarcasm actually.
I don't understand why

>
>> I can't find the difference of defining a function
>> entirely within a class body or just declaring it (like in
>> the header) and then defining out of the class body (using
>> the prefix ClassOwner :: MemberFunction (...) { ... };
>
> That's because there is no difference, provided that
> everything else is set up correctly, and wherever the class
> method (not a function) gets defined, over there the
> declarations of everything that the class method uses are
> properly declared. And that "wherever" gets linked.

oh
very confusing getting different opinions. I can't exteem
which is correct :\

>
>> I attached the whole code as you can see.
>
> No, I do not see anything in your message. You might've

it was above in the same tread. It is not a huge 3D

> included your code in some other message, that's lost
> somewhere else in the newsgroup, but when someone replies to
> a message that's all they see.
>
> So, I can't really "see" anything, at the moment.
>
>>>> > Trying random things, without a clear understanding of
>>>> what
>>>> > the problem is, is very unlikely to be very productive.
>>>>
>>>> I'm asking in order to understand
>>>
>>> All C++ books provide detailed information about scoping,
>>> and how header files work. If there's
>>
>> I missed this details both on paper book and in some C++
>> reference online ... that's why i'm trying to resort to
>> the NG
>
> The only way to rigorously learn C++ is by using a dead
> tree.

I did it once, on Bjarne Stroustrup textbook, I'm not
learning C++ from scratch, I just need to remove some rust
(I'm also new to QT which makes the things harder)

> It's true that there are many online resources out
> there. But they're not a replacement for a well-written dead
> tree. Some online C++ web site may seem very attractive,
> leading one to believe that all they had to do is read a
> couple of pages and they become an instant C++ expert.
> Sorry, it doesn't work this way.

Friend, first of all I don't need to become an expert, and
secondly I happen to have studied a lot, just long ago.
I manage to "think" in C++ terms, but I'm no longer FLUENT
in the constructs.
I never managed every single aspect of the language (for
example closures, lamda expressions are beyond my skills),
but I just need to use a C+ (a far better and type checked
C). Rarely I used also IsA inheritance (preferring HasA pattern)

>
> C++ is the most complicated general purpose programming
> language in use today, and its complexity increased, in my

Im very outdated on last 10 yrs developments ... but
actually I need to solve rather basic doubts, I'm an hobbyist

> estimation, about three-fold in the last couple of years.
> C++ never had a reputation for instant gratification, and

oh I'm not in a hurry, never mind.
The fact is, I find it rather easy to think in C++ terms
when designing the data layout, and also easy to code
algoritms in this language.
But I make many syntax mistakes or more subtle errors

> now it never will. There is no alternative to setting aside
> plenty of time to read through a good book, until you
> thoroughly understand how declarations work, how definitions
> work, and other things. Randomly cutting and pasting chunks

friend, it has never been my habit to steal other's code. I
write it all by myself and try to learn from what I read.

> of code, crossing your fingers, then hope things will
> compile and link, is unlikely to succeed without a thorough,
> complete, fundamental understanding of what you're actually
> doing.

well, sarcasm's deluge. Congrats.
I still have to understand why

Just try to assume I can be misunderstood cause I don't
master English, at least