174 replies to this topic

[fiberoptik]

Regarding "solve(23.4X^4=3.8)"

In my CP (os 1.24) the return is No Solution. But if i make x^4=(3.8/23.4) and then calculate the "4th root of ans" the result is correct (i don?t know how to write the root simbol here) ! Strange. no ?
Another strange thing, i tried this last calculation (4th root of ans), on my old FX-7700GB and it is much faster returning the result than my CP. I wonder why ?
I think that Casio has some serious issues to solve on CP.

Bye

[aero]

I hope in the new OS V2.00
that have contour plot
cause i need it

[R00KIE]

Regarding "solve(23.4X^4=3.8)"

Have you tried using fractions instead of 'floating point values' ?
like

solve((117/5)*x^4=19/5)

i don't have a CP or AFX but my experience tells me that calculator CAS don't like 'floating point values' when solving expressions, that is, they may return wrong results.

[m4x]

Hi all,

I've had my CP for some time now, and I've found such a thing:
(I don't know if this issue has already been posted, if so, sorry for repeating)

I've got the OS 1.24 and typed in my Classpad the folowing:
solve(x^2 + (2/x) - 8=0,x) and it returned {x=0.2520003852}
but there are 3 solutions of this equation.
I've multiplied both sides by x and received a polynominal with the same roots and typed it into Classpad like so:
solve(x^3-8x+2=0,x) and it returned correctly all three solutions:
{x=-2.945995202,x=0.2520003852,x=2.693994817}

When I've tried NumSolve in the Main like so
solve(x^2 + (2/x) - 8=0,x,-3,-inf,inf) it returned the first root only
{x=-2.945995202}
solve(x^2 + (2/x) - 8=0,x,3,-inf,inf) it returned the third root only
{x=2.693994817}

So CP is capable of finding other roots of the first equation, but it seems like it doesn't know that they exist and return only one. While with the polynominal there was no problem.

I've also tried a polynominal x^3-6*x^2+11*x - 6=0 with integer roots
{x=1,x=2,x=3}, divided it by x and typed in:
solve(x^2-6*x - (6/x) + 11=0,x) and CP returned correctly {x=1,x=2,x=3} so it might suggest that it happens when CP operates on irrational numbers.
I've tried it in CPLX and REAL and it's the same in both.
Sure hope this can be improved somehow.
Sorry for a bit longish post.

[TacoFred]

one quick question......
when doing definite integrations on CP, it takes minimum 20 seconds-ish to complete
when i did the same on my cfx 9850, it only took 2~3 seconds
if CP supposed to be faster, how is it so slow!?!?
does it use different method or does it just take longer because it is more accurate? (even so, it shouldn't take THAT much longer)
i need fast integration for school......

[Lovecasio]

Hi.
ClassPad is slow in some kinds of calculations because it uses algebraic methods. I don't have CFX 9850, but I know that it cannot give exact result in definite integral, it calculates integral by Simpson method (I think), while the procedure on ClassPad is: f(x) -> F(x) -> F(m)-F(n) ->simplify(recent value or expression). If you use numerical selection, ClassPad will be much faster in calculating integral.

[qwerty841]

when i upgraded my cp to os 2.0 the program backed up my data but it didn't put it back when it got done, so i lost some things.

[CrimsonCasio]

lists seem to have problems with Undefined too.

[qwerty841]

the other day i was using the statistics editor and i would have to type the numbers in kind of slowly because sometimes it wouldnt take the keypress if i did it too fast.

[PAP]

SERIOUS BUG: ClassPad (any OS version) is not able to integrate the function:
x sin(x) + x ln(x)
This is not a difficult function to integrate, even by hand. The problem seems to be the ln(x) function (if you replace it by, e.g., e^x, you get the correct result).
There is an obvious workaround: Integrate x sin(x) and x ln(x) separately, then add the answers. But the fact remains: this is a BUG, and should be corrected.
Does anyone in Casio takes into account the bugs reported here?

[PAP]

Integration problems: The function:
1/sqrt(tan(x))
cannot be integrated in ClassPad. This is a difficult integral. However, HP 49g+ is able to find the answer (which is a rather legthy and complicated function).
If you differentiate the correct antiderivative in ClassPad, you get a complicated answer. If you try to simplify it, ClassPad reports "Unsufficient memory".
I have also tested ClassPad in various integrals, and I have to say that I am not impressed, to post it nicely. Symbolic integration in ClassPad should definitely be upgraded!

[Lovecasio]

Does anyone in Casio takes into account the bugs reported here?

Yes, there is someone reads these posts.
I agree with you, integral calculation should be upgraded. I think the step that ClassPad does when calculating integral is : find F(x) -> Perform F( b )-F(a) -> simplify the result (if F(x) can be found). However, it is slow simplifying the result.
In the first version, it was not such slow.

[PAP]

Yes, there is someone reads these posts.

Is there an official ClassPad OS developement team or something similar? I have not found in this forum a single "official" post responding to user-reported bugs...
For example, the fact that "functions" are not able to return anything has been mentioned by many users in this forum the last two years. However, this fact, which is a very strong constraint, is still present in OS 2.0.

I agree with you, integral calculation should be upgraded. I think the step that ClassPad does when calculating integral is : find F(x) -> Perform F( b )-F(a) -> simplify the result (if F(x) can be found). However, it is slow simplifying the result.
In the first version, it was not such slow.

Actually, I was speaking about indefinite integrals (antiderivatives), i.e., integrals without limits. For example, the indefinite integral I mentioned before is:
/
|(x sin(x)+x ln(x))dx
/
and can be computed very easily. However, ClassPad left it unevaluated. I suspect that ClassPad's integration algorithms are buggy, especially for integrals involving the natural logaritm, ln(x). For example, the integrals
/
|(x sin(x)+x ln(|x|))dx
/
and
/
|(x sin(x)+x log(x))dx
/
are evaluated correctly. What's so difficult in the first integral? Nothing. Clearly, this is a bug.

[PAP]

There is a serious constraint concerning the solve function. For example, the list
{x+y=1,x-y=2}=>syst
is valid, but cannot be used in a solve statement:
solve(syst,{x,y}) is invalid, since it reports "Wrong Argument Type". It seems that the first argument of solve must be a list, not a variable, even if the variable is actually a list. Strictly speaking this is not a bug, but a serious constraint. I think it should be corrected in the next OS version.

[SoftCalc]

There is a serious constraint concerning the solve function. For example, the list
{x+y=1,x-y=2}=>syst
is valid, but cannot be used in a solve statement:
solve(syst,{x,y}) is invalid, since it reports "Wrong Argument Type". It seems that the first argument of solve must be a list, not a variable, even if the variable is actually a list. Strictly speaking this is not a bug, but a serious constraint. I think it should be corrected in the next OS version.

<{POST_SNAPBACK}>

Part of the problem is the parser is checking for the correct number of arguments in each list before evaluation. For example, solve({eq1,eq2,eq3},{x}) would be a "syntax" error that the parse picks up. I think some of these checks should be moved to the evaluation step and not the parse step. This would fix your issue.

A work around for now is solve({syst1,syst2},{x,y})

[PAP]

Part of the problem is the parser is checking for the correct number of arguments in each list before evaluation. For example, solve({eq1,eq2,eq3},{x}) would be a "syntax" error that the parse picks up. I think some of these checks should be moved to the evaluation step and not the parse step. This would fix your issue.

A work around for now is solve({syst1,syst2},{x,y})

<{POST_SNAPBACK}>

I agree with you. The problem is clearly the parser. The parser checks have similar problems in other circumstances as well. Let's hope that someone in Casio will hear your remarks. Thanks!

There is also another constraint concerning the solve function: It can be used for polynomials of the 3rd order or higher, but only if the polynomial coefficients are specific constants. Symbolic computation of the roots is possible only for polynomials of the 1st or 2nd order. For example, the function
solve(4 x^3-2 x^2+3 x+2=0,x)
works as expected. However, the function
solve(a x^3+b x^2+c x+d=0,x)
is left unevaluated. This is not a very serious constraint, but it is a constraint...
It is well known that the roots of polynomials can always be found for polynomials up to the 4th order (Evariste Galois proved that, for polynomials of the 5th order or higher, the roots can be found only in special cases). So, I think that the solve function should be able to compute the roots for polynomials up to the 4th order.

[PAP]

The Switch structure does not work as expected.
Assume that you have written a subroutine foo(x), implementing a simple use of the Switch structure:

Switch x
Case 1
 Print "First"
Case 2
 Print "Second"
Default
 Print "foo"
SwitchEnd

If x=1, this code should print "First", but it prints everything ("First", "Second", and "foo"). If x=2, it prints "Second", then "foo". In fact, everything after the current Case is executed, making it totally useless. The obvious workaround is to add a Break command at the end of each Case statements, but this makes the code longer, plus it is only a workaround for a structure which is clearly buggy. I personally prefer to forget Switch and use an If construct instead.
I cannot believe that this huge bug is still present after three (or more?) OS upgrades. Even the manual does not say anything about that.

[Nanard]

switch structure always do that, this is how it work.

[PAP]

switch structure always do that, this is how it work.

<{POST_SNAPBACK}>

It doesn't work properly then. See similar structures in any language (e.g., Fortran 95, or even Visual Basic). And, of course, the manual does not say that it "works" this way. As it is, Switch is simply nonsense. It could be useful if it worked as expected...

[2072]

It doesn't work properly then. See similar structures in any language (e.g., Fortran 95, or even Visual Basic). And, of course, the manual does not say that it "works" this way. As it is, Switch is simply nonsense. It could be useful if it worked as expected...

Sorry but as a programmer myself I can tell you this is how "Switch" works, this is not a bug... All languages work this way (C, C++, PHP, javascript, java etc...).

This allow you to bind a part of code to several cases....

In fact SWITCHes are just organized GOTOs, CASEs and DEFAULTs are labels.... So when you have a SWITCH SWITCHend block the interpreter just jump to the CASE corresponding to the switch argument or to DEFAULT if no CASEs match, that's all it does! When you want to leave the SWITCH SWITCHend block you HAVE TO use the Break command.

[SoftCalc]

It doesn't work properly then. See similar structures in any language (e.g., Fortran 95, or even Visual Basic). And, of course, the manual does not say that it "works" this way. As it is, Switch is simply nonsense. It could be useful if it worked as expected...

<{POST_SNAPBACK}>

Well, you're both right. it works this way in some languages, and different in others. Some languages execute the statement after the case and then exit. This was more common with old languages like Fortran and has carried over to their present day syntax.

C, C++, java, and the bulk of newer languages will only exit on a break. This is a common annoyance with some programmers and a sinkhole for bugs when forgetting to use the break.

[SoftCalc]

I agree with you. The problem is clearly the parser. The parser checks have similar problems in other circumstances as well. Let's hope that someone in Casio will hear your remarks. Thanks! 

I have it on good advice that this particular problem will be fixed in a future version of the OS. Let me know if you find other examples where the parser is trying to be too smart and the evaluator should be the one doing the validating.

...
solve(4 x^3-2 x^2+3 x+2=0,x)
works as expected. However, the function
solve(a x^3+b x^2+c x+d=0,x)
is left unevaluated. This is not a very serious constraint, but it is a constraint...

It looks like the TI-89 has the same constraint. The main reason is because the result is so huge and complex that it isn't very unusable. Maple will solve a general 3rd order polynomial, but the result takes over a page on my computer screen. Still, I could see an argument for solving 3rd order symbolic polynomials in the ClassPad.


As far as 4th and 5th order symbolic solutions, the result is so complex it is all but unusable. Maple will not even solve for or display the result of a 4th order solution. in Maple...

solve(a*x^4+b*x^3+c*x^2+d*x+e=0,x); => RootOf(a*_Z^4+b*_Z^3+c*_Z^2+d*_Z+e)

[PAP]

Sorry but as a programmer myself I can tell you this is how "Switch" works, this is not a bug... All languages work this way (C, C++, PHP, javascript, java etc...).

<{POST_SNAPBACK}>

Sorry, but I'm also a programmer more years than you (provided that your profile is correct). Switch works as you said only in the languages you are programming. However C, C++, and Java are not "mathematical" languages. C++ is ideal for making operating systems, or windows applications, or games, but it sucks when used to solve mathematical problems. Two examples: matrix manipulation in C++ is a headach (while in Fortran 95 is a piece of cake), complex arithmetic is supported only by external libraries (in Fortran, complex arithmetic is part of the language for more than 40 years) - the list of mathematical structures available in Fortran 95 but not in C++ is very lengthy. As far as mathematical applications are concerned, there is no language that can be compared to Fortran 95. This is probably the reason that large mathematical applications, such as Mathematica, Matlab, Scilab, Octave etc, have copied many Fortran 95 structures. What they have copied from C? Almost nothing (just the "printf" and "readf" commands).
C++ is simply "a la mode", so many people started to use it even for mathematical applications, i.e., they started to reinvent the wheel. I'm writing numerical analysis programs the last 15 years, and I never do it in C++, because the wheel has been invented many centuries ago.
Now, all mathematical applications mentioned above have a structure similar to Switch, which works as in Fortran 95: the corresponding case block is executed, and that's all. No need to Break. This is how it works in all (I repeat, all) mathematical languages. I'm not surprised that it doesn't work like that in C++, because C++ has many bugholes. Now, ClassPad is not made to write games or operating systems. ClassPad is a CAS calculator, so its basic should be similar to a mathematical language. Conclusion: The Switch structure doesn't work as it should.

In fact SWITCHes are just organized GOTOs, CASEs and DEFAULTs are labels...

Need I to add anything? "organized" GOTOs in a modern language? No, thanks.

[2072]

Sorry, but I'm also a programmer. Switch works as you said only in the languages you are programming. However C, C++, and Java are not "mathematical" languages. C++ is ideal for making operating systems or windows applications or games, but it sucks when used to solve mathematical problems.

Well I wasn't speaking about "mathematical" languages and Classpad BASIC as its name says is inspired from BASIC...

In fact SWITCHes are just organized GOTOs, CASEs and DEFAULTs are labels...


Need I to add anything? "organized GOTOs" in a modern language?  No, thanks.

I was just speaking about the internal way it works, I hate GOTOs too...

Do you know GOTO++ ? http://gpp.niacland.net/index.html.en I'm sure you'll like it

[PAP]

Let me know if you find other examples where the parser is trying to be too smart and the evaluator should be the one doing the validating.

I will, of course. The problem is that, although I have found some parser-related problems during programming, I don't remember where exactly, because I don't keep notes. My fault.

The main reason is because the result is so huge and complex that it isn't very unusable. Maple will solve a general 3rd order polynomial, but the result takes over a page on my computer screen. Still, I could see an argument for solving 3rd order symbolic polynomials in the ClassPad.
As far as 4th and 5th order symbolic solutions, the result is so complex it is all but unusable. Maple will not even solve for or display the result of a 4th order solution.

The result is complex indeed, but not so huge, at least in Mathematica (as far as I know, Mathematica is better than Maple in symbolic computations). It is also usable, I needed it recently. In this case, Mathematica gives general solutions for both 3rd and 4th order symbolic polynomials. 5th order symbolic polynomials cannot be solved (except for special cases), so Mathematica does not give any solution as well.
Anyway, I agree with you. There is an argument for solving 3rd and 4th order symbolic polynomials in the ClassPad, but it is not a strong one. I think that there are other, more important, things that are missing.

[PAP]

Well I wasn't speaking about "mathematical" languages and Classpad BASIC as its name says is inspired from BASIC...

I think that even in Visual Basic it works as I said, without breaks...

Do you know GOTO++ ? http://gpp.niacland.net/index.html.en I'm sure you'll like it

<{POST_SNAPBACK}>

Funny link, thanks . I speak french, I will browse its pages.

[SoftCalc]

Sorry, but I'm also a programmer more years than you (provided that your profile is correct).

No offense, but year programming <> programming experience. I've seen some extremely bright and talented programmers that are young enough I could be their father.

Switch works as you said only in the languages you are programming. However C, C++, and Java are not "mathematical" languages. C++ is ideal for making operating systems, or windows applications, or games, but it sucks when used to solve mathematical problems.
...

The switch statement really has nothing to do with whether it's a mathematical language or not, any more than the if statement?

I think that even in Visual Basic it works as I said, without breaks...

Last I checked Visual Basic wasn't a mathematical language any more than C or C++. I also noticed that TI-89 doesn't have a switch/case programming structure at all.

In fact SWITCHes are just organized GOTOs, CASEs and DEFAULTs are labels...

Need I to add anything? "organized GOTOs" in a modern language?  No, thanks.

Well for that matter if-then-else and loops are all just orginized GOTOs. Isn't that the idea? They are structured gotos which enforce some type of structured programming.

I actually agree with you. I never liked having to put the break at the end of the case. My feeling is 99% of the time you want the break, so why force someone to add it? The other 1% is probably a situation that involves bad programming style anyway and will confuse the hell out of anyone reading the code My feeling is it's a bug waiting to happen. I never liked it, and think any newer language should expunge the whole idea of requiring an explicit break.

That being said, switch/case statements really are a widely accepted control structure and are considered to be good programming style. The fact that a language like java implement switch/case statements in a similar way to the ClasPad and java is a highly structured, modern language shows it isn't completely crazy.

Arguing over the case/break issue spans beyond the ClassPad into many modern languages. This single topic could fill an entire forum with opinions. In fact there are many a forum/blog that do just this. Is it really worth any time debating this? Is this that big of an issue? (for that matter why have I spend so much time on this issue. ) What it all comes down to is preference.

[SoftCalc]

I will, of course. The problem is that, although I have found some parser-related problems during programming, I don't remember where exactly, because I don't keep notes. My fault.

What, you don't have all the quirks of the ClassPad syntax committed to memory? if you do ever come accross something as trivial as this let me know.(when I say trivial I don't mean a trivial issue, I mean something that could be fixed with a trivial change). Who knows, things that only involve a simple code change might end up in the next OS.

[PAP]

Last I checked Visual Basic wasn't a mathematical language any more than C or C++.

I never said that Visual Basic is a mathematical language, because it is not, definitely. I was just aswering to the argument "ClassPad basic is inspired from Basic": even so, the Switch structure does not work as expected. Anyway, I have found my personal workaround: I will never use Switch in ClassPad, as it is now...
I totally agree with SoftCalc. There is no reason for debating: I personally hate C++, but you may love it. You may even try to write mathematical applications in C++ or Java (it can be done, but it is painful).

I also noticed that TI-89 doesn't have a switch/case programming structure at all.

btw, is there any good pc emulator for TI-89 or Voyage 200? I have one for HP49g+ that works perfectly...

[SoftCalc]

I totally agree with SoftCalc. There is no reason for debating:

But wait... I'm not finished...I have at least 3-4 more posts on the topic.

..is there any good pc emulator for TI-89 or Voyage 200? I have one for HP49g+ that works perfectly...

There is a program called VirtualTI that can emulate nearly the entire line of Texas Instruments graphing calculators...

http://www.ticalc.or...fo/84/8442.html

For both the TI and HP emulators you'll need a ROM image. Luckily, you can download the ROMs directly from TI's website. Also HP has made the ROMs of many of their calculators public and can be downloaded at http://www.hpcalc.org/

NOTE: There are also PocketPC and PalmOS version of both emulators. Now if I could only port both emulators to the ClassPad.

[PAP]

There is a program called VirtualTI that can emulate nearly the entire line of Texas Instruments graphing calculators...

http://www.ticalc.or...fo/84/8442.html

For both the TI and HP emulators you'll need a ROM image. Luckily, you can download the ROMs directly from TI's website.

Cool! Many thanks!
I'll try it tomorrow (it's 2:00am here, and this test will take a lot of time...)

[SoftCalc]

I'll try it tomorrow (it's 2:00am here, and this test will take a lot of time...)

<{POST_SNAPBACK}>

Test, or play with. I have a feeling you won't be posting much tomorrow. Have a good night.

[2072]

I actually agree with you. I never liked having to put the break at the end of the case. My feeling is 99% of the time you want the break, so why force someone to add it? The other 1% is probably a situation that involves bad programming style anyway and will confuse the hell out of anyone reading the code My feeling is it's a bug waiting to happen. I never liked it, and think any newer language should expunge the whole idea of requiring an explicit break.

<{POST_SNAPBACK}>

Here is complete Switch() {} from one of my C program where an implicit Break would have been very problematic:

switch (key)
{
    case 0: break;
    case K_LEFT:	case GK_LEFT:
     c--; break;
    case K_RIGHT:	case GK_RIGHT:
     c++; break;
    case K_SHIFT:	case K_F1:case GK_SHIFT:case GK_F1:
     gotoxy(holdc,w); printf("W");
     gotoxy(c+1 +rwidth,w); printf(read_char(142), b);
     waitforkey(K_SHIFT, K_F1, 0); wait_fornokey();break;
    case K_ESC:case GK_ESC:case K_ESCAPE:
     allreadytest=0; clear_key_buf(); SAVE_NUM_HEX_STAT; return;
    case K_DOWN:case GK_DOWN:
     waittime-= (waittime>100) + 99;
     gotoxy(c+1 +rwidth,w); printf(read_char(143), waittime); break;
    case K_UP:case GK_UP:
     waittime+= 1 + 99;
     gotoxy(c+1 +rwidth,w); printf(read_char(143), waittime); break;
    case K_D:case GK_D:
     p=(p==0); gotoxy(c+1 +rwidth,w); echoDATstr(144);
     printf(p?read_char(145):read_char(146)); wait_fornokey();break;
    case K_S:case GK_S:
     gotoxy(c+1 +rwidth,w); printf(read_char(147));
     waittime=(unsigned int)number(65535l); b=0; break;
    case K_L:case GK_L:
     gotoxy(c+1 +rwidth,w); echoDATstr(149);
     newrwidth =(unsigned int)number(99);
     width_changed = (int)(rwidth - newrwidth);
     rwidth = newrwidth;
     rwidth=rwidth * (rwidth < xmax - 1)
  + 2 * ( !(rwidth < xmax - 1) || rwidth<2); b=0;
     break;
    ?default:;
}

How would have I done it if Switch CASE worked like in Fortran?


(Note that some variable name are horrible because it's the translation of a CASIO basic game I made a very long time ago...)

[PAP]

Here is complete Switch() {} from one of my C program where an implicit Break would have been very problematic:
........ your code ........
How would have I done it if Switch CASE worked like in Fortran?

Correct me if I'm wrong, but, in your code, every case block has a break, except for the 5th (ESC' /> pressed). Even in this case, however, there is a return. If I remember well, return stops function's execution immediately, returning to the calling program. What's so problematic? Anyway, I give 2 solutions: (1) if you want the function to stop executing if the 5th case is satisfied, or (2) if you want to continue with the other cases, even if the 5th case is satisfied.
First, let me say this: you can't implement this code in Fortran 95 directly, because Fortran does not support key pressed detection, gotoxy, etc. As I said before, it is not made for games (although you can add these features by using external Fortran game libraries - yes, there is such a thing). Fortran has no competitors, as far as mathematical structures are concerned, but game programming is not Fortran's strong point. That being said, here are the solutions:

(1) In the first case, you don't have to do anything special to implement this code in Fortran 95: just remove the breaks (on leave them, they are useless in Fortran, but they are not a syntax error). It will work almost as-is in Fortran (apart from the slightly different syntax), and the code will be shorter. For example, the 5th case is very similar in Fortran 95:

case (K_ESC,GK_ESC,K_ESCAPE)
  allreadytest=0; call clear_key_buf(); call SAVE_NUM_HEX_STAT; return

(2) Even if you didn't wanted to return if the 5th case is satisfied, you can still implement this in Fortran easily. If you need the code after the 5th case to be executed even if ESC' /> is pressed, you remove the 5th case, and add K_ESC,GK_ESC,K_ESCAPE in all cases after the 5th, together with the call of a subroutine (say, "EscPressed") that executes the 5th case block. For example, the last case becomes:

case (K_L,case GK_L,K_ESC,GK_ESC,K_ESCAPE)
  call EscPressed()
  ........ rest your code ........

As you can see, it can be done (and I think that is more structured this way). Trust me, Fortran 95 is not a poor language, as many C++ programmers think. It is "module-oriented", instead of object-oriented, but this is not a disadvantage: Compared to object-oriented programming, module-oriented programming has all the reuse without all the abuse.

[2072]

ok I didn't know it was possible to write something like this in Fortran:

case (K_ESC,GK_ESC,K_ESCAPE)

Since the above is possible I understand why Break are not needed in Fortran... But such syntax doesn't exist in Casio BASIC, C, etc... so Break commands are needed so you can achieve to the same result by writing "case K_ESC:case GK_ESC:case K_ESCAPE:".

First, let me say this: you can't implement this code in Fortran 95 directly, because Fortran does not support key pressed detection, gotoxy, etc

standard keypress functions don't work with the CASIO AFX, I had to rewrite my own, the gotoxy() function is very simple to rewrite if needed.

Trust me, Fortran 95 is not a poor language, as many C++ programmers think.

I've never said such a thing (and I don't use C++ )