Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: wij <wyniijj5@gmail.com>
Newsgroups: comp.lang.c++
Subject: Re: What is OOP?
Date: Wed, 04 Dec 2024 22:31:00 +0800
Organization: A noiseless patient Spider
Lines: 319
Message-ID: <ca1b6f0bae05427d5a715146df77c60cbcd1c014.camel@gmail.com>
References: <d8a5a0d563f0b9b78b34711d12d4975a7941f53a.camel@gmail.com>
	 <gog0ljdjdhdekscrcbpprte8788aerq05h@4ax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Injection-Date: Wed, 04 Dec 2024 15:31:01 +0100 (CET)
Injection-Info: dont-email.me; posting-host="480ecf5338b3395793e3ae85a24ec6b2";
	logging-data="975792"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18Gu/t1932pMltIpCEyEjw+"
User-Agent: Evolution 3.50.2 (3.50.2-1.fc39)
Cancel-Lock: sha1:2zs21s308KJx4e2lJ3tet6DVleE=
In-Reply-To: <gog0ljdjdhdekscrcbpprte8788aerq05h@4ax.com>
Bytes: 13317

On Wed, 2024-12-04 at 13:14 +0100, Rosario19 wrote:
> On Mon, 02 Dec 2024 01:17:49 +0800, wij=C2=A0 wrote:
> > There are several understandings:
> > https://www.quora.com/As-an-experienced-OOP-programmer-in-your-opinion-=
whats-the-biggest-problem-of-OOP-object-oriented-programming
> >=20
> > ...
> > OO can have many meaning. I took OO to mean object, the basic entity of=
 the
> > programming model and the operation of the object. The concept, as foun=
dmental,
> > has to be solid, practical and easily usable. Otherwise, more codes and=
 efforts
> > will be needed latter to fix it, making the original goal ,practically,=
 a lie.
> > IOW, (nearly) a flawless model is all the basics. ...
> > https://sourceforge.net/projects/cscall/files/MisFiles/ClassGuidelines.=
txt/download
> >=20
> > From my view, programming language has to provide a model, so that prog=
rammers=20
> > know what they are dealing with, to solve the problem (recent C++ seems=
 solving
> > just syntax problems).
> > In (my) OOP, 'portability' (or reusable) is first achieved by making th=
e=20
> > probramming object compatible (form platform to platfrom or from time t=
o time
> > in the same platform, but libwy only considers linux, but the idea shou=
ld be
> > generally applicable), i.e. like pod types, structures, union may not b=
e portable.
> >=20
> > Programming object or 'concept' are 'better' represented/wrapped by cla=
ss (keyword)
> > All should be simple, I don't know how to make the idea of 'object' mor=
e simpler.
> > See the guidelines.
>=20
> oop
> what is oo programming?
> 1 definition
> object=3Dmemory layout and all the label to access to it, even that
> layout apply to the pc memory in the machine
> oop=3D programming way use objects and functions and operations on
> objects=20
> with this definition even C would be oop, int and all operation with
> that would be one object
>=20
> change definition
> 2 definition
> a object is a memory layout that have a routine for inizialize that
> memory (constructor) and one routine for end the object (distructor)
> and the programmer can define all the functions and operations to it
> and othe objects or types in language
>=20
> oop is the programming of objects in definition 2

That (the beginning of OOP) is RAII. But, not C++ programs are automaticall=
y RAII.=20
You still need to make it RAII.

[Snippet] Object life cycle view
+----------------------------------------------------------+
| Creating objects to program:                             |
| 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 that can be randomly overwritten is referred to =
as
          discardable in this library. Often, such object has no user defin=
ed
          destructor.
-----

More to continue:

----- 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 dom=
ain
   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++ langua=
ge
   (ref. [12.4.14]). Since destructing an object the second time results to
   undefined behavior, destructor must make sure destructing it once is eno=
ugh.
   In another word, destructor must succeed to the language. Object destruc=
tion
   actually magnifies the effect of common ignorance of the implicitly crea=
ted
   rollback function (or a design).... The program execution from return/th=
row/
   exit.. to its caller(e.g. main, init..) shall succeed.

   Note: C++ language had enforced the semantics that 'destructor must succ=
eed'.

 Const member functions:
   A set of const function members, often referred to as property or attrib=
ute
   members, defines whether or not two objects function 'identically'. In
   general, a minimum set of such members must exist. These members are oft=
en
   in complexity O(1), and provide the basic proofs that the class is prope=
rly
   designed.

 Reset(..) members:
   Reset member brings the object from responsible state back to random sta=
te
   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 obje=
ct
   initialization process of the life cycle view (and the symmetrical rever=
se).
   Implementation can optimize the theoretical sequence.

   Since this library adopts an implicit rule that object has to be in a 'v=
alid'
   state, 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 r=
eset
   members normally exist but not necessary. For instance, if the class
   contains const or reference data members, then the reset would be diffic=
ult
   to implement.

 Move Constructor:
   The motivation of devising is from the need to avoid costly and unnecess=
ary
   copy operations found in classes that contain allocated resources and th=
e
   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 't=
his'
   pointed address (source object is treated non-existent). The reason is t=
hat
   such an operation is conceptually elementary, thus, it can enable the
   definition of a no-throw swap function template (note: implementation ne=
eds
   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 ligh=
t
   weight, which in a way means it can transform easier. Again, This librar=
y's
   guide "No room should be left for lower-level implement". Another reason=
========== REMAINDER OF ARTICLE TRUNCATED ==========