(5+6%4)

Pages: 1234
closed account (1CfG1hU5)
to cnoeval:
i can counter incorrect arguments all I choose. you should read some posts above and maybe previous page. some persons here are ridiculous arguers about topics that could be talked of much more amicably and appropriately.

move on to another topic. this topic is solved for some time now.

some persons post here to raise hell because of wrongful enjoyment.

to minii:
the operators are not outdated minii. read above disch's posts. the word "harmful", you
are taking this too far. you really need to clam yourself.
closed account (1CfG1hU5)
relating source code available to making drugs and fraud. that is harmful speech.
I am tired of this. Just some test:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#include <stdio.h>

struct foo
{
    virtual void bar() {printf("%c", 'a');}
};

struct baz : foo
{
    virtual void bar() {printf("%c", 'b');}
};


int main()
{
    foo& x = *new baz;
    x.foo::bar();
}
If that code gives you are compile time error because it cannot find type baz.foo, your table is correct with precerence (as it says that member selection (.) and scope resolution belongs to same group and it parsed left-to-rigt. So last line should be read as (x.foo)::bar() ).

If it output is 'a', it is incorect and should not be used. (as actual precedence is :: first: (x.(foo::bar))() )
jt1 wrote:
from what I saw listed at a web page, the "::" scope operator was at top. looks close to precedence in c++ dos. not surprised "::" is first relating to standards.


Yes, but it is not at the very top. So it's incorrect.

:: has a higher priority than ()
In what you posted, they have equal priority. That is incorrect.

did you know source codes are available on web for dos compilers?


What does that have to do with anything?

those sources could be used to compile a c++ dos program which is considered too old a compiler by disch.


When you update Turbo C++ to be standards compliant, let me know and I will retract my statement.

Of course... if you do that... the compiler will no longer be 24 years old... so Cubbi's original claim would still be correct: 24 Year old compilers should not be used as a reference.

i make my own decisions about what i use or not whether disch approves or not.


I'm fine with that. Just don't spread bad information to newbies. That's all I really care about.

And when someone calls you out and tells you your information is bad... listen to them and learn from your mistake. Don't start an argument trying to defend a clearly faulty point.

I have been corrected numerous times on this forum... and each time I'm not only gracious about it, but am actually grateful for the person correcting me. It's a learning experience.

Don't be so stubborn. This isn't debate class.

you said in certain words that precedence did not change. disch argued opposite.


That's not true at all. You said that in this post:
http://www.cplusplus.com/forum/beginner/145271/#msg765266

You in that post wrote:
operator precedence should be same today as was then


MiiniPaa never claimed your operator precedence table was correct. You are taking his quote clearly out of context. What he said was this:

http://www.cplusplus.com/forum/beginner/145271/2/#msg766103
MiiniPaa wrote:
Operator precedence did not change. At all. It is just your beloved souce that got it completely wrong from the very beginning.


He's saying that the standard never changed (which is never did) -- but your precedence table was incorrect because it was pre-standard.

i can counter incorrect arguments all I choose.


Except that's not what you're doing. You're misinterpretting everything we say and arguing a completely fallacious point. You could not possibly be any more wrong than you are.
Why is this thread going "viral"??
closed account (1CfG1hU5)
this web page, "::" is at the top and is only labled as a part of 1

http://en.cppreference.com/w/cpp/language/operator_precedence

the dos c++ gives equal precedence to () and ::.

i am not updating c++ dos to the standards you speak of. i do not run the no longer in business borland international.

quoted disch:
MiiniPaa never claimed your operator precedence table was correct. You are taking his quote clearly out of context. What he said was this:

jt1 response:
he said in certain words that operator precedence had not changed. you need to reread previous message to find.

shuttup disch, you conceited arrogant individual. i believe you are doing a lot of this for
wrongful enjoyment.

you do not realize how incorrect you are for some reason.

i may not read future posts in relation to this topic.
the dos c++ gives equal precedence to () and ::.
Prove it. Do the little test I posted which will show exact precedence used in your compiler.
closed account (1CfG1hU5)
here is a partial precedence page from c++ dos:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
   #  Category   ³ Operator ³ What it is (or does)

   1. Highest    ³    ()    ³ Function call
                 ³    []    ³ Array subscript
                 ³    ->    ³ C++ indirect component selector
                 ³    ::    ³ C++ scope access/resolution
                 ³     .    ³ C++ direct component selector

   2. Unary      ³     !    ³ Logical negation (NOT)
                 ³     ~    ³ Bitwise (1's) complement
                 ³     +    ³ Unary plus
		 ³     -    ³ Unary minus
                 ³    ++    ³ Preincrement or postincrement
                 ³    --    ³ Predecrement or postdecrement
                 ³     &    ³ Address
                 ³     *    ³ Indirection
                 ³  sizeof  ³ (returns size of operand, in bytes)
                 ³    new   ³ (dynamically allocates C++ storage)
                 ³  delete  ³ (dynamically deallocates C++ storage) 


(), [], ->, ::, and ., are all listed as a part of 1. precedence is equal yes?

here is a partial precedence page from this web site:

http://en.cppreference.com/w/cpp/language/operator_precedence

1
2
3
4
5
6
7
8
Precedence	Operator	Description	Associativity
1	::	Scope resolution	Left-to-right
2	++   --	Suffix/postfix increment and decrement
type() type{}	Function-style type cast
()	Function call
[]	Array subscripting
.	Element selection by reference
->	Element selection through pointer


the "::" has first priority labeled next to 1 only
closed account (1CfG1hU5)
looking at your example
jt1 wrote:
he said in certain words that operator precedence had not changed. you need to reread previous message to find.


Again you are taking his quote entirely out of context. I put it in context (and actually linked to the quote you are referring to) in my reply. If you are unable to read then I cannot help you.

Again, MiiniPaa never once said or even implied that the Turbo C++ operator precedent chart was correct. In fact he has said the exact opposite numerous times. The only one who has been defending it is you.

And I still don't know how you even can... since they are clearly different. I mean all you have to do is look at the two side-by-side. AND I already pointed out several differences in my previous post.

I don't know what it will take to show you. I've literally pointed to everything I can.

shuttup disch, you conceited arrogant individual.


Being able to spot when someone is clearly wrong does not make me conceited.

In fact, I'm aware that I quite often make mistakes. The difference is, I don't get defensive and argue with people when they get pointed out.

Here are some past mistakes I've made (there are many more, but these are the first few I was able to find from a google search):
http://www.cplusplus.com/forum/general/10932/#msg51407
http://www.cplusplus.com/forum/general/141051/2/#msg745491
http://www.cplusplus.com/forum/beginner/27565/#msg147526

The only reason I'm being hostile with you is because you were hostile with Cubbi, and because you are stubbornly debating something that makes absolutely no sense. Your argument doesn't have a leg to stand on. You are clearly wrong.

you do not realize how incorrect you are for some reason.


Tell me one thing I've said in this thread that was not correct.

You probably won't be able to unless you take something out of context and/or misinterpret it -- which seems to be what you're best at.

here is a partial precedence page from c++ dos:


Yes... see how the () operator has highest priority?
Now... notice how it doesn't have highest priority in the standardized page?

They're different.
closed account (1CfG1hU5)
do yourself a favor disch, and lose yourself.
done with this post. on to other topics
Topic archived. No new replies allowed.
Pages: 1234