How do you organise streaming/gui-related code?

[peter koch]

Hello group,

I have a question that is not technical in nature. Still, I believe that the answer might depend on the fact that the language is C++, given its rather antiquated way of handling compilation.

I have a group of user-defined types for which I have what I would categorize of non-trivial (text-based) I/O. Those types can also be displayed via a GUI.
So what is the "proper" way to organize your source?
Say I have a type:

struct Complex
{
Complex1 field1;
Complex2 field2;
...
ComplexN fieldN;
};

This structure is fully streamable, so you can both stream it out (which is more or less trivial) and stream it in (which is non-trivial, requiring a parser - implemented in boost::spirit).

Complex can also be dispalyed on a GUI. Again, the code is rather complex and heavily templated.

Currently, I have chosen to use three files to represent the class:
complex.hpp, (the struct) complex_tio.hpp (std::stream functions including parsing) and complex_gui.hpp (includes gui-code). This is not a bad solution, I think, but I would like to also hear YOUR opinion. ;-)

/Peter

[Öö Tiib]

On Tuesday, 4 July 2017 00:04:22 UTC+3, peter koch wrote:
>
> Currently, I have chosen to use three files to represent the class:
> complex.hpp, (the struct) complex_tio.hpp (std::stream functions
> including parsing) and complex_gui.hpp (includes gui-code). This is not
> a bad solution, I think, but I would like to also hear YOUR opinion. ;-)

Your "complex" sounds like something whose nature is entirely undisclosed
so you seem to hope that there is silver bullet that covers everything?
There are no silver bullet solutions so do how you please, but I can sure
tell how I organize those.

When I need to stream objects "Whatever" to/from somewhere then I typically
make those constructible from and convertible to streamable format/document
class that I use in project, for example JSON. That capability means 2
functions to declare so I would likely declare those in "Whatever.h".
Same we can say about streaming it directly (have operator<< for ostream
and operator>> for istream). Your situation may be different ... or why
to have separate header for 2 function declarations?

About GUI however I consider every view or widget as separate class and
see those quite non-tightly related to each other and to data class
they represent.
For example if there is "list item", "table cell", "tool tip"
and "edit dialog" that represent "Whatever" in one or other part of GUI
then I would most likely have separate header ("WhateverListItem.h",
"WhateverTableCell.h", "WhateverToolTip.h" and "WhateverEditDialog.h") for
each of those and possibly in separate directories (and even modules)
from "Whatever.h" and each other. Again your situation may be different
and even GUI concept may be different, how can I know.

[Alf P. Steinbach]

On 03-Jul-17 11:04 PM, peter koch wrote:
> Hello group,
>
> I have a question that is not technical in nature. Still, I believe
> that the answer might depend on the fact that the language is C++,
> given its rather antiquated way of handling compilation.
>
> I have a group of user-defined types for which I have what I would
> categorize of non-trivial (text-based) I/O. Those types can also be
> displayed via a GUI. So what is the "proper" way to organize your
> source? Say I have a type:
>
> struct Complex
> {
> Complex1 field1;
> Complex2 field2;
> ...
> ComplexN fieldN;
> };
>
> This structure is fully streamable, so you can both stream it out
> (which is more or less trivial) and stream it in (which is
> non-trivial, requiring a parser - implemented in boost::spirit).

Yout way of presenting this is as if you think of the serialization
functionality as very strongly connected to, or even part of, the class.

That's the way I think of it too.

> Complex can also be dispalyed on a GUI. Again, the code is rather
> complex and heavily templated.

I think of that as separate /client/ code.

> Currently, I have chosen to use three files to represent the class:
> complex.hpp, (the struct) complex_tio.hpp (std::stream functions
> including parsing) and complex_gui.hpp (includes gui-code). This is
> not a bad solution, I think, but I would like to also hear YOUR
> opinion. ;-)

The serialization functionality can be useful in the GUI code. The GUI
functionality cannot reasonably be useful in the serialization code. So
these functional areas are not, IMO, on an equal footing.

So I would not put the GUI code (a view?) along with the rest.

I would split view and model also wrt. to projects file/directory
structure, with serialization as part of the model, and try to ensure
that the model supplies all the info & functionality that the view needs
to present it, edit it, whatever.


Cheers & hth., (just my 2c)

- Alf