(5+6%4)
closed account (1CfG1hU5)
untrustworthy is same as not trustworthy
untrustworthy
adjective
1.
not worthy of being trusted
maybe visit an online dictionary or book
don't need "enlighten". i said type a small list.
maybe I will look at web page
i said nothing about the source being beloved. you're being extreme.
did I never type that i have visual studio? c++ dos is not my only compiler.
if I use my dos language. i am trusting the information for same
untrustworthy
adjective
1.
not worthy of being trusted
maybe visit an online dictionary or book
don't need "enlighten". i said type a small list.
maybe I will look at web page
i said nothing about the source being beloved. you're being extreme.
did I never type that i have visual studio? c++ dos is not my only compiler.
if I use my dos language. i am trusting the information for same
| untrustworthy is same as not trustworthy untrustworthy adjective 1. not worthy of being trusted |
| if I use my dos language |
I will give my proofs: name of the standards governing proper C++ are ISO 14882:1998, ISO 14882:2003, ISO 14882:2011 and ISO 14882:2014
Groan... how do I get pulled back into these. You are clearly arguing just for the sake of arguing because you apparently seem to like it. Unfortunately I kind of like it too... so let's butt heads some more.
No.... "can be wrong about anything" is pretty much the definition of "untrustworthy". They are not contradictory at all. Maybe you should read a dictionary.
How can you trust something that is frequently wrong and/or could be wrong about anything? Again I must turn back to my magic 8 ball example. Sure it's going to be right about some things... but does that mean you can trust it? Of course not.
To be trustworthy, something must be reliable. It must be consistently correct. Turbo C++ cannot possibly be consistently correct because it was created years before what was correct was actually established and documented.
Turbo C++ is not based on standards. There was no C++ standard back then. It didn't exist. So it's not that standards have changed, it's that they didn't exist.
And yes... some things in Turbo C++ are the same as they are in the C++ standard... but just as many (or more things) are not.
What's more... the standard has undergone at least 2 major upgrades since it was first established. So even the first standard isn't really worth anything any more. And you're talking about something that predates the first standard.
What you believe doesn't matter. The reality is you posted incorrect operator precedent information, then backlashed with inane arguments trying to justify your post when someone called you out on it.
EXACTLY. That is why this is so outrageous. Code that compiles and runs in Turbo C++ is very likely to not work when compiled in any other compiler. And vice versa -- standards compliant code likely will choke on Turbo C++. That's the reality of it.
Turbo C++ is so broken that it is not worth using. It cannot be trusted. It does things completely differently from everything else.
This is especially dangerous in the Beginners forum where you are telling newbies completely wrong information and leading them down a path of confusion.
You should be able to find a list of C++ operator precedence on Google. Also.. MiiNiPaa already posted a link to the actual precedence... but whatever. Here you go again:
http://en.cppreference.com/w/cpp/language/operator_precedence
Some differences between the actual precedence rules and the ones you posted:
1) Scope operator (::) has highest overall precedence
2) inc/dec (++/--) operators have higher priority when in suffix form rather than prefix form
3) member access (.* and ->*) operators have higher priority than multiplication/division
4) The ternary conditional operator (?:) does not have higher precedence than assignment.
You're the one who responded to Cubbi's gentle correction with sarcasm and "take your ridiculous arguments elsehwere. tired of worthless statements in these forums". The only one being ridiculous here is you -- not only clinging to a 25 year old compiler (so much so that you actually have to run it through an emulator -- I mean seriously, wtf)... but saying it's a trustworthy source for language rules and actually arguing to defend that absurd standpoint.
| jt1 wrote: |
|---|
| you said entire is untrustworty, and then later can be wrong about anything. one is contrary to the other. either entirely untrustworthy or partial. |
No.... "can be wrong about anything" is pretty much the definition of "untrustworthy". They are not contradictory at all. Maybe you should read a dictionary.
How can you trust something that is frequently wrong and/or could be wrong about anything? Again I must turn back to my magic 8 ball example. Sure it's going to be right about some things... but does that mean you can trust it? Of course not.
To be trustworthy, something must be reliable. It must be consistently correct. Turbo C++ cannot possibly be consistently correct because it was created years before what was correct was actually established and documented.
| lots of the dos turbo c++ is right today. some standards have changed. |
Turbo C++ is not based on standards. There was no C++ standard back then. It didn't exist. So it's not that standards have changed, it's that they didn't exist.
And yes... some things in Turbo C++ are the same as they are in the C++ standard... but just as many (or more things) are not.
What's more... the standard has undergone at least 2 major upgrades since it was first established. So even the first standard isn't really worth anything any more. And you're talking about something that predates the first standard.
| do not believe operator precedence could have changed much |
What you believe doesn't matter. The reality is you posted incorrect operator precedent information, then backlashed with inane arguments trying to justify your post when someone called you out on it.
| as c++ functionality would be severely different for example. |
EXACTLY. That is why this is so outrageous. Code that compiles and runs in Turbo C++ is very likely to not work when compiled in any other compiler. And vice versa -- standards compliant code likely will choke on Turbo C++. That's the reality of it.
Turbo C++ is so broken that it is not worth using. It cannot be trusted. It does things completely differently from everything else.
This is especially dangerous in the Beginners forum where you are telling newbies completely wrong information and leading them down a path of confusion.
| if you have a difference to prove, do a small list here |
You should be able to find a list of C++ operator precedence on Google. Also.. MiiNiPaa already posted a link to the actual precedence... but whatever. Here you go again:
http://en.cppreference.com/w/cpp/language/operator_precedence
Some differences between the actual precedence rules and the ones you posted:
1) Scope operator (::) has highest overall precedence
2) inc/dec (++/--) operators have higher priority when in suffix form rather than prefix form
3) member access (.* and ->*) operators have higher priority than multiplication/division
4) The ternary conditional operator (?:) does not have higher precedence than assignment.
| and go stuff your troll talk. i really don't give a crap |
You're the one who responded to Cubbi's gentle correction with sarcasm and "take your ridiculous arguments elsehwere. tired of worthless statements in these forums". The only one being ridiculous here is you -- not only clinging to a 25 year old compiler (so much so that you actually have to run it through an emulator -- I mean seriously, wtf)... but saying it's a trustworthy source for language rules and actually arguing to defend that absurd standpoint.
> the operator precedence is correct for the language c++ dos
For 'the language C++ dos'. Yes, it was probably correct for Turbo C++ in 1991 (Presumably Turbo C++, like C, did not allow assignment at the tail end of the conditional operator.)
There were only C++ dialects, but no standard C++ prior to 1998. What may have been correct for a particular pre-standard dialect of C++ in 1991 need not be what standard specified, years later, in 1998. <iostream.h> being perhaps the most well-known example of 'what was correct in C++ once upon a time'.
Whether a particular C++ construct was considered correct or wrong in 1991 is quite irrelevant today.
For 'the language C++ dos'. Yes, it was probably correct for Turbo C++ in 1991 (Presumably Turbo C++, like C, did not allow assignment at the tail end of the conditional operator.)
There were only C++ dialects, but no standard C++ prior to 1998. What may have been correct for a particular pre-standard dialect of C++ in 1991 need not be what standard specified, years later, in 1998. <iostream.h> being perhaps the most well-known example of 'what was correct in C++ once upon a time'.
Whether a particular C++ construct was considered correct or wrong in 1991 is quite irrelevant today.
closed account (1CfG1hU5)
not worth any trust is better. the trust? are you stating all trust? trust to extent relating
specifically to person and and condition(s).
c++ dos uses ansi standards. i believe iso standards were later.
specifically to person and and condition(s).
c++ dos uses ansi standards. i believe iso standards were later.
Last edited on
closed account (1CfG1hU5)
JLBorges
miini said "Operator precedence did not change. At all."
and turbo c++ 1.01 dos is dated 1990, not 1991.
c++ dos uses ANSI standards.
miini said "Operator precedence did not change. At all."
and turbo c++ 1.01 dos is dated 1990, not 1991.
c++ dos uses ANSI standards.
closed account (1CfG1hU5)
disch:
Groan... how do I get pulled back into these. You are clearly arguing just for the sake of arguing because you apparently seem to like it. Unfortunately I kind of like it too... so let's butt heads some more.
because you pull yourself into these arguments. you make your own choice(s). lol
Groan... how do I get pulled back into these. You are clearly arguing just for the sake of arguing because you apparently seem to like it. Unfortunately I kind of like it too... so let's butt heads some more.
because you pull yourself into these arguments. you make your own choice(s). lol
closed account (1CfG1hU5)
disch quoted:
You're the one who responded to Cubbi's gentle correction with sarcasm and "take your ridiculous arguments elsehwere. tired of worthless statements in these forums". The only one being ridiculous here is you -- not only clinging to a 25 year old compiler (so much so that you actually have to run it through an emulator -- I mean seriously, wtf)... but saying it's a trustworthy source for language rules and actually arguing to defend that absurd standpoint.
jt1 response:
24 year old compiler actually. c++ dos dated 1990. i will use my dos compiler as much as i please.
i also have visual studio 2013. miini said "Operator precedence did not change. At all."
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.
there are some extra chars in the list look like little 3's. will not take time to remove them. vertical line characters.
You're the one who responded to Cubbi's gentle correction with sarcasm and "take your ridiculous arguments elsehwere. tired of worthless statements in these forums". The only one being ridiculous here is you -- not only clinging to a 25 year old compiler (so much so that you actually have to run it through an emulator -- I mean seriously, wtf)... but saying it's a trustworthy source for language rules and actually arguing to defend that absurd standpoint.
jt1 response:
24 year old compiler actually. c++ dos dated 1990. i will use my dos compiler as much as i please.
i also have visual studio 2013. miini said "Operator precedence did not change. At all."
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.
|
|
there are some extra chars in the list look like little 3's. will not take time to remove them. vertical line characters.
Last edited on
Now that I think about it, multiplication and division on my old Commodore 64 BASIC interpreter had a higher precedence than addition and subtraction! The implications of that are awesome! I should be able to change the background color of my screen with "poke 53281,2", but VS 2013 won't compile it!. I'm gonna submit a bug report to microsoft and see if they plan on fixing that any time soon.
Did you actually read table you just posted? Scope resolution operator is not on top here. it shares precedence with some other operators which should be lower.
As does instructions for making drugs and commiting fraud.
| did you know source codes are available on web for dos compilers? |
closed account (1CfG1hU5)
the table posted is from c++ dos. the web page you pasted earlier has "::" operator at top.
Why did you write about avaliability of some source on internet?
If something is on internet it... does not prove anything at all.
And? Does this somehow miracluosly eliminates inconsistency?
Actually Turbo C++ implemented precendence correctly. It its help page which listed them wrong.
Your help is inconsistent with how compiler it should provide help for operates. That means that you cannot trust this help even working with Turbo C++ compiler.
If you can't win an argument, correct their grammar instead
Your posts are riddled with mistakes too, but I thought that it is not important.
If something is on internet it... does not prove anything at all.
| the table posted is from c++ dos. the web page you pasted earlier has "::" operator at top |
Actually Turbo C++ implemented precendence correctly. It its help page which listed them wrong.
Your help is inconsistent with how compiler it should provide help for operates. That means that you cannot trust this help even working with Turbo C++ compiler.
| as are, not as does |
Your posts are riddled with mistakes too, but I thought that it is not important.
Last edited on
closed account (1CfG1hU5)
those sources could be used to compile a c++ dos program which is considered too old a compiler by disch.
i make my own decisions about what i use or not whether disch approves or not.
you said in certain words that precedence did not change. disch argued opposite.
i did not declare a loss to argument
i make my own decisions about what i use or not whether disch approves or not.
you said in certain words that precedence did not change. disch argued opposite.
i did not declare a loss to argument
| you said in certain words that precedence did not change. disch argued opposite. |
| i make my own decisions about what i use or not whether disch approves or not. |
Just. Stop. Telling. New. Members. Outdated. And. Harmful. Information.
They do not deserve to be confused and taught wrong stuff.
@ jt1: Nobody cares about your argument since you have clearly defined yourself as a fool who won't let go of his point after being proven incorrect. The only thing left to do is warn other forum users that your posts are not to be trusted. Either wake up and listen to the voices of reason or stop wasting everyone's time!