Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Is it legal code?

Reply
Thread Tools

Is it legal code?

 
 
Paul
Guest
Posts: n/a
 
      02-21-2011

"Stuart Redmann" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On 21 Feb., "Paul" wrote:
>> Invalid code , illformed program , illegal construct etc etc are all
>> terms
>> that mean generally screwed up code.
>>
>> Whatever the correct terminology the bottom line is that if a program
>> invokes UB, whatever happens after that is anyones guess.
>> So consider the following psuedo code:
>> do something;
>> do something else;
>> invoke UB;
>> do something more;
>>
>> 'do something more' cannot be considered part of a valid C++ program.
>> There
>> is no defined sequence after the UB.

>
> Agreed. However, there is a subtle difference between illegal code and
> UB: Illegal code says that different compilers are not forced to
> produce semantically equivalent machine code, whereas UB means that
> different run-times may produce different results. While I consider
> illegal code as something that must be avoided at all costs, I allow
> for very, very few occurances of UB (for example casting a
> std::vector<Derived*> to _const_ std::vector<Base*>).
>

Fair enough.
>
> "Stuart Redmann" wrote:
>> > PS: In my opinion the life-time of members functions and ordinary
>> > functions should be equivalent, so I wouldn't go so far as to say that
>> > we need at least one object in order for its member functions to
>> > exist. I don't know whether the C++ standard agrees with me, but I
>> > would be surprised if the authors of the standard had a different
>> > opinion.

>
> On 21 Feb., "Paul" wrote:
>> What is your idea of the lifetime of a function?
>> a) from function calling code until return?
>> b) from start of program until end of a program?
>> c) something other?

>
> I'd opt for b).
>

I think this is very debateable.
I can understand your view if a function is thought of a set of instructions
in a block of memory, but a function can also be seen as a sub
process/routine
I usually think of a function as a sub-process, when thinking in this way it
seems inconceivable that a functions' lifetime can be the same as the
program (unless its the main function ).

TY
Paul.

 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      02-21-2011
On Feb 21, 4:42 pm, "Paul" <(E-Mail Removed)> wrote:
> "James Kanze" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > On Feb 21, 11:48 am, "Paul" <(E-Mail Removed)> wrote:
> >> "James Kanze" <(E-Mail Removed)> wrote in message


> > [...]
> >> > In practice, as someone else has pointed out in this thread, you
> >> > can take the address of a non-static member function, with or
> >> > without the presense of an object. Which seems like
> >> > a conclusive argument that whatever non-static member functions
> >> > might be, and whether they exist or not, their reality or status
> >> > or whatever is independent of any object.


> >> I have pointed this out , but I aslo pointed out this would
> >> not be standard complaint. I disagree with your analysis,
> >> I think the standard defines a rule that means a function
> >> cannot exists without an object, the opposite of your
> >> conclusion.


> > So what am I taking the address of, when I take its address.


> You are in a gray area where you have a pointer to a functions
> definition, but you can't invoke the function, so does the
> function exist?


It depends on your definition of "exists", I suppose. But the
issue is not restricted to non-static member functions; the same
question could be asked of any function which requires an lvalue
(and thus an object). Given:

struct Toto
{
void titi();
};
void tata(Toto&);

, what is the existential difference between Toto::titi and
tata?

> > Given something like:


> > struct Toto
> > {
> > void titi();
> > };


> > int
> > main()
> > {
> > void (Toto::*pmf1)() = &Toto::titi;
> > // What does pmf1 point to, if Toto::titi
> > // doesn't exit?


> Its the address InstrPointer will point to when the the function is
> invoked. (for an assumed machine architecture).


The pointer already exists, and has a fixed value. What does it
mean to be the address something will point to when the function
is called?

> &Toto::titi is the location where the function is defined.


It's the address of the function. As far as the standard is
concerned, there is no "location".

> > Toto* p1 = new Toto;
> > Toto* p2 = new Toto;
> > void (Toto::*pmf2)() = &Toto::titi;
> > // And what about here, since according to
> > // your logic, there are now two Toto::titi?


> No there are two pointers.
> Toto::titi is part of the class/object-type defiition, there is only one
> definiton for all instances of this class/object-type.
> (whether this is guaranteed to be the case on all implementations, I think
> is undefined).


> Note: I am not talking about breaking the one definition rule , I am
> thinking of possible implementations of virtual functions.> }


> > No matter how you cut it: if existance has any meaning for
> > a member function, it exists for the entire time the program
> > runs, regardless of the presence or absence of instances.


> If you are going to give a function a lifetime then consider
> a function as a sub-process. What is the lifetime of that
> sub-process? It seems stupid to speak about the lifetime of
> a function, where every function has the same lifetime(that of
> program execution).


But that's the only way you can speak about it and be conform
with what the standard says. C++0x doesn't link functions with
threads (I presume that's what you mean by "sub-process") any
more than it links them to objects. A member function is
a function like any other, except that it has a special calling
syntax, and special access rights to member data.

> >> > But in the end, who cares?


> >> What kind of attitude is that? If you don't accept the rules
> >> of the language, that's hardy good pr for you as
> >> a professional.


> > What does your argumentation have to do with the rules of the
> > C++ language? It's purely a lexical dispute.


> The rules suggest that a NSMF cannot be called unless called
> on an object. This supports my argument that C++ supports the
> OOP concept that NSMF's are members of an object.


The rules say explicitly that *no* function, member or
otherwise, can be called without being passed valid arguments.
Any function taking a reference requires an object. There's
nothing special about member functions here.

> If you are suggesting C++ does not support OOP, this seems
> like a pretty bold statement to make considering the
> overwhelming evidence to suggest otherwise. I don't see how
> you can brush this of as 'purely lexical'.


I'm not sure what you mean by "supporting OOP". C++ provides
adequate support for OOP, and for a number of other paradigms as
well. But the usual language of OOP doesn't talk about members
of objects (at least not in OOP languages with static
typechecking); it talks about members of classes; Java, for
example, has class members (8.2 of the Java specification), not
object members. It's frequent as well to use the term "members
of an object" as a shorthand for "members of the object's type",
but this is just that, a shorthand.

> >> > The whole discussion sounds more like metaphysics than
> >> > anything useful. Pragmatically, if you want to
> >> > communicate, you use the same vocabulary as everyone
> >> > else, even if you think it less than ideal. And if you
> >> > don't want to communicate, why bother posting at all?


> >> People around here keep thinking they speak for the
> >> majority but this is not the case.


> > Except that you can't find anyone speaking differently, at
> > least where C++ is concerned.


> No I can find hundreds of quotes to support me, the fact that
> nobody in here seems to be speaking up against the majority(in
> here) doesn't mean you are the real majority.


And where do you find those quotes? I can't find them, and I've
read quite a bit of the OO literature. None of my collegues,
past or present, describe things in terms you use, and that
represents a lot of very competent people.

> >> Just take alook at your argument in the stl thread James
> >> , you originally started of arguing with the majority
> >> , then later it evolves that you don't even support that
> >> cause. You just argued on-sdie with Pete becker etc because
> >> they seemed like the stronger side to be on., this doesn't
> >> mean everyone arguing against you has a failure to
> >> communicate.


> > In the case of the STL argument, I've argued consistently
> > that the term is ambiguous. Unlike the current discussion,
> > there is no consensus among C++ practitionners as to what
> > STL means. In some ways, this is regretable, but neither
> > I nor anyone else can force consensus. (Luckily, in the
> > case of the meaning of STL, the distinction isn't really
> > important.)


> You and a few other in here have claimed that a NSMF is
> a member of a class but not an object. You have given no
> evidence at all to support your claim except for the fact that
> you are in the majority therefore you are correct.


We cite other uses, such as that of the C++ standard. (I've
also cited the Java standard, just to prove that it's not
a particularity of C++.) As we are clearly in the majority
here, and in the majority in the C++ committee, it's up to you
to find support elsewhere---in which case, the best you can do
is prove that the use is ambiguous; that different communities
use the language differently.

> C++ is a language where the class is the definition of an
> object, so to say something is a member of a class but not
> part of an object doesn't make sense, bar the exception of
> static members.


No. A class is not the definition of an object, neither in C++
nor in Java (the other "OO" language I know well). A class is
a definition of a type, and an object has a type---in C++, that
type is not even necessarily a class type.

Note the distinction---it's a typically OO one between isA
(a class isA type) and containment (an object hasA type). In
many (most?) OO languages, each type is represented by a specific
object, but this is not the case of C++, and it is still
a distinct object, with its own type, and not the object which
has the type.

> Member functions as part of an object are a well defined OOP
> concept


It's such a well defined concept that I can find no mention of
it in the literature. A quick search for member functions turns
up:
-- Member functions are operators and functions that are
declared as members of a class. (IBM)
-- Classes can contain data and functions. These functions are
referred to as "member functions." (Microsoft)
and so on.

> and if a language doesn't support this, it cannot be
> said to support OOP.


In which case, I know of no language which supports OOP. The
Java specification makes the distinction even clearer than the
C++ one.

> However C++ does support OOP so therefore
> it follows that C++ supports the concept of member functions
> as members of an object. The argument you have put forward is
> very non supportive of OOP, and if your argument was correct
> it would mean C++ did not support OOP.


For starters, you've got things backwards. C++ has a set of
functionalities; it is this set which can be used to determine
whether C++ supports OOP or not (and some prominent
practitioners---Bertrand Meyers for examnple---have proclamed
that it doesn't). Whether a feature is OOP or not has no
influence on the language---only on how you view the language.

> Can you at least agree that a language must support this
> concept to support OOP?


No, since Java explicitly doesn't, and Java is definitly OOP
(and not much else).

--
James Kanze
 
Reply With Quote
 
 
 
 
Paul
Guest
Posts: n/a
 
      02-21-2011

"itaj sherman" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
On Feb 21, 6:42 pm, "Paul" <(E-Mail Removed)> wrote:

>
> Can you at least agree that a language must support this concept to
> support
> OOP?- Hide quoted text -
>


And what would be your definition of OOP?

'''''''''''''''''''''''''''''''''''''''''''''''''' '''''''''''''''''''''''''''''''''''''''''''''''''

Object Orientated Programming.

I guess you are looking for a more detailed answer but I don't know what to
say TBH. I think there are differing opinions about some OOP concepts. But
there are some concepts that are generally agreed on, member functions as
members of an object is one of the generally agreed upon concepts IMHO.

 
Reply With Quote
 
itaj sherman
Guest
Posts: n/a
 
      02-21-2011
On Feb 21, 7:46*pm, "Paul" <(E-Mail Removed)> wrote:

>
> Object Orientated Programming.
>
> I guess you are looking for a more detailed answer but I don't know what to
> say TBH. I think there are differing opinions about some OOP concepts. But
> there are some concepts that are generally agreed on, member functions as
> members of an object is one of the generally agreed upon concepts IMHO.


And what is the meaning of the word "member" in this?
I'm sure it's not the same as any of the 3 different meanings (at
least) of the word "member" in of the following c++ definitions: data
member, static data member, function member, static function member.
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      02-21-2011
On Feb 21, 5:06 pm, "Paul" <(E-Mail Removed)> wrote:
> "James Kanze" <(E-Mail Removed)> wrote in message


> news:(E-Mail Removed)...
> > On Feb 21, 2:00 pm, "Paul" <(E-Mail Removed)> wrote:
> >> "James Kanze" <(E-Mail Removed)> wrote in message


> >>news:(E-Mail Removed)...


> >> > On Feb 20, 9:59 pm, Leigh Johnston <(E-Mail Removed)> wrote:
> >> >> On 20/02/2011 21:44, Paul wrote:


> >> > [...]
> >> >> In C++ a member function is a member of a class not
> >> >> a member of an object; in C++ an object is simply
> >> >> a region of storage; in C++ a non-static member function
> >> >> is *invoked* on an object it is not part of an object.


> >> > In C++, an object is a *contiguous* region of storage. Each
> >> > object has a distinct address.


> >> > C++ also requires pointer to member functions to compare equal
> >> > if they point to the same function. So member functions cannot
> >> > be members of an object; they must have an existance outside of
> >> > the object.


> >> They do have an existence outside objects, but their existence
> >> outwith an object is undefined.


> > And what does "existence [..] is undefined" mean?


> I actually covered two things by this:
> 1)The existence/lifetime of a function is a gray area and is undefined.
> 2)When a function is invoked on an object its behaviour is defined,
> otherwise it is undefined.


I don't think that there's any disagreement there. But there is
no difference between member functions and free functions in
either case.

> >> This doesn't mean they are not members of an object but
> >> members of a class, they don't exist inside a class either.
> >> The class doesn't even exist anymore, its as precompile
> >> time entity. The class-type or object-type( means the same
> >> thing), is defined. If this type is defined to have a NSMF
> >> then the NSMF is a member of the object and the class-type.


> > Within the C++ standard, class type and object type are two very
> > different concepts. A "class type" is a subset of all possible
> > types. An "object type" is a much larger subset: int in not
> > a class type, but it is an object type.


> What you say above seems illogical to me i.e the following are incoherent.:
> 1) a class type is a subset of all possible types
> 2) object type is a larger subset, int is not a class type.


> How can you get larger subset than *all possible* types?


Class types are a subset of all possible subsets. Object types
are a subset of all possible subsets. The cardinality of
"object types" is larger than the cardinality of "class types".
Thus, if I write:
class Toto {};
typedef int Titi;
typedef void Tata(); // (And yes, this is legal. Even if
// I've never found a use for it.)
Then Toto, Titi and Tata are names of types: all three are in
the set of all possible types. Toto and Titi are object types,
and only Toto is a class type.

> > This is the usual C++ terminology.


> IMO the standards loose use of the word 'object' to mean
> almost anything imaginable is confusing.


It doesn't use it to mean almost anything. It uses "object" for
a specific set of types, which have instances guaranteed to be
represented as a contiguous set of bytes in memory.

> Everytime I use the word now I feel the need to follow it with
> a bracketed description to define my meaning(which is normally
> an instance of class-type).
> .>> *It's not simply a class member because this terminology is
> >> used to mean static members*.


> > By whom? In what context? I've worked with a lot of C++
> > programmers, over the last twenty or so years, and I've never
> > heard one use it this way.


> http://en.wikipedia.org/wiki/Class_variable
>


Not that Wikipedia is a reference, but it does reflect the
vocabulary used by at least some practitioners...

The article in question talks about "class variable", and
compares it with "instance variable". There's nothing in it
which says that "instance variables" aren't members of a class;
it doesn't even speak of "members".

More generally, however, I have found some respectable sites
which do use your terminology. From an admittedly very quick
scan of the text, my impression is that people from a Smalltalk
background think in terms of objects having members (and don't
think much in terms of types at all); people from a Simula
background think in terms of classes having members (and are
very concerned about types). Stroustrup, of course, studied
with the creators of Simula, and has long cited Simula as his
major source, along side of C. And types are a very important
concept in C++. So the Simula vocabulary seems more
appropriate. Also, most people from the Smalltalk school deny
C++, and even Java, the qualification of an OOP language. And
also, they don't talk about functions, period---functions don't
exist in Smalltalk, only methods, which are members of the
object (since there isn't any type system in the sense we
understand it in C++), and react to messages.

Anyway, that's not the way most people speak about C++.
Curiously enough, a lot more Java experts use the term "members
of an object", despite the Java standard very explicitly
describing members as "of a class". My experience is largely
C++ (with some Java), so I use the vocabulary that is current in
the C++ community, and especially in the C++ standards
committee. When talking about C++, it certainly facilitates
communication. (Maybe part of your problem is that you consider
C++ an OOP language, while using a vocabulary generally used by
people who don't consider C++ OOP.)

--
James Kanze
 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      02-21-2011

<snip>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

This is too long a post to manually indent everything. Please re-raise any
issues if you think I am trying to avoid anything
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

But when you see what i have to post you will realise I am not avoiding
anything.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>



>You are in a gray area where you have a pointer to a functions
> definition, but you can't invoke the function, so does the
> function exist?


It depends on your definition of "exists", I suppose. But the
issue is not restricted to non-static member functions; the same
question could be asked of any function which requires an lvalue
(and thus an object). Given:

struct Toto
{
void titi();
};
void tata(Toto&);

, what is the existential difference between Toto::titi and
tata?



> > Given something like:


> > struct Toto
> > {
> > void titi();
> > };


> > int
> > main()
> > {
> > void (Toto::*pmf1)() = &Toto::titi;
> > // What does pmf1 point to, if Toto::titi
> > // doesn't exit?


> Its the address InstrPointer will point to when the the function is
> invoked. (for an assumed machine architecture).


The pointer already exists, and has a fixed value. What does it
mean to be the address something will point to when the function
is called?

> &Toto::titi is the location where the function is defined.


It's the address of the function. As far as the standard is
concerned, there is no "location".

> > Toto* p1 = new Toto;
> > Toto* p2 = new Toto;
> > void (Toto::*pmf2)() = &Toto::titi;
> > // And what about here, since according to
> > // your logic, there are now two Toto::titi?


> No there are two pointers.
> Toto::titi is part of the class/object-type defiition, there is only one
> definiton for all instances of this class/object-type.
> (whether this is guaranteed to be the case on all implementations, I think
> is undefined).


> Note: I am not talking about breaking the one definition rule , I am
> thinking of possible implementations of virtual functions.> }


> > No matter how you cut it: if existance has any meaning for
> > a member function, it exists for the entire time the program
> > runs, regardless of the presence or absence of instances.


> If you are going to give a function a lifetime then consider
> a function as a sub-process. What is the lifetime of that
> sub-process? It seems stupid to speak about the lifetime of
> a function, where every function has the same lifetime(that of
> program execution).


But that's the only way you can speak about it and be conform
with what the standard says. C++0x doesn't link functions with
threads (I presume that's what you mean by "sub-process") any
more than it links them to objects. A member function is
a function like any other, except that it has a special calling
syntax, and special access rights to member data.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>

Here I am speaking about a function as a sub-routine or sub-process, I'm not
talking about thread processes.

Please note your final sentence in the above paragraph. Its a contradiction
in terms. You state that a member function is like any normal function
except......blah blah. This means its not the same as a normal function. I
would refer back to this in the many instances where you suggest there is
nothing special about member functions, if it weren't for my skipping over
because of indenting probs.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>


> >> > But in the end, who cares?


> >> What kind of attitude is that? If you don't accept the rules
> >> of the language, that's hardy good pr for you as
> >> a professional.


> > What does your argumentation have to do with the rules of the
> > C++ language? It's purely a lexical dispute.


> The rules suggest that a NSMF cannot be called unless called
> on an object. This supports my argument that C++ supports the
> OOP concept that NSMF's are members of an object.


The rules say explicitly that *no* function, member or
otherwise, can be called without being passed valid arguments.
Any function taking a reference requires an object. There's
nothing special about member functions here.

> If you are suggesting C++ does not support OOP, this seems
> like a pretty bold statement to make considering the
> overwhelming evidence to suggest otherwise. I don't see how
> you can brush this of as 'purely lexical'.


I'm not sure what you mean by "supporting OOP". C++ provides
adequate support for OOP, and for a number of other paradigms as
well. But the usual language of OOP doesn't talk about members
of objects (at least not in OOP languages with static
typechecking); it talks about members of classes; Java, for
example, has class members (8.2 of the Java specification), not
object members. It's frequent as well to use the term "members
of an object" as a shorthand for "members of the object's type",
but this is just that, a shorthand.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>

<quote ref =http://java.sun.com/docs/glossary.html#O>
"object
The principal building blocks of object-oriented programs. Each object is a
programming unit consisting of data (instance variables) and functionality
(instance methods). See also class."
</quote>

I have nothing more to say about your above paragraph except.. complete
rubbish.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >.>>>
> >> > The whole discussion sounds more like metaphysics than
> >> > anything useful. Pragmatically, if you want to
> >> > communicate, you use the same vocabulary as everyone
> >> > else, even if you think it less than ideal. And if you
> >> > don't want to communicate, why bother posting at all?


> >> People around here keep thinking they speak for the
> >> majority but this is not the case.


> > Except that you can't find anyone speaking differently, at
> > least where C++ is concerned.


> No I can find hundreds of quotes to support me, the fact that
> nobody in here seems to be speaking up against the majority(in
> here) doesn't mean you are the real majority.


And where do you find those quotes? I can't find them, and I've
read quite a bit of the OO literature. None of my collegues,
past or present, describe things in terms you use, and that
represents a lot of very competent people.
..>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>

One above and here's another, there are hundreds if not thousands:

http://en.wikipedia.org/wiki/Object-...ed_programming

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>



> >> Just take alook at your argument in the stl thread James
> >> , you originally started of arguing with the majority
> >> , then later it evolves that you don't even support that
> >> cause. You just argued on-sdie with Pete becker etc because
> >> they seemed like the stronger side to be on., this doesn't
> >> mean everyone arguing against you has a failure to
> >> communicate.


> > In the case of the STL argument, I've argued consistently
> > that the term is ambiguous. Unlike the current discussion,
> > there is no consensus among C++ practitionners as to what
> > STL means. In some ways, this is regretable, but neither
> > I nor anyone else can force consensus. (Luckily, in the
> > case of the meaning of STL, the distinction isn't really
> > important.)


> You and a few other in here have claimed that a NSMF is
> a member of a class but not an object. You have given no
> evidence at all to support your claim except for the fact that
> you are in the majority therefore you are correct.


We cite other uses, such as that of the C++ standard. (I've
also cited the Java standard, just to prove that it's not
a particularity of C++.) As we are clearly in the majority
here, and in the majority in the C++ committee, it's up to you
to find support elsewhere---in which case, the best you can do
is prove that the use is ambiguous; that different communities
use the language differently.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>

"We"? Are you skitzo, or royal?
You are speaking nonsense James, see my quote from Java above.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>


<snip rest>

 
Reply With Quote
 
itaj sherman
Guest
Posts: n/a
 
      02-21-2011
On Feb 21, 7:46*pm, "Paul" <(E-Mail Removed)> wrote:

>
> Object Orientated Programming.
>
> I guess you are looking for a more detailed answer but I don't know what to
> say TBH. I think there are differing opinions about some OOP concepts. But
> there are some concepts that are generally agreed on, member functions as
> members of an object is one of the generally agreed upon concepts IMHO.


Whatever your definitions mean.
The following section of the standard is very clear about the
definitions of all members in c++ (and whether they are members of the
class or something else):

9.2/1 The member-specification in a class definition declares the full
set of members of the class; no member can be added elsewhere. Members
of a class are data members, member functions (9.3), nested types, and
enumerators. Data members and member functions are static or non-
static; see 9.4. Nested types are classes (9.1, 9.7) and enumerations
(7.2) defined in the class, and arbitrary types declared as members by
use of a typedef declaration (7.1.3). The enumerators of an unscoped
enumeration (7.2) defined in the class are members of the class.
Except when used to declare friends (11.4) or to introduce the name of
a member of a base class into a derived class (7.3.3, 11.3), member-
declarations declare members of the class, and each such member-
declaration shall declare at least one member name of the class. A
member shall not be declared twice in the member-specification, except
that a nested class or member class template can be declared and then
later defined, and except that an enumeration can be introduced with
an opaque-enum-declaration and later redeclared with an enum-
specifier.

When we converse about c++ here we stick to these definitions and any
others in the standard because we want to understand each other
easily.
If you want to talk about different things you have to choose another
name that is not used by already existing defintions (in the
standard), and explain very clearly what your definition is. For all I
care you can call it x-member.
Also, you will be expected to show what your definitions are
beneficial for, if you want anyone to consider them seriously.

* BTW, I do think that the word "member" in any of these does not
stand by itself, because it has a slightly different meaning between
them. However it makes no difference for anything we talked about.

itaj
 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      02-21-2011

"itaj sherman" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
On Feb 21, 7:46 pm, "Paul" <(E-Mail Removed)> wrote:

>
> Object Orientated Programming.
>
> I guess you are looking for a more detailed answer but I don't know what
> to
> say TBH. I think there are differing opinions about some OOP concepts. But
> there are some concepts that are generally agreed on, member functions as
> members of an object is one of the generally agreed upon concepts IMHO.


And what is the meaning of the word "member" in this?
I'm sure it's not the same as any of the 3 different meanings (at
least) of the word "member" in of the following c++ definitions: data
member, static data member, function member, static function member.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


Can you jump to the point please because my newsreader aint indenting and
its a pain , if you have something form the standard you think suggests C++
doesn't suport OOP then please post the relevant quote.

 
Reply With Quote
 
itaj sherman
Guest
Posts: n/a
 
      02-21-2011
On Feb 21, 8:32*pm, "Paul" <(E-Mail Removed)> wrote:

>
> Can you jump to the point please because my newsreader aint indenting and
> its a pain , if you have something form the standard you think suggests C++
> doesn't suport OOP then please post the relevant quote.


get out.
 
Reply With Quote
 
itaj sherman
Guest
Posts: n/a
 
      02-21-2011
On Feb 21, 8:31*pm, itaj sherman <(E-Mail Removed)> wrote:
> On Feb 21, 7:46*pm, "Paul" <(E-Mail Removed)> wrote:
>


>
> > Object Orientated Programming.

>
> > I guess you are looking for a more detailed answer but I don't know what to
> > say TBH. I think there are differing opinions about some OOP concepts. But
> > there are some concepts that are generally agreed on, member functions as
> > members of an object is one of the generally agreed upon concepts IMHO.

>
> Whatever your definitions mean.
> The following section of the standard is very clear about the
> definitions of all members in c++ (and whether they are members of the
> class or something else):
>


I guess c++ is not OOP as far as you're concerned. You shouldn't be
learning it anymore.

itaj
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Is it legal to write an logical equation for a FPGA LUT in claims of a patent? Weng Tianxiang VHDL 12 12-10-2005 03:49 PM
Research: File-sharers big legal download spenders. Silverstrand Front Page News 0 07-27-2005 03:00 PM
State machine transition on internal signals - is it legal? Divyang M VHDL 9 05-18-2005 03:58 PM
State machine transition on internal signals -- is it legal? Divyang M VHDL 1 05-15-2005 09:36 AM
Is this legal? Valentin Tihomirov VHDL 20 10-29-2003 10:31 AM



Advertisments