Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

19 May, 2024: Line wrapping has been changed to be more consistent with Usenet standards.
 If you find that it is broken please let me know here rocksolid.nodes.help


devel / comp.lang.c++ / Re: OOD idea of C++ and class coding guide lines

SubjectAuthor
* OOD idea of C++ and class coding guide lineswij
+* Re: OOD idea of C++ and class coding guide lineswij
|`* Re: OOD idea of C++ and class coding guide lineswij
| `* Re: OOD idea of C++ and class coding guide lineswij
|  `* Re: OOD idea of C++ and class coding guide linesPaavo Helde
|   +* Re: OOD idea of C++ and class coding guide lineswij
|   |+- Re: OOD idea of C++ and class coding guide lineswij
|   |`- Re: OOD idea of C++ and class coding guide lineswij
|   `* Re: OOD idea of C++ and class coding guide lineswij
|    `- Re: OOD idea of C++ and class coding guide lineswij
`* Re: OOD idea of C++ and class coding guide linesChris M. Thomasson
 `* Re: OOD idea of C++ and class coding guide lineswij
  +* Re: OOD idea of C++ and class coding guide lineswij
  |`* Re: OOD idea of C++ and class coding guide lineswij
  | `- Re: OOD idea of C++ and class coding guide lineswij
  `- Re: OOD idea of C++ and class coding guide linesChris M. Thomasson

1
OOD idea of C++ and class coding guide lines

<4ebc633e-2dbd-4c5d-b9d1-45101d781c4dn@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=532&group=comp.lang.c%2B%2B#532

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:6214:132:b0:635:e6da:f372 with SMTP id w18-20020a056214013200b00635e6daf372mr4249qvs.3.1687941390686;
Wed, 28 Jun 2023 01:36:30 -0700 (PDT)
X-Received: by 2002:a05:6808:21a2:b0:3a1:f3bb:99b5 with SMTP id
be34-20020a05680821a200b003a1f3bb99b5mr1899525oib.1.1687941389804; Wed, 28
Jun 2023 01:36:29 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!newsfeed.hasname.com!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Wed, 28 Jun 2023 01:36:29 -0700 (PDT)
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=0Ek0TQoAAAAS0oceh95IuNV59QuIWNeN
NNTP-Posting-Host: 124.218.76.41
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <4ebc633e-2dbd-4c5d-b9d1-45101d781c4dn@googlegroups.com>
Subject: OOD idea of C++ and class coding guide lines
From: wynii...@gmail.com (wij)
Injection-Date: Wed, 28 Jun 2023 08:36:30 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 8357
 by: wij - Wed, 28 Jun 2023 08:36 UTC

The following are rewrite of my 20-years old coding guide lines. I'd like to
ask for suggestions to refine in the way because one reason is that recently
the many questions I saw in this forum are actually rooted in class design
problems (or problems of being too expressive, arbitrary).

------
I think one major feature C++ provides is the support (or restriction) of
Object-oriented Design. From the wiki https://en.wikipedia.org/wiki/Object-oriented_design
or others, the definition is a bit difficult to be practically applicable. And
the 'isa' part ideal of OOD I knew didn't properly work.

In addition, C++ class actually works by 'semantics' (or convention) which is
not mentioned anywhere (E.g. default constructor,copy constructor and operator=).
Thus, the following guide lines are defined (exceptions are few):

Constructor(..):
Constructor forms are in basic the Cartesian product view of problem domain
in tupple. IOW, the arguments of ctors define the class (concept).
Constructor brings an object in random state to responsible state.

Destructor:
The destructed object is no longer considered existing in the C++ language
(ref. [12.4.14]). Since destructing an object the second time results to
undefined behavior, destructor must make sure destructing it once is enough.
In another word, destructor must succeed to the language. Object destruction
actually magnifies the effect of common ignorance of the implicitly created
rollback function (or a design).... The program execution from return/throw/
exit.. to its caller(e.g. main, init..) shall succeed.

const member functions:
Const members describe the property of the class. Normally, these members
should be in O(1) complexity. And, if properties of two objects are equal,
the objects should behave the same.

Reset(..) members:
Reset members brings the object from responsible state back to random state
and then does whatever the argument corresponding constructor does.
Therefore, If a reset member exists then the argument(s) corresponding
constructor also exists.

Construct/destruct/reset are implemented as composite operations of object
initialization process of the life cycle view (and the symmetrical reverse).
Implementation can optimize the theoretical sequence.

Since this library adopts an implicit rule that object has to be in a 'valid'
state (no good in class Array), the reset() postcondition is thus required to
be default. Default state is among the easiest check points to ensure object
constructed, in whatever valid state it may be, can always be successfully
destructed. Note that reset members normally exist but not necessary. For
instance, if the class contains const or reference data members, then the
reset would be difficult to implement.

Move Constructor:
The motivation of devising is from the need to avoid costly and unnecessary
copy operations found in classes that contain allocated resources and the
objects movement in a dynamic array. It has been practiced that such
motivation basically just need a *move constructor*. This library uses
"enum ByMove_t { ByMove }" as the signature denoting a move constructor (for
the moment), which is defined to move the source referenced object to 'this'
pointed address (source object is treated non-existent). The reason is that
such an operation is conceptually elementary, thus can enable the definition
of a no-throw swap function template (note: implementation needs a buffer
type, e.g. type_store<T>, but this is a different issue).

Many other libraries do not contain the move constructor. Bit-wise copy
(memcpy) may mostly do the job, e.g. QString of Qt library, so far. Just
make sure that destructor of the moved object won't be called.

Note: C++11 introduced rv-reference and defined another name 'std::move',
a constructor taking a rv-reference argument is therefore called a move
constructor. This library decided to continue the development using this now
standard-confusing move constructor. Simply because ByMove is relatively
more elementary. Many reasons can eventually be translated to being light
weight, which in a way means it can transform easier. Again, This library's
guide "No room should be left for lower-level implement". Another reason is
the ratio of gain v.s. cost does not appear good for the author to use it,
hopefully this library can survive.

-------- Class member rules
Let T denote a given class of this library. The following member names
and associated functionality are defined.

T() Default constructor. The object thus construted is referred
to as in default state and so the default object.

Postcondition of throw: object does not exist.

Note: If object can mean 'no real contents', the default object is
better thus designed, at least to be safely destructable.

Errno reset(...)
Reconstruct the object to the state as constructed.
If reset(..) defined, there exists the argument corresponding
constructor (reset() usually exists)

Ex: reset members should function identical to the following
example:
Errno T::reset(Type1 a, Type2 b) try {
T obj(a,b);
swap(*this,obj);
return Ok;
}
catch(const Errno& e) {
return e;
};

Note: This rule is important. Real practice may want do things
slightly different in some cases, but no, hidden, hard to find
bugs may exist.
Note: For reset() (no argument), object return state (and Reply) is
always default.

~T Destruct object

Postcondition: object does not exist

bool is_default() const
return true iff object is equivalent to the default constructed
object (i.e a.is_default() <==> a==T(), if operator== is defined).

bool operator==(const T& rhs) const
This function returns true iff *this and rhs are not
distinguishable by using any non-private member on the same
condition unless otherwise explicitly specified.

Note: Object equivalence does not include equivalence of SLI and
address of its own.

T& operator=(const T&)
Reconstruct object to the state as the copy constructor constructed
(same as reset(const T&) except the return type and throwing error).

void swap(&T)
Exchange object state of *this and the argument indicated object.

Take 'a.swap(b)' (commutative) for instance, the state of a is set
to the state of b. The previous state of a becomes the state of b.
The same applies for b

Note: No construct and destruct semantics involved

Reply
Class specific throw class inherited from Wy::Errno.

_.. prefix for system-specific members or candidate, or restricted

wy_.. prefix for internal members (for test codes, etc.).

------

Re: OOD idea of C++ and class coding guide lines

<fc5bec45-71f3-47f1-964e-d90d8ca8bbf5n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=573&group=comp.lang.c%2B%2B#573

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a0c:ef52:0:b0:635:90c4:c851 with SMTP id t18-20020a0cef52000000b0063590c4c851mr23971qvs.0.1688282866474;
Sun, 02 Jul 2023 00:27:46 -0700 (PDT)
X-Received: by 2002:a05:6a00:2e0e:b0:666:e42c:d5ec with SMTP id
fc14-20020a056a002e0e00b00666e42cd5ecmr9026794pfb.3.1688282866103; Sun, 02
Jul 2023 00:27:46 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Sun, 2 Jul 2023 00:27:45 -0700 (PDT)
In-Reply-To: <4ebc633e-2dbd-4c5d-b9d1-45101d781c4dn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=0Ek0TQoAAAAS0oceh95IuNV59QuIWNeN
NNTP-Posting-Host: 124.218.76.41
References: <4ebc633e-2dbd-4c5d-b9d1-45101d781c4dn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <fc5bec45-71f3-47f1-964e-d90d8ca8bbf5n@googlegroups.com>
Subject: Re: OOD idea of C++ and class coding guide lines
From: wynii...@gmail.com (wij)
Injection-Date: Sun, 02 Jul 2023 07:27:46 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 10274
 by: wij - Sun, 2 Jul 2023 07:27 UTC

On Wednesday, June 28, 2023 at 4:36:40 PM UTC+8, wij wrote:
> The following are rewrite of my 20-years old coding guide lines. I'd like to
> ask for suggestions to refine in the way because one reason is that recently
> the many questions I saw in this forum are actually rooted in class design
> problems (or problems of being too expressive, arbitrary).
>
> ------
> I think one major feature C++ provides is the support (or restriction) of
> Object-oriented Design. From the wiki https://en.wikipedia.org/wiki/Object-oriented_design
> or others, the definition is a bit difficult to be practically applicable.. And
> the 'isa' part ideal of OOD I knew didn't properly work.
>
> In addition, C++ class actually works by 'semantics' (or convention) which is
> not mentioned anywhere (E.g. default constructor,copy constructor and operator=).
> Thus, the following guide lines are defined (exceptions are few):
>
> Constructor(..):
> Constructor forms are in basic the Cartesian product view of problem domain
> in tupple. IOW, the arguments of ctors define the class (concept).
> Constructor brings an object in random state to responsible state.
>
> Destructor:
> The destructed object is no longer considered existing in the C++ language
> (ref. [12.4.14]). Since destructing an object the second time results to
> undefined behavior, destructor must make sure destructing it once is enough.
> In another word, destructor must succeed to the language. Object destruction
> actually magnifies the effect of common ignorance of the implicitly created
> rollback function (or a design).... The program execution from return/throw/
> exit.. to its caller(e.g. main, init..) shall succeed.
>
> const member functions:
> Const members describe the property of the class. Normally, these members
> should be in O(1) complexity. And, if properties of two objects are equal,
> the objects should behave the same.
>
> Reset(..) members:
> Reset members brings the object from responsible state back to random state
> and then does whatever the argument corresponding constructor does.
> Therefore, If a reset member exists then the argument(s) corresponding
> constructor also exists.
>
> Construct/destruct/reset are implemented as composite operations of object
> initialization process of the life cycle view (and the symmetrical reverse).
> Implementation can optimize the theoretical sequence.
>
> Since this library adopts an implicit rule that object has to be in a 'valid'
> state (no good in class Array), the reset() postcondition is thus required to
> be default. Default state is among the easiest check points to ensure object
> constructed, in whatever valid state it may be, can always be successfully
> destructed. Note that reset members normally exist but not necessary. For
> instance, if the class contains const or reference data members, then the
> reset would be difficult to implement.
>
> Move Constructor:
> The motivation of devising is from the need to avoid costly and unnecessary
> copy operations found in classes that contain allocated resources and the
> objects movement in a dynamic array. It has been practiced that such
> motivation basically just need a *move constructor*. This library uses
> "enum ByMove_t { ByMove }" as the signature denoting a move constructor (for
> the moment), which is defined to move the source referenced object to 'this'
> pointed address (source object is treated non-existent). The reason is that
> such an operation is conceptually elementary, thus can enable the definition
> of a no-throw swap function template (note: implementation needs a buffer
> type, e.g. type_store<T>, but this is a different issue).
>
> Many other libraries do not contain the move constructor. Bit-wise copy
> (memcpy) may mostly do the job, e.g. QString of Qt library, so far. Just
> make sure that destructor of the moved object won't be called.
>
> Note: C++11 introduced rv-reference and defined another name 'std::move',
> a constructor taking a rv-reference argument is therefore called a move
> constructor. This library decided to continue the development using this now
> standard-confusing move constructor. Simply because ByMove is relatively
> more elementary. Many reasons can eventually be translated to being light
> weight, which in a way means it can transform easier. Again, This library's
> guide "No room should be left for lower-level implement". Another reason is
> the ratio of gain v.s. cost does not appear good for the author to use it,
> hopefully this library can survive.
>
> -------- Class member rules
> Let T denote a given class of this library. The following member names
> and associated functionality are defined.
>
> T() Default constructor. The object thus construted is referred
> to as in default state and so the default object.
>
> Postcondition of throw: object does not exist.
>
> Note: If object can mean 'no real contents', the default object is
> better thus designed, at least to be safely destructable.
>
> Errno reset(...)
> Reconstruct the object to the state as constructed.
> If reset(..) defined, there exists the argument corresponding
> constructor (reset() usually exists)
>
> Ex: reset members should function identical to the following
> example:
> Errno T::reset(Type1 a, Type2 b) try {
> T obj(a,b);
> swap(*this,obj);
> return Ok;
> }
> catch(const Errno& e) {
> return e;
> };
>
> Note: This rule is important. Real practice may want do things
> slightly different in some cases, but no, hidden, hard to find
> bugs may exist.
> Note: For reset() (no argument), object return state (and Reply) is
> always default.
>
> ~T Destruct object
>
> Postcondition: object does not exist
>
> bool is_default() const
> return true iff object is equivalent to the default constructed
> object (i.e a.is_default() <==> a==T(), if operator== is defined).
>
> bool operator==(const T& rhs) const
> This function returns true iff *this and rhs are not
> distinguishable by using any non-private member on the same
> condition unless otherwise explicitly specified.
>
> Note: Object equivalence does not include equivalence of SLI and
> address of its own.
>
> T& operator=(const T&)
> Reconstruct object to the state as the copy constructor constructed
> (same as reset(const T&) except the return type and throwing error).
>
> void swap(&T)
> Exchange object state of *this and the argument indicated object.
>
> Take 'a.swap(b)' (commutative) for instance, the state of a is set
> to the state of b. The previous state of a becomes the state of b.
> The same applies for b
>
> Note: No construct and destruct semantics involved
>
> Reply
> Class specific throw class inherited from Wy::Errno.
>
> _.. prefix for system-specific members or candidate, or restricted
>
> wy_.. prefix for internal members (for test codes, etc.).
>
> ------

I was noticed C++ has its (language?) guidelines:
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
Lots of 'vision' and talks (contradictory) in the CppCoreGuidelines, but I
admit the fact that stdc++ faces lots more challenge than I can handle.
libwy focuses on OO way of problem solving, the implement is not relatively so
important (stdc++ is same, not really the fast kind of 'efficiency'), the result
might be paving the road for a new language.

Comparing libwy with the standard library, the prominent differences are:

Stream I/O:
libwy relies on 'syscalls' to accomplish the goal of being a library for
system programming (stdc++ seems to have abandoned this goal). And, the
guideline "No room should be left for lower-level implement" found in Bjarne
Stroustrup's book is realized in this way.

Error handling:
libwy uses Errno (and macros containing __FILE__, __LINE__ to indicate 'where')
for returning and throwing error report. Because, 'devising errors' has many
realistic problems (ref. the evolution of errno).

I think these two are already difficult for stdc++ to solve. And, a nearby post
reminded me that I had tried a similar idea to std::filesystem::path
https://en.cppreference.com/w/cpp/filesystem/path
....I thought if it could be satisfactorily solved like that, it would be
equivalent to that stdc++ invented a general OS.
Lots things I don't know, it seems all going back the beginning of C++.

Re: OOD idea of C++ and class coding guide lines

<d7797b83-4c9f-422a-b1e4-ab7ac5151782n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=598&group=comp.lang.c%2B%2B#598

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a0c:f9c6:0:b0:635:ef17:c453 with SMTP id j6-20020a0cf9c6000000b00635ef17c453mr89612qvo.2.1688401928596;
Mon, 03 Jul 2023 09:32:08 -0700 (PDT)
X-Received: by 2002:a17:902:7404:b0:1b3:edae:882b with SMTP id
g4-20020a170902740400b001b3edae882bmr8366643pll.12.1688401928227; Mon, 03 Jul
2023 09:32:08 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Mon, 3 Jul 2023 09:32:07 -0700 (PDT)
In-Reply-To: <fc5bec45-71f3-47f1-964e-d90d8ca8bbf5n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=0Ek0TQoAAAAS0oceh95IuNV59QuIWNeN
NNTP-Posting-Host: 124.218.76.41
References: <4ebc633e-2dbd-4c5d-b9d1-45101d781c4dn@googlegroups.com> <fc5bec45-71f3-47f1-964e-d90d8ca8bbf5n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d7797b83-4c9f-422a-b1e4-ab7ac5151782n@googlegroups.com>
Subject: Re: OOD idea of C++ and class coding guide lines
From: wynii...@gmail.com (wij)
Injection-Date: Mon, 03 Jul 2023 16:32:08 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 9593
 by: wij - Mon, 3 Jul 2023 16:32 UTC

The following is the updated guideline (file ClassGuideLines.txt), posted for
review. Subtleness is there, don't be fooled by simplicity.

----- ClassGuideLines.txt

This file updates the class guideline in Rationale.txt
The guideline focuses on the OO way of class (concept) design, and is made to
ensure that the class (concept) design is provably consistent.

+----------------------------------------------------------+
| Sequence of acquisition incident: Object life cycle view |
+----------------------------------------------------------+
1. Name binding
(there might be anonymous object)
2. Size binding
Information to allocate memory
3. Address binding
Object in this stage is called in random state.
4. Semantics binding
Object is in responsible state of the occupied space and contents.
(external resource may be associated in the semantics)
5. Reversal is the object destruct process

Note: Class of objects whose destructor can be runtime ignored is referred
to as discardable in this library. Often, such class has no user
defined destructor and such objects can be overwritten.

----Result of the life cycle view is the basic rule of class members

Constructor(..):
Constructor forms are in basic the Cartesian product view of problem domain
in tupple. IOW, the class (concept) is defined by the arguments of ctor.
Constructor brings an object in random state to responsible state.

Destructor:
The destructed object is no longer considered existing in the C++ language
(ref. [12.4.14]). Since destructing an object the second time results to
undefined behavior, destructor must make sure destructing it once is enough.
In another word, destructor must succeed to the language. Object destruction
actually magnifies the effect of common ignorance of the implicitly created
rollback function (or a design).... The program execution from return/throw/
exit.. to its caller(e.g. main, init..) shall succeed.

Note: C++ language had enforced the semantics that 'destructor must succeed'.

const member functions:
Const members define the property of the class. Normally, these 'property'
members should be in O(1) complexity. If properties of two objects are equal,
the objects should behave the same.
These members provide the basic proofs that the class is properly designed.

Reset(..) members:
Reset members brings the object from responsible state back to random state
and then does whatever the argument corresponding constructor does.
Therefore, If a reset member exists then the argument(s) corresponding
constructor also exists.

Construct/destruct/reset are implemented as composite operations of object
initialization process of the life cycle view (and the symmetrical reverse).
Implementation can optimize the theoretical sequence.

Since this library adopts an implicit rule that object has to be in a 'valid'
state (no good in class like Array), the reset() postcondition is thus
required to be default. Default state is among the easiest check points to
ensure object constructed, in whatever valid state, can always be
successfully destructed. Note that reset members normally exist but not
necessary. For instance, if the class contains const or reference data
members, then the reset would be difficult to implement.

Move Constructor:
The motivation of devising is from the need to avoid costly and unnecessary
copy operations found in classes that contain allocated resources and the
objects movement in a dynamic array. It has been practiced that such
motivation basically just need a *move constructor*. This library uses
"enum ByMove_t { ByMove }" as the signature denoting a move constructor (for
the moment), which is defined to move the source referenced object to 'this'
pointed address (source object is treated non-existent). The reason is that
such an operation is conceptually elementary, thus, it can enable the
definition of a no-throw swap function template (note: implementation needs
a buffer type, e.g. type_store<T>, but this is a different issue).

Many other libraries do not contain the move constructor. Bit-wise copy
(memcpy) may mostly do the job, e.g. QString of Qt library, so far. Just
make sure that destructor of the moved object won't be called.

Note: C++11 introduced rv-reference and defined another name 'std::move',
a constructor taking a rv-reference argument is therefore called a move
constructor. This library decided to continue the development using this now
standard-confusing move constructor. Simply because ByMove is relatively
more elementary. Many reasons can eventually be translated to being light
weight, which in a way means it can transform easier. Again, This library's
guide "No room should be left for lower-level implement". Another reason is
the ratio of gain vs. cost does not appear good for the author to use it,
hopefully this library can survive.

-------- Class member rules
The general rule: Class members should be able to conduct self-check for
correctness, except not possible.

Let T denote a given class of this library. The following member names
and associated functionality are defined.

T() Default constructor. The object thus construted is referred
to as in default state and so the default object.

Postcondition of throw: object does not exist.

Note: If object can mean 'no real contents', the default object is
better thus designed, at least to be safely destructable.

T(const T&) Construct *this to the state as the source object.
(nothing more to say from general practice)
T(T&, ByMove_t) Move the source object to 'this' pointed address.
This member is not really a constructor since nothing is created.

Errno reset(...)
Reconstruct the object to the state as constructed by the arguments
corresponding constructor.

Ex: reset members should ideally function identical to the following
example:
Errno T::reset(Type1 a, Type2 b) try {
T obj(a,b);
swap(*this,obj);
return Ok;
}
catch(const Errno& e) {
return e;
};

Note: This rule is important. Real practice may want do things
slightly different in some cases, but no. Hidden and hard to
find bugs may exist (maybe the concept or interface of the
class design should be reconsidered).
Note: For reset() (no argument), object return (and Reply) state is
always default regardless of the Errno, if exists, returned.

~T Destruct object

Postcondition: object does not exist

bool is_default() const
return true iff object is equivalent to the default constructed
object (i.e a.is_default() <==> a==T(), if operator== is defined).

bool operator==(const T& rhs) const
This function returns true iff *this and rhs are not distinguishable
by using any non-private member on the same condition unless
otherwise explicitly specified.

Note: Object equivalence does not include equivalence of SLI and
address of its own.

T& operator=(const T&)
Reconstruct object to the state as the copy constructor constructed
(same as reset(const T&) except the return type and throwing error).

void swap(&T)
Exchange object state of *this and the argument indicated object.

Take 'a.swap(b)' (commutative) for instance, the state of a is set
to the state of b. The previous state of a becomes the state of b.
The same applies for b

Note: No construct and destruct semantics is involved

Reply
Class specific throw class inheriting Errno.

_.. prefix for system-specific members or candidate, or restricted..etc.

wy_.. prefix for internal members (for testing, etc.).

------

Re: OOD idea of C++ and class coding guide lines

<5099e453-bf3f-4935-8177-52c7f9978a00n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=753&group=comp.lang.c%2B%2B#753

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:622a:18a3:b0:3fd:e74b:3194 with SMTP id v35-20020a05622a18a300b003fde74b3194mr37574qtc.2.1688916545209;
Sun, 09 Jul 2023 08:29:05 -0700 (PDT)
X-Received: by 2002:a65:6a84:0:b0:55b:1e0e:d278 with SMTP id
q4-20020a656a84000000b0055b1e0ed278mr7254248pgu.1.1688916544571; Sun, 09 Jul
2023 08:29:04 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Sun, 9 Jul 2023 08:29:03 -0700 (PDT)
In-Reply-To: <d7797b83-4c9f-422a-b1e4-ab7ac5151782n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=0Ek0TQoAAAAS0oceh95IuNV59QuIWNeN
NNTP-Posting-Host: 124.218.76.41
References: <4ebc633e-2dbd-4c5d-b9d1-45101d781c4dn@googlegroups.com>
<fc5bec45-71f3-47f1-964e-d90d8ca8bbf5n@googlegroups.com> <d7797b83-4c9f-422a-b1e4-ab7ac5151782n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <5099e453-bf3f-4935-8177-52c7f9978a00n@googlegroups.com>
Subject: Re: OOD idea of C++ and class coding guide lines
From: wynii...@gmail.com (wij)
Injection-Date: Sun, 09 Jul 2023 15:29:05 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 11483
 by: wij - Sun, 9 Jul 2023 15:29 UTC

On Tuesday, July 4, 2023 at 12:32:17 AM UTC+8, wij wrote:
> The following is the updated guideline (file ClassGuideLines.txt), posted for
> review. Subtleness is there, don't be fooled by simplicity.
>
> ----- ClassGuideLines.txt
>
> This file updates the class guideline in Rationale.txt
> The guideline focuses on the OO way of class (concept) design, and is made to
> ensure that the class (concept) design is provably consistent.
>
> +----------------------------------------------------------+
> | Sequence of acquisition incident: Object life cycle view |
> +----------------------------------------------------------+
> 1. Name binding
> (there might be anonymous object)
> 2. Size binding
> Information to allocate memory
> 3. Address binding
> Object in this stage is called in random state.
> 4. Semantics binding
> Object is in responsible state of the occupied space and contents.
> (external resource may be associated in the semantics)
> 5. Reversal is the object destruct process
>
> Note: Class of objects whose destructor can be runtime ignored is referred
> to as discardable in this library. Often, such class has no user
> defined destructor and such objects can be overwritten.
>
> ----Result of the life cycle view is the basic rule of class members
> Constructor(..):
> Constructor forms are in basic the Cartesian product view of problem domain
> in tupple. IOW, the class (concept) is defined by the arguments of ctor.
> Constructor brings an object in random state to responsible state.
>
> Destructor:
> The destructed object is no longer considered existing in the C++ language
> (ref. [12.4.14]). Since destructing an object the second time results to
> undefined behavior, destructor must make sure destructing it once is enough.
> In another word, destructor must succeed to the language. Object destruction
> actually magnifies the effect of common ignorance of the implicitly created
> rollback function (or a design).... The program execution from return/throw/
> exit.. to its caller(e.g. main, init..) shall succeed.
> Note: C++ language had enforced the semantics that 'destructor must succeed'.
>
> const member functions:
> Const members define the property of the class. Normally, these 'property'
> members should be in O(1) complexity. If properties of two objects are equal,
> the objects should behave the same.
> These members provide the basic proofs that the class is properly designed.
> Reset(..) members:
> Reset members brings the object from responsible state back to random state
> and then does whatever the argument corresponding constructor does.
> Therefore, If a reset member exists then the argument(s) corresponding
> constructor also exists.
>
> Construct/destruct/reset are implemented as composite operations of object
> initialization process of the life cycle view (and the symmetrical reverse).
> Implementation can optimize the theoretical sequence.
>
> Since this library adopts an implicit rule that object has to be in a 'valid'
> state (no good in class like Array), the reset() postcondition is thus
> required to be default. Default state is among the easiest check points to
> ensure object constructed, in whatever valid state, can always be
> successfully destructed. Note that reset members normally exist but not
> necessary. For instance, if the class contains const or reference data
> members, then the reset would be difficult to implement.
>
> Move Constructor:
> The motivation of devising is from the need to avoid costly and unnecessary
> copy operations found in classes that contain allocated resources and the
> objects movement in a dynamic array. It has been practiced that such
> motivation basically just need a *move constructor*. This library uses
> "enum ByMove_t { ByMove }" as the signature denoting a move constructor (for
> the moment), which is defined to move the source referenced object to 'this'
> pointed address (source object is treated non-existent). The reason is that
> such an operation is conceptually elementary, thus, it can enable the
> definition of a no-throw swap function template (note: implementation needs
> a buffer type, e.g. type_store<T>, but this is a different issue).
>
> Many other libraries do not contain the move constructor. Bit-wise copy
> (memcpy) may mostly do the job, e.g. QString of Qt library, so far. Just
> make sure that destructor of the moved object won't be called.
>
> Note: C++11 introduced rv-reference and defined another name 'std::move',
> a constructor taking a rv-reference argument is therefore called a move
> constructor. This library decided to continue the development using this now
> standard-confusing move constructor. Simply because ByMove is relatively
> more elementary. Many reasons can eventually be translated to being light
> weight, which in a way means it can transform easier. Again, This library's
> guide "No room should be left for lower-level implement". Another reason is
> the ratio of gain vs. cost does not appear good for the author to use it,
> hopefully this library can survive.
>
> -------- Class member rules
> The general rule: Class members should be able to conduct self-check for
> correctness, except not possible.
> Let T denote a given class of this library. The following member names
> and associated functionality are defined.
>
> T() Default constructor. The object thus construted is referred
> to as in default state and so the default object.
>
> Postcondition of throw: object does not exist.
>
> Note: If object can mean 'no real contents', the default object is
> better thus designed, at least to be safely destructable.
> T(const T&) Construct *this to the state as the source object.
> (nothing more to say from general practice)
> T(T&, ByMove_t) Move the source object to 'this' pointed address.
> This member is not really a constructor since nothing is created.
>
> Errno reset(...)
> Reconstruct the object to the state as constructed by the arguments
> corresponding constructor.
>
> Ex: reset members should ideally function identical to the following
> example:
> Errno T::reset(Type1 a, Type2 b) try {
> T obj(a,b);
> swap(*this,obj);
> return Ok;
> }
> catch(const Errno& e) {
> return e;
> };
>
> Note: This rule is important. Real practice may want do things
> slightly different in some cases, but no. Hidden and hard to
> find bugs may exist (maybe the concept or interface of the
> class design should be reconsidered).
> Note: For reset() (no argument), object return (and Reply) state is
> always default regardless of the Errno, if exists, returned.
> ~T Destruct object
>
> Postcondition: object does not exist
>
> bool is_default() const
> return true iff object is equivalent to the default constructed
> object (i.e a.is_default() <==> a==T(), if operator== is defined).
>
> bool operator==(const T& rhs) const
> This function returns true iff *this and rhs are not distinguishable
> by using any non-private member on the same condition unless
> otherwise explicitly specified.
>
> Note: Object equivalence does not include equivalence of SLI and
> address of its own.
>
> T& operator=(const T&)
> Reconstruct object to the state as the copy constructor constructed
> (same as reset(const T&) except the return type and throwing error).
>
> void swap(&T)
> Exchange object state of *this and the argument indicated object.
>
> Take 'a.swap(b)' (commutative) for instance, the state of a is set
> to the state of b. The previous state of a becomes the state of b.
> The same applies for b
> Note: No construct and destruct semantics is involved
>
> Reply
> Class specific throw class inheriting Errno.
>
> _.. prefix for system-specific members or candidate, or restricted..etc.
>
> wy_.. prefix for internal members (for testing, etc.).
>
> ------

A section about throwing error is added to libwy guidelines, posted for review.

-------- Throwing error
As an elementary library, libwy has to make any error report of provided
functions be able properly handled by its caller to accomplish the function
requested and don't create exception.
Throwing error loses the context information. FUNCTIONS (and ctor/dtor/..) SHOULD
CATCH ALL CONFUSING ERRORS THROWN TO CONVERT TO THE ONE IT IS RESPONSIBLE.
Difficulty exists to achieve this requirement especially for template classes,
therefore, libwy should minimize using template in general (Array<T> seems to
defy this rule...).


Click here to read the complete article
Re: OOD idea of C++ and class coding guide lines

<u8ekkn$25o8q$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=756&group=comp.lang.c%2B%2B#756

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: eesn...@osa.pri.ee (Paavo Helde)
Newsgroups: comp.lang.c++
Subject: Re: OOD idea of C++ and class coding guide lines
Date: Sun, 9 Jul 2023 18:44:22 +0300
Organization: A noiseless patient Spider
Lines: 19
Message-ID: <u8ekkn$25o8q$1@dont-email.me>
References: <4ebc633e-2dbd-4c5d-b9d1-45101d781c4dn@googlegroups.com>
<fc5bec45-71f3-47f1-964e-d90d8ca8bbf5n@googlegroups.com>
<d7797b83-4c9f-422a-b1e4-ab7ac5151782n@googlegroups.com>
<5099e453-bf3f-4935-8177-52c7f9978a00n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 9 Jul 2023 15:44:23 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="e49aac112e5fa0e93477a37b56e70940";
logging-data="2285850"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+M/1QL0wTMYqfBDeOLXVyMZIStinxfvpM="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.12.0
Cancel-Lock: sha1:rZvR0r57rIxEj5lhoEm8m1vljTA=
Content-Language: en-US
In-Reply-To: <5099e453-bf3f-4935-8177-52c7f9978a00n@googlegroups.com>
 by: Paavo Helde - Sun, 9 Jul 2023 15:44 UTC

09.07.2023 18:29 wij kirjutas:
> +--------------------------+
> | Appendix: Losing Context |
> +--------------------------+
> The error thrown may not associate to the function being called.
>
> int read_integer(size_t maxlen) {
> int v;
> if(maxlen>10) {
> throw Invalid_Argument;

I can see now what you mean by "losing context". It has never occurred
to me to throw such meaningless exceptions. Try something like this instead:

throw std::runtime_error(
"Invalid parameter maxlen=" +
std::to_string(maxlen) +
" passed to read_integer(), the value must be not larger than 10");

Re: OOD idea of C++ and class coding guide lines

<f18adf44-1667-4bfb-b64d-31aca0eae5cen@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=757&group=comp.lang.c%2B%2B#757

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:6214:5642:b0:637:1cb0:679e with SMTP id mh2-20020a056214564200b006371cb0679emr34228qvb.0.1688918573264;
Sun, 09 Jul 2023 09:02:53 -0700 (PDT)
X-Received: by 2002:a17:903:2149:b0:1b6:a2e4:c8f8 with SMTP id
s9-20020a170903214900b001b6a2e4c8f8mr8795164ple.2.1688918572915; Sun, 09 Jul
2023 09:02:52 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Sun, 9 Jul 2023 09:02:52 -0700 (PDT)
In-Reply-To: <u8ekkn$25o8q$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=0Ek0TQoAAAAS0oceh95IuNV59QuIWNeN
NNTP-Posting-Host: 124.218.76.41
References: <4ebc633e-2dbd-4c5d-b9d1-45101d781c4dn@googlegroups.com>
<fc5bec45-71f3-47f1-964e-d90d8ca8bbf5n@googlegroups.com> <d7797b83-4c9f-422a-b1e4-ab7ac5151782n@googlegroups.com>
<5099e453-bf3f-4935-8177-52c7f9978a00n@googlegroups.com> <u8ekkn$25o8q$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <f18adf44-1667-4bfb-b64d-31aca0eae5cen@googlegroups.com>
Subject: Re: OOD idea of C++ and class coding guide lines
From: wynii...@gmail.com (wij)
Injection-Date: Sun, 09 Jul 2023 16:02:53 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 2247
 by: wij - Sun, 9 Jul 2023 16:02 UTC

On Sunday, July 9, 2023 at 11:44:39 PM UTC+8, Paavo Helde wrote:
> 09.07.2023 18:29 wij kirjutas:
> > +--------------------------+
> > | Appendix: Losing Context |
> > +--------------------------+
> > The error thrown may not associate to the function being called.
> >
> > int read_integer(size_t maxlen) {
> > int v;
> > if(maxlen>10) {
> > throw Invalid_Argument;
> I can see now what you mean by "losing context". It has never occurred
> to me to throw such meaningless exceptions. Try something like this instead:
>
> throw std::runtime_error(
> "Invalid parameter maxlen=" +
> std::to_string(maxlen) +
> " passed to read_integer(), the value must be not larger than 10");

Your brain is stuffed by stdc++'s lie.
"Losing Context" means it is DOOMED in C++ language. All the user can do is
working around.

Re: OOD idea of C++ and class coding guide lines

<d432a81d-5285-42fa-b8ed-0a85bfdd3277n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=758&group=comp.lang.c%2B%2B#758

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:620a:4688:b0:762:1b2f:ec53 with SMTP id bq8-20020a05620a468800b007621b2fec53mr42673qkb.7.1688918953786;
Sun, 09 Jul 2023 09:09:13 -0700 (PDT)
X-Received: by 2002:a17:902:da92:b0:1b8:184d:1379 with SMTP id
j18-20020a170902da9200b001b8184d1379mr10296904plx.9.1688918953210; Sun, 09
Jul 2023 09:09:13 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Sun, 9 Jul 2023 09:09:12 -0700 (PDT)
In-Reply-To: <f18adf44-1667-4bfb-b64d-31aca0eae5cen@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=0Ek0TQoAAAAS0oceh95IuNV59QuIWNeN
NNTP-Posting-Host: 124.218.76.41
References: <4ebc633e-2dbd-4c5d-b9d1-45101d781c4dn@googlegroups.com>
<fc5bec45-71f3-47f1-964e-d90d8ca8bbf5n@googlegroups.com> <d7797b83-4c9f-422a-b1e4-ab7ac5151782n@googlegroups.com>
<5099e453-bf3f-4935-8177-52c7f9978a00n@googlegroups.com> <u8ekkn$25o8q$1@dont-email.me>
<f18adf44-1667-4bfb-b64d-31aca0eae5cen@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d432a81d-5285-42fa-b8ed-0a85bfdd3277n@googlegroups.com>
Subject: Re: OOD idea of C++ and class coding guide lines
From: wynii...@gmail.com (wij)
Injection-Date: Sun, 09 Jul 2023 16:09:13 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 2453
 by: wij - Sun, 9 Jul 2023 16:09 UTC

On Monday, July 10, 2023 at 12:03:03 AM UTC+8, wij wrote:
> On Sunday, July 9, 2023 at 11:44:39 PM UTC+8, Paavo Helde wrote:
> > 09.07.2023 18:29 wij kirjutas:
> > > +--------------------------+
> > > | Appendix: Losing Context |
> > > +--------------------------+
> > > The error thrown may not associate to the function being called.
> > >
> > > int read_integer(size_t maxlen) {
> > > int v;
> > > if(maxlen>10) {
> > > throw Invalid_Argument;
> > I can see now what you mean by "losing context". It has never occurred
> > to me to throw such meaningless exceptions. Try something like this instead:
> >
> > throw std::runtime_error(
> > "Invalid parameter maxlen=" +
> > std::to_string(maxlen) +
> > " passed to read_integer(), the value must be not larger than 10");
> Your brain is stuffed by stdc++'s lie.
> "Losing Context" means it is DOOMED in C++ language. All the user can do is
> working around.

Re: OOD idea of C++ and class coding guide lines

<127be2df-c6d9-4fb9-ab1b-7fc6424d4857n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=759&group=comp.lang.c%2B%2B#759

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:620a:4544:b0:762:42ca:9197 with SMTP id u4-20020a05620a454400b0076242ca9197mr26470qkp.11.1688919145482;
Sun, 09 Jul 2023 09:12:25 -0700 (PDT)
X-Received: by 2002:a63:33c7:0:b0:530:3a44:1581 with SMTP id
z190-20020a6333c7000000b005303a441581mr7379138pgz.9.1688919145181; Sun, 09
Jul 2023 09:12:25 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Sun, 9 Jul 2023 09:12:24 -0700 (PDT)
In-Reply-To: <f18adf44-1667-4bfb-b64d-31aca0eae5cen@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=0Ek0TQoAAAAS0oceh95IuNV59QuIWNeN
NNTP-Posting-Host: 124.218.76.41
References: <4ebc633e-2dbd-4c5d-b9d1-45101d781c4dn@googlegroups.com>
<fc5bec45-71f3-47f1-964e-d90d8ca8bbf5n@googlegroups.com> <d7797b83-4c9f-422a-b1e4-ab7ac5151782n@googlegroups.com>
<5099e453-bf3f-4935-8177-52c7f9978a00n@googlegroups.com> <u8ekkn$25o8q$1@dont-email.me>
<f18adf44-1667-4bfb-b64d-31aca0eae5cen@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <127be2df-c6d9-4fb9-ab1b-7fc6424d4857n@googlegroups.com>
Subject: Re: OOD idea of C++ and class coding guide lines
From: wynii...@gmail.com (wij)
Injection-Date: Sun, 09 Jul 2023 16:12:25 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 2528
 by: wij - Sun, 9 Jul 2023 16:12 UTC

On Monday, July 10, 2023 at 12:03:03 AM UTC+8, wij wrote:
> On Sunday, July 9, 2023 at 11:44:39 PM UTC+8, Paavo Helde wrote:
> > 09.07.2023 18:29 wij kirjutas:
> > > +--------------------------+
> > > | Appendix: Losing Context |
> > > +--------------------------+
> > > The error thrown may not associate to the function being called.
> > >
> > > int read_integer(size_t maxlen) {
> > > int v;
> > > if(maxlen>10) {
> > > throw Invalid_Argument;
> > I can see now what you mean by "losing context". It has never occurred
> > to me to throw such meaningless exceptions. Try something like this instead:
> >
> > throw std::runtime_error(
> > "Invalid parameter maxlen=" +
> > std::to_string(maxlen) +
> > " passed to read_integer(), the value must be not larger than 10");
> Your brain is stuffed by stdc++'s lie.
> "Losing Context" means it is DOOMED in C++ language. All the user can do is
> working around.

Throwing std::runtime_error is like signaling a global object is updated.

Re: OOD idea of C++ and class coding guide lines

<3dd1b6bc-8681-4de4-b551-2eb5f063142en@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=760&group=comp.lang.c%2B%2B#760

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:6214:8ef:b0:635:fa5d:cb8d with SMTP id dr15-20020a05621408ef00b00635fa5dcb8dmr29479qvb.13.1688925049555;
Sun, 09 Jul 2023 10:50:49 -0700 (PDT)
X-Received: by 2002:a63:3d48:0:b0:54f:d3ef:539b with SMTP id
k69-20020a633d48000000b0054fd3ef539bmr7586895pga.12.1688925049075; Sun, 09
Jul 2023 10:50:49 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Sun, 9 Jul 2023 10:50:48 -0700 (PDT)
In-Reply-To: <u8ekkn$25o8q$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=0Ek0TQoAAAAS0oceh95IuNV59QuIWNeN
NNTP-Posting-Host: 124.218.76.41
References: <4ebc633e-2dbd-4c5d-b9d1-45101d781c4dn@googlegroups.com>
<fc5bec45-71f3-47f1-964e-d90d8ca8bbf5n@googlegroups.com> <d7797b83-4c9f-422a-b1e4-ab7ac5151782n@googlegroups.com>
<5099e453-bf3f-4935-8177-52c7f9978a00n@googlegroups.com> <u8ekkn$25o8q$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <3dd1b6bc-8681-4de4-b551-2eb5f063142en@googlegroups.com>
Subject: Re: OOD idea of C++ and class coding guide lines
From: wynii...@gmail.com (wij)
Injection-Date: Sun, 09 Jul 2023 17:50:49 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 2829
 by: wij - Sun, 9 Jul 2023 17:50 UTC

On Sunday, July 9, 2023 at 11:44:39 PM UTC+8, Paavo Helde wrote:
> 09.07.2023 18:29 wij kirjutas:
> > +--------------------------+
> > | Appendix: Losing Context |
> > +--------------------------+
> > The error thrown may not associate to the function being called.
> >
> > int read_integer(size_t maxlen) {
> > int v;
> > if(maxlen>10) {
> > throw Invalid_Argument;
> I can see now what you mean by "losing context". It has never occurred
> to me to throw such meaningless exceptions. Try something like this instead:
>
> throw std::runtime_error(
> "Invalid parameter maxlen=" +
> std::to_string(maxlen) +
> " passed to read_integer(), the value must be not larger than 10");

To be specific about such coding:

throw std::runtime_error(
"Invalid parameter maxlen=" +
std::to_string(maxlen) +
" passed to read_integer(), the value must be not larger than 10");

0. Error report of a function (mostly) is made for the caller to know and handle.
In this case, owing to the context loss issue, caller of a function generally
won't be able to tell it is exactly the argument 'maxlen' causing the
problem. Such coding as the above does not make things better in the general case.
1. Error report itself has to be error free.
2. Efficiency. Many of such error reports may happen and happen frequently.
No one like to do the heavy decoding job everywhere.

Re: OOD idea of C++ and class coding guide lines

<2c15813d-6ab8-4c1d-9f2e-2e352f6c590dn@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=774&group=comp.lang.c%2B%2B#774

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:620a:258a:b0:765:ac7b:ccb3 with SMTP id x10-20020a05620a258a00b00765ac7bccb3mr32949qko.3.1689008067452;
Mon, 10 Jul 2023 09:54:27 -0700 (PDT)
X-Received: by 2002:a05:6a00:2d16:b0:677:7731:5edd with SMTP id
fa22-20020a056a002d1600b0067777315eddmr16329449pfb.0.1689008067027; Mon, 10
Jul 2023 09:54:27 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Mon, 10 Jul 2023 09:54:26 -0700 (PDT)
In-Reply-To: <3dd1b6bc-8681-4de4-b551-2eb5f063142en@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=0Ek0TQoAAAAS0oceh95IuNV59QuIWNeN
NNTP-Posting-Host: 124.218.76.41
References: <4ebc633e-2dbd-4c5d-b9d1-45101d781c4dn@googlegroups.com>
<fc5bec45-71f3-47f1-964e-d90d8ca8bbf5n@googlegroups.com> <d7797b83-4c9f-422a-b1e4-ab7ac5151782n@googlegroups.com>
<5099e453-bf3f-4935-8177-52c7f9978a00n@googlegroups.com> <u8ekkn$25o8q$1@dont-email.me>
<3dd1b6bc-8681-4de4-b551-2eb5f063142en@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <2c15813d-6ab8-4c1d-9f2e-2e352f6c590dn@googlegroups.com>
Subject: Re: OOD idea of C++ and class coding guide lines
From: wynii...@gmail.com (wij)
Injection-Date: Mon, 10 Jul 2023 16:54:27 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 5237
 by: wij - Mon, 10 Jul 2023 16:54 UTC

On Monday, July 10, 2023 at 1:50:58 AM UTC+8, wij wrote:
> On Sunday, July 9, 2023 at 11:44:39 PM UTC+8, Paavo Helde wrote:
> > 09.07.2023 18:29 wij kirjutas:
> > > +--------------------------+
> > > | Appendix: Losing Context |
> > > +--------------------------+
> > > The error thrown may not associate to the function being called.
> > >
> > > int read_integer(size_t maxlen) {
> > > int v;
> > > if(maxlen>10) {
> > > throw Invalid_Argument;
> > I can see now what you mean by "losing context". It has never occurred
> > to me to throw such meaningless exceptions. Try something like this instead:
> >
> > throw std::runtime_error(
> > "Invalid parameter maxlen=" +
> > std::to_string(maxlen) +
> > " passed to read_integer(), the value must be not larger than 10");
> To be specific about such coding:
> throw std::runtime_error(
> "Invalid parameter maxlen=" +
> std::to_string(maxlen) +
> " passed to read_integer(), the value must be not larger than 10");
> 0. Error report of a function (mostly) is made for the caller to know and handle.
> In this case, owing to the context loss issue, caller of a function generally
> won't be able to tell it is exactly the argument 'maxlen' causing the
> problem. Such coding as the above does not make things better in the general case.
> 1. Error report itself has to be error free.
> 2. Efficiency. Many of such error reports may happen and happen frequently.
> No one like to do the heavy decoding job everywhere.

A passage is added to the appendix Losing Context, of which mostly had shown.
Also, the followings are for review:

--------------------
In a metaphor, throwing error is like using the thread local errno to propagate
the error report with the enforcement that the stack will unwind if the function
in the stack frame did not check the errno. So, in the general case, caller
function has no way to know which function in the unwound path is responsible
for the errno.
----------------

The following is the appendix for C++ programmers not used to this "disguised C++ of C" programming guidelines.
+---------------------------------------------------+
| Appendix B: Possible doubt of StdC++ library user |
+---------------------------------------------------+
..Program is difficult to read: The author believes, mixed style may be the major
issue. Programmers are more often in the code review process for correctness
than exhibiting the codes. Terseness that hides details that need to guess, and
scattered source may be more of the problem to concern.

..'Less human language': The semantics of C++ language is defined ultimately by
the target assembly and recognized by CPU, not any one, no magic in this
regard. Far too human language and ideal consume effort and creates illusion
difficult to debug. Although it is possible the high level language can lead
to the invention of a new machine, but, so far, no machine can be beyond TM.
If the language wants so, do it directly. As the author understood, parallel
(muli-cpu) machine is likely still a TM or a TM with an additional random bit
source. Again, no fancy things there (Of course, proving these statement wrong
is very welcome to all, e.g. Artificial Neural Network. This is just what libwy
should say).

---------------------------------------------------------
Finally, the author (me) thinks he is probably not able to do much more to
make libwy mature, help is needed from different person. Join the project to
modify it (or, if you can do similar things by your own, notify me the project.
Or, spread the message).

Re: OOD idea of C++ and class coding guide lines

<u8hk7v$2jkd9$2@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=775&group=comp.lang.c%2B%2B#775

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: OOD idea of C++ and class coding guide lines
Date: Mon, 10 Jul 2023 11:56:00 -0700
Organization: A noiseless patient Spider
Lines: 13
Message-ID: <u8hk7v$2jkd9$2@dont-email.me>
References: <4ebc633e-2dbd-4c5d-b9d1-45101d781c4dn@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 10 Jul 2023 18:55:59 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="c3f080eb5fdb43bc44eed6a41e9c4a8c";
logging-data="2740649"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18OBAOWaUPTqDsDeEgwa15jTIHf/84hf4A="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.13.0
Cancel-Lock: sha1:Rf4T6/1Aakm6rnKY6+nYQQHC2+A=
In-Reply-To: <4ebc633e-2dbd-4c5d-b9d1-45101d781c4dn@googlegroups.com>
Content-Language: en-US
 by: Chris M. Thomasson - Mon, 10 Jul 2023 18:56 UTC

On 6/28/2023 1:36 AM, wij wrote:
> The following are rewrite of my 20-years old coding guide lines. I'd like to
> ask for suggestions to refine in the way because one reason is that recently
> the many questions I saw in this forum are actually rooted in class design
> problems (or problems of being too expressive, arbitrary).
[...]

Here are some coding guidelines for ya:

https://www.stroustrup.com/JSF-AV-rules.pdf

;^)

Re: OOD idea of C++ and class coding guide lines

<220c7ef8-31d5-4198-8624-883644c3c2f3n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=778&group=comp.lang.c%2B%2B#778

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:6214:1629:b0:635:ef76:6448 with SMTP id e9-20020a056214162900b00635ef766448mr39608qvw.6.1689023629461;
Mon, 10 Jul 2023 14:13:49 -0700 (PDT)
X-Received: by 2002:a17:903:441:b0:1b8:c666:207a with SMTP id
iw1-20020a170903044100b001b8c666207amr11985095plb.9.1689023628759; Mon, 10
Jul 2023 14:13:48 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!newsfeed.hasname.com!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Mon, 10 Jul 2023 14:13:47 -0700 (PDT)
In-Reply-To: <u8hk7v$2jkd9$2@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=0Ek0TQoAAAAS0oceh95IuNV59QuIWNeN
NNTP-Posting-Host: 124.218.76.41
References: <4ebc633e-2dbd-4c5d-b9d1-45101d781c4dn@googlegroups.com> <u8hk7v$2jkd9$2@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <220c7ef8-31d5-4198-8624-883644c3c2f3n@googlegroups.com>
Subject: Re: OOD idea of C++ and class coding guide lines
From: wynii...@gmail.com (wij)
Injection-Date: Mon, 10 Jul 2023 21:13:49 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 1920
 by: wij - Mon, 10 Jul 2023 21:13 UTC

On Tuesday, July 11, 2023 at 2:56:19 AM UTC+8, Chris M. Thomasson wrote:
> On 6/28/2023 1:36 AM, wij wrote:
> > The following are rewrite of my 20-years old coding guide lines. I'd like to
> > ask for suggestions to refine in the way because one reason is that recently
> > the many questions I saw in this forum are actually rooted in class design
> > problems (or problems of being too expressive, arbitrary).
> [...]
>
> Here are some coding guidelines for ya:
>
> https://www.stroustrup.com/JSF-AV-rules.pdf
>
> ;^)

Thanks, it looks my class member rule win! (I can provide stronger restriction).

This is one thousand bill [$1000千圓], keep the change.

Re: OOD idea of C++ and class coding guide lines

<4a157119-36b1-4c38-beb7-b512a1b313b0n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=797&group=comp.lang.c%2B%2B#797

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:622a:1ba4:b0:401:e192:fc61 with SMTP id bp36-20020a05622a1ba400b00401e192fc61mr80068qtb.7.1689119776131;
Tue, 11 Jul 2023 16:56:16 -0700 (PDT)
X-Received: by 2002:aca:b903:0:b0:3a3:6140:e021 with SMTP id
j3-20020acab903000000b003a36140e021mr3216541oif.3.1689119775875; Tue, 11 Jul
2023 16:56:15 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Tue, 11 Jul 2023 16:56:15 -0700 (PDT)
In-Reply-To: <220c7ef8-31d5-4198-8624-883644c3c2f3n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=0Ek0TQoAAAAS0oceh95IuNV59QuIWNeN
NNTP-Posting-Host: 124.218.76.41
References: <4ebc633e-2dbd-4c5d-b9d1-45101d781c4dn@googlegroups.com>
<u8hk7v$2jkd9$2@dont-email.me> <220c7ef8-31d5-4198-8624-883644c3c2f3n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <4a157119-36b1-4c38-beb7-b512a1b313b0n@googlegroups.com>
Subject: Re: OOD idea of C++ and class coding guide lines
From: wynii...@gmail.com (wij)
Injection-Date: Tue, 11 Jul 2023 23:56:16 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 3254
 by: wij - Tue, 11 Jul 2023 23:56 UTC

On Tuesday, July 11, 2023 at 5:13:59 AM UTC+8, wij wrote:
> On Tuesday, July 11, 2023 at 2:56:19 AM UTC+8, Chris M. Thomasson wrote:
> > On 6/28/2023 1:36 AM, wij wrote:
> > > The following are rewrite of my 20-years old coding guide lines. I'd like to
> > > ask for suggestions to refine in the way because one reason is that recently
> > > the many questions I saw in this forum are actually rooted in class design
> > > problems (or problems of being too expressive, arbitrary).
> > [...]
> >
> > Here are some coding guidelines for ya:
> >
> > https://www.stroustrup.com/JSF-AV-rules.pdf
> >
> > ;^)
> Thanks, it looks my class member rule win! (I can provide stronger restriction).
>
> This is one thousand bill [$1000千圓], keep the change.

As I am in the mood, so Appendix C is added. Updated wording are in
https://sourceforge.net/projects/cscall/files/MisFiles/ClassGuidelines.txt/download

+--------------------------------------------+
| Appendix C: Returning 'error' is necessary |
+--------------------------------------------+
Reusing of execution codes has two kinds, as a function or as a macro (C++
template is an advanced kind in source level). The exit points (I mean the
flowchar of machine codes, or assembly) of a function are traditionally
simplified to one point (the return address) by encoding the exit information
carried in the branch point into a return object --- the basic picture of the
original codes (the nature may be more intriguing).
So, the birth of the branch point info. carrying object and the associated cost
of space and time to encode and decode. 'error' or 'exception' is what human
thinks, it is just an information/mechanism for branching.

Control-flows between modules are similar, just have more room to play tricks.

So, libwy regards returning Errno as primitive.

Re: OOD idea of C++ and class coding guide lines

<fa6d28c2-8e23-494f-9fda-cc7c7e869e24n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=823&group=comp.lang.c%2B%2B#823

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:620a:17a1:b0:762:407d:3837 with SMTP id ay33-20020a05620a17a100b00762407d3837mr8077qkb.6.1689307542341;
Thu, 13 Jul 2023 21:05:42 -0700 (PDT)
X-Received: by 2002:a05:6830:60c:b0:6b8:8441:bc37 with SMTP id
w12-20020a056830060c00b006b88441bc37mr3291274oti.5.1689307542045; Thu, 13 Jul
2023 21:05:42 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Thu, 13 Jul 2023 21:05:41 -0700 (PDT)
In-Reply-To: <4a157119-36b1-4c38-beb7-b512a1b313b0n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=0Ek0TQoAAAAS0oceh95IuNV59QuIWNeN
NNTP-Posting-Host: 124.218.76.41
References: <4ebc633e-2dbd-4c5d-b9d1-45101d781c4dn@googlegroups.com>
<u8hk7v$2jkd9$2@dont-email.me> <220c7ef8-31d5-4198-8624-883644c3c2f3n@googlegroups.com>
<4a157119-36b1-4c38-beb7-b512a1b313b0n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <fa6d28c2-8e23-494f-9fda-cc7c7e869e24n@googlegroups.com>
Subject: Re: OOD idea of C++ and class coding guide lines
From: wynii...@gmail.com (wij)
Injection-Date: Fri, 14 Jul 2023 04:05:42 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 4475
 by: wij - Fri, 14 Jul 2023 04:05 UTC

On Wednesday, July 12, 2023 at 7:56:25 AM UTC+8, wij wrote:
> On Tuesday, July 11, 2023 at 5:13:59 AM UTC+8, wij wrote:
> > On Tuesday, July 11, 2023 at 2:56:19 AM UTC+8, Chris M. Thomasson wrote:
> > > On 6/28/2023 1:36 AM, wij wrote:
> > > > The following are rewrite of my 20-years old coding guide lines. I'd like to
> > > > ask for suggestions to refine in the way because one reason is that recently
> > > > the many questions I saw in this forum are actually rooted in class design
> > > > problems (or problems of being too expressive, arbitrary).
> > > [...]
> > >
> > > Here are some coding guidelines for ya:
> > >
> > > https://www.stroustrup.com/JSF-AV-rules.pdf
> > >
> > > ;^)
> > Thanks, it looks my class member rule win! (I can provide stronger restriction).
> >
> > This is one thousand bill [$1000千圓], keep the change.
> As I am in the mood, so Appendix C is added. Updated wording are in
> https://sourceforge.net/projects/cscall/files/MisFiles/ClassGuidelines.txt/download
>
> +--------------------------------------------+
> | Appendix C: Returning 'error' is necessary |
> +--------------------------------------------+
> Reusing of execution codes has two kinds, as a function or as a macro (C++
> template is an advanced kind in source level). The exit points (I mean the
> flowchar of machine codes, or assembly) of a function are traditionally
> simplified to one point (the return address) by encoding the exit information
> carried in the branch point into a return object --- the basic picture of the
> original codes (the nature may be more intriguing).
> So, the birth of the branch point info. carrying object and the associated cost
> of space and time to encode and decode. 'error' or 'exception' is what human
> thinks, it is just an information/mechanism for branching.
>
> Control-flows between modules are similar, just have more room to play tricks.
>
> So, libwy regards returning Errno as primitive.

A section about ops-on-self is added to ClassGuidelines. The updated version is at
https://sourceforge.net/projects/cscall/files/MisFiles/ClassGuidelines.txt/download

------ Operations on self
Functions that modify something from source info. is what programs do.
But, when the source and destination object overlap (this is possible when the
object is indicated by pointer or reference), things become tricky, e.g.

t.reset(t);
str.reset(cstr_ptr); // cstr_ptr points to the inside string of str.

Theoretically, semantics of such expression is classified as undefined. In
C/C++, if the source object is indicated const, the promise will be broken, at
least.

[Rationale omitted]

This library decided to test this situation, if cannot work around, ELOOP is
returned.
----------

Such ops-on-self should not be few. How does std library deal with this (e.g. string, vector)?
The cost of checking is not cheap, suggestion and idea?

Re: OOD idea of C++ and class coding guide lines

<u96ugt$1pmsh$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=902&group=comp.lang.c%2B%2B#902

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: chris.m....@gmail.com (Chris M. Thomasson)
Newsgroups: comp.lang.c++
Subject: Re: OOD idea of C++ and class coding guide lines
Date: Tue, 18 Jul 2023 14:00:12 -0700
Organization: A noiseless patient Spider
Lines: 20
Message-ID: <u96ugt$1pmsh$1@dont-email.me>
References: <4ebc633e-2dbd-4c5d-b9d1-45101d781c4dn@googlegroups.com>
<u8hk7v$2jkd9$2@dont-email.me>
<220c7ef8-31d5-4198-8624-883644c3c2f3n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 18 Jul 2023 21:00:13 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="4968e6fd90b76b2c9a43bd670dd5aa43";
logging-data="1891217"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1968ecu+Wx6tM+DO6jD2all3L42Tc785GY="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.13.0
Cancel-Lock: sha1:BlkduS3BEqcpfCXMfviJawCac5I=
Content-Language: en-US
In-Reply-To: <220c7ef8-31d5-4198-8624-883644c3c2f3n@googlegroups.com>
 by: Chris M. Thomasson - Tue, 18 Jul 2023 21:00 UTC

On 7/10/2023 2:13 PM, wij wrote:
> On Tuesday, July 11, 2023 at 2:56:19 AM UTC+8, Chris M. Thomasson wrote:
>> On 6/28/2023 1:36 AM, wij wrote:
>>> The following are rewrite of my 20-years old coding guide lines. I'd like to
>>> ask for suggestions to refine in the way because one reason is that recently
>>> the many questions I saw in this forum are actually rooted in class design
>>> problems (or problems of being too expressive, arbitrary).
>> [...]
>>
>> Here are some coding guidelines for ya:
>>
>> https://www.stroustrup.com/JSF-AV-rules.pdf
>>
>> ;^)
>
> Thanks, it looks my class member rule win! (I can provide stronger restriction).
>
> This is one thousand bill [$1000千圓], keep the change.

I concur. :^)

Re: OOD idea of C++ and class coding guide lines

<0cb84ba7-ee78-47a7-a552-27713d7fad1fn@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=932&group=comp.lang.c%2B%2B#932

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:ac8:590b:0:b0:403:b102:9559 with SMTP id 11-20020ac8590b000000b00403b1029559mr1826qty.9.1689898018797;
Thu, 20 Jul 2023 17:06:58 -0700 (PDT)
X-Received: by 2002:a05:6808:13c2:b0:39e:9757:6263 with SMTP id
d2-20020a05680813c200b0039e97576263mr1194922oiw.0.1689898018375; Thu, 20 Jul
2023 17:06:58 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Thu, 20 Jul 2023 17:06:57 -0700 (PDT)
In-Reply-To: <fa6d28c2-8e23-494f-9fda-cc7c7e869e24n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=0Ek0TQoAAAAS0oceh95IuNV59QuIWNeN
NNTP-Posting-Host: 124.218.76.41
References: <4ebc633e-2dbd-4c5d-b9d1-45101d781c4dn@googlegroups.com>
<u8hk7v$2jkd9$2@dont-email.me> <220c7ef8-31d5-4198-8624-883644c3c2f3n@googlegroups.com>
<4a157119-36b1-4c38-beb7-b512a1b313b0n@googlegroups.com> <fa6d28c2-8e23-494f-9fda-cc7c7e869e24n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <0cb84ba7-ee78-47a7-a552-27713d7fad1fn@googlegroups.com>
Subject: Re: OOD idea of C++ and class coding guide lines
From: wynii...@gmail.com (wij)
Injection-Date: Fri, 21 Jul 2023 00:06:58 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 6295
 by: wij - Fri, 21 Jul 2023 00:06 UTC

On Friday, July 14, 2023 at 12:05:52 PM UTC+8, wij wrote:
> On Wednesday, July 12, 2023 at 7:56:25 AM UTC+8, wij wrote:
> > On Tuesday, July 11, 2023 at 5:13:59 AM UTC+8, wij wrote:
> > > On Tuesday, July 11, 2023 at 2:56:19 AM UTC+8, Chris M. Thomasson wrote:
> > > > On 6/28/2023 1:36 AM, wij wrote:
> > > > > The following are rewrite of my 20-years old coding guide lines. I'd like to
> > > > > ask for suggestions to refine in the way because one reason is that recently
> > > > > the many questions I saw in this forum are actually rooted in class design
> > > > > problems (or problems of being too expressive, arbitrary).
> > > > [...]
> > > >
> > > > Here are some coding guidelines for ya:
> > > >
> > > > https://www.stroustrup.com/JSF-AV-rules.pdf
> > > >
> > > > ;^)
> > > Thanks, it looks my class member rule win! (I can provide stronger restriction).
> > >
> > > This is one thousand bill [$1000千圓], keep the change.
> > As I am in the mood, so Appendix C is added. Updated wording are in
> > https://sourceforge.net/projects/cscall/files/MisFiles/ClassGuidelines.txt/download
> >
> > +--------------------------------------------+
> > | Appendix C: Returning 'error' is necessary |
> > +--------------------------------------------+
> > Reusing of execution codes has two kinds, as a function or as a macro (C++
> > template is an advanced kind in source level). The exit points (I mean the
> > flowchar of machine codes, or assembly) of a function are traditionally
> > simplified to one point (the return address) by encoding the exit information
> > carried in the branch point into a return object --- the basic picture of the
> > original codes (the nature may be more intriguing).
> > So, the birth of the branch point info. carrying object and the associated cost
> > of space and time to encode and decode. 'error' or 'exception' is what human
> > thinks, it is just an information/mechanism for branching.
> >
> > Control-flows between modules are similar, just have more room to play tricks.
> >
> > So, libwy regards returning Errno as primitive.
> A section about ops-on-self is added to ClassGuidelines. The updated version is at
> https://sourceforge.net/projects/cscall/files/MisFiles/ClassGuidelines.txt/download
>
> ------ Operations on self
> Functions that modify something from source info. is what programs do.
> But, when the source and destination object overlap (this is possible when the
> object is indicated by pointer or reference), things become tricky, e.g.
>
> t.reset(t);
> str.reset(cstr_ptr); // cstr_ptr points to the inside string of str.
>
> Theoretically, semantics of such expression is classified as undefined. In
> C/C++, if the source object is indicated const, the promise will be broken, at
> least.
>
> [Rationale omitted]
>
> This library decided to test this situation, if cannot work around, ELOOP is
> returned.
> ----------
>
> Such ops-on-self should not be few. How does std library deal with this (e.g. string, vector)?
> The cost of checking is not cheap, suggestion and idea?

I think ClassGuidelines https://sourceforge.net/projects/cscall/files/MisFiles/ClassGuidelines.txt/download
should be completed. The following should be the last section added.

-------- Returning error and the error checking
Error (branching point information) not handled is always a hiden 'UB' waiting
to happen. The guideline is: ALWAYS CHECK THE ERROR. This guideline extends to
API, therefore, "__attribute__((warn_unused_result))" should be added to the
returning Errno. As usual, exception exists.

From function usage point of view: The general concern of error checking may
be the complexity and readibility of the source codes. In this guidelines'
view, without the checking and handling of the error, the evaluation
(readibility, beauty,..) of the codes is one-sided judgement, because error
checking and handling is part of the complete program.
The minimum check-and-throw pattern is better than ignoration, such coding is
equivalent to a blended 'cheap and better assert'.
Practice proves that error checking actually reduces software development and
maintenance time, significantly.

--------------
I don't know what to say. My coding guidelines are very different from MANY programs I saw.
The last one I checked is "asio C++ library" https://sourceforge.net/projects/asio/
Lots of codes are about 'concept and policy', difficult to find real ones, and it seems
to throw error. How does it expect user catch and handle it? ...


devel / comp.lang.c++ / Re: OOD idea of C++ and class coding guide lines

1
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor