My one great desire...

O

oric_dan

Well-known member
This isn't actually such a world-shaking suggestion .... however

What I would really like to see is the "errors" in the Teensyduino verbose output compile window being shown in a different color from the "warnings". IE, every one of my programs shows dozens if not 100s of the following totally useless warnings, and any actual errors are buried in the pile, and it takes endless amounts of wasted time to find them, starting with blowing the IDE up to fill the entire screen so you can even read the lines. Foo.
Code: 
warning: deprecated conversion from string constant to 'char*'
 
The better way is to fix the warnings...
In general, warnings are not printed "just for fun".
 
Last edited:
When faced with that, I copy the entire IDE output, paste it into a text editor and then search for the word "error".

Pete
 
oric_dan said:
What I would really like to see is the "errors" in the Teensyduino verbose output compile window being shown in a different color from the "warnings".
Click to expand...

The warnings are supposed to show as white text and the errors as red. Like this:

sc2.png
 
Can you give me a screenshot of how the errors are warnings are actually appearing on your screen?

Hopefully you could do this with a relatively small program you can post here, and tell me which operating system and software version, so I can try to reproduce the problem here.

The really are supposed to print in different colors, exactly as you have wished. I would like to know why they're not.
 
oric_dan said:
Code: 
warning: deprecated conversion from string constant to 'char*'
Click to expand...
You often get this type of message if your code has something like:
Code: 
void myfunc(char *string_pointer) {
...
}
...
   myfunc("ABCD");
You can often get rid of the error if you change myfunc like:
Code: 
void myfunc(const char *string_pointer) {
...
}
...
   myfunc("ABCD");
Which tells the system you are not going to try to change the string...
 
Oh darn, this is kind of one of those "never mind" sort of things. I've been using the older Teensyduino install (v1.24 on IDE v1.0.6, left side of attachment) so much with my T3.1 modules that I hadn't noticed things had changed on the newer installs (v1.32a on IDE 1.6.13, right side of attachment). However, there are still some weird things.

The attachment shows the same sketch compiled in each version of Teensyduino. I added some obvious warnings and errors. In the new version, the errors are indeed shown in a different color from the warnings, although the formatting uses a large amount of blank space. And now the warnings are the same color as the compile statements. Strange. I don't know if that's better or not.

Also,
You can often get rid of the error if you change myfunc like:
Code:
void myfunc(const char *string_pointer) {
...
}
...
myfunc("ABCD");
Click to expand...
Kurt was right about this. Cf lines 2 and 3 in the sketch, the deprecated char* warnings disappear on adding "const". Now to add this to 10,000 places in my programs :).

When faced with that, I copy the entire IDE output, paste it into a text editor and then search for the word "error".

Pete
Click to expand...
Yeah, that's what I have been doing for ... many ... years.

EDIT: using Win10 here.
 

Attachments

  • test1.jpg
    test1.jpg
    113.9 KB · Views: 134
Last edited:
As Frank says the correct thing to do its correct the warnings... in code.
I've been programming since 13 years old in assembler, C, C++, Pascal, Perl, Java, ASP, PHP, bash and so many languages I don't even remember (and I will like to be a 1/100 Paul).
I have done alone projects of more than 40000 lines of code and didn't see 100 warnings more than a few times. And most of the times when you have that high warnings count usually involves a single mistake.
Given the limited rom and ram space of Teensy compared with a regular PC, having that amount of non corrected warnings in a such small platform speaks really bad about your coding habits and standards.
Do you have 10000 functions definitions in a sketch for a 256K MCU?.
Are you sure you are not being a little bit hyperbolic speaking?

Luis M.
 
Yup, professional developers treat warnings as errors, and there's a compiler-switch to do this:

-Werror

That's a good practice.
Warnings may lead to unexpected behavior.
 
Frank and Stendall, you guys are both right. I normally go through and ultimately clean up my programs until all of the warnings have been taken care of, except for that deprecated char* warning, of which there may be 100s in my larger programs. But if I implement Kurt's fix, then that should go away too.

But I'm not sure, if a usage has been deprecated, it seems to me that's a matter of "style", and a not possible compile error. But I'm probably wrong.
 
In this case, I think it is a bit more than just style.

It may be more also depending on how the compiler handles the string constants.

That is in my case above:
Code: 
void myfunc(char *string_pointer) {
...
}
...
   myfunc("ABCD");
if inside of myFunc I did something like:
*string_pointer = 0;

If the string constant is held in RAM than this will function, if it is held in Program space it will fault the processor... I think now it is kept in program space.

The reason I knew about that warning was I was lazy for awhile and took my time fixing them.

Now as a "Retired" professional programmer I can be lazy again ;)

Also sometimes I get lazy on how to remove warnings. Ones like, variable may be used before it is set (paraphrased), even though you know by the logic it can not happen.
I get lazy and do something like uint8_t myvar=0;
Which generates fatter code.

I hate having to look for all of those ... Pragma or attribute statements. Like if you wish to pop something off of SPI stack, if you ignore the results compiler complain, likewise if you assign it to a variable that is not used it complains... So you look it up to find something like:
uint32_t tmp __attribute__((unused)) = SPI0_DL;
...
 
Seems to me there has always been a problem between declaring something as char *x and char x[] with the C language, so sometimes the programmer has to think about what he's doing, ha. Eg, in the following sketch, the compiler has caught the error at line 13, but it compiles fine if line 13 is commented out. OTOH, it seems to me that lines 19,21,23,25 will crash at run time. Deprecation, or no.
 

Attachments

  • test1a.jpg
    test1a.jpg
    129.5 KB · Views: 124
oric_dan said:
The attachment shows the same sketch compiled in each version of Teensyduino. I added some obvious warnings and errors. In the new version, the errors are indeed shown in a different color from the warnings, although the formatting uses a large amount of blank space. And now the warnings are the same color as the compile statements. Strange. I don't know if that's better or not.
Click to expand...

The newer compiler versions print the actual line of source code after the error, then a line with a "^" which is meant to point to the exact location on the line where the error occurs, and then a blank line which is probably meant to help you visually see the "^". Maybe?

I'm also not sure if it's better or not.

In an ideal world (with a *lot* more hours in every day) I've considered trying to add GUI elements to Arduino's lower panel. Ideally this ascii art text from the compiler could be replaced with something much better with real graphics. All the extra info could be hidden under a little more/less button that expands the info and highlights the source line in Arduino's editor. Links to "help with this error" could open up (ideally) well written help for the most common causes and suggestions for troubleshooting errors and warnings, and in a really ideal situation such help could get some context cues from the source code to prioritize which help to show first.

But for now, I'm working on EHCI USB, and then a long list of minor issues, and then probably some improvements to Wire, and Ethernet, and improving the website..... seems unlikely such work on the Arduino IDE will happen anytime soon, at least by my hand...


Kurt was right about this. Cf lines 2 and 3 in the sketch, the deprecated char* warnings disappear on adding "const". Now to add this to 10,000 places in my programs :).
Click to expand...

For this particular warning, you likely have 10,000 places that pass string constants to just a few functions defined with (non-const) char * inputs. Of course this is a guess without seeing your code, but there's a good chance adding const to a relatively small number of function inputs will make a huge number of "deprecated conversion from string constant" warnings disappear.
 
Last edited:
For this particular warning, you likely have 10,000 places that pass string constants to just a few functions defined with (non-const) char * inputs.
Click to expand...
Paul, you and Kurt may be right. Since Rduino IDE doesn't have a nice printf() type of function like normal C, I have been using 12-15 of my own specially-defined utility fcns in various forms that look as follows:
Code: 
/* trivial printf for string/integer/string/integer display. 
*  - usage:  print_sisi("...", -123, "...", 456);
************************************************************/
void print_sisi( const char* s1, int num1, const char* s2, int num2 )
{
   dbg.print(s1);  dbg.print(num1);
   dbg.print(s2);  dbg.print(num2); 
}

- earlier on, I have:
#define dbg   Serial1
So, I just changed all of the char* to const char* as shown above in this set of fcns, and it reduced the number of
Code: 
rem.ino:582: warning: deprecated conversion from string constant to 'char*'
warning statements in my most-used program from 271 down to 145. There are only 5 other warnings in the current program. So, if I keep hacking away it should reduce these a lot more.

For reference, that program has 22 .ino and .h source files, and probably 150 pages of source code. The compile window dump has 418 lines, so reading through it looking for errors has been a PITN.

For edification, when I mentioned 10,000 places, I was originally referring to my dozens and dozens and dozens of sketches. So, not quite pure hyperbole, :).
 
Yup, with Teensy you can use Serial.printf("number = %d\n", num);

The printf support is in the Print class inherited by almost all displays and other things that use print, so you can use it with those too.
 
Wow. And some of us have long dreamed of having an atan(), LOL. I notice there is both
- double atan(double x);
- float atanf(float x);
and I assume the 2nd makes use of the T3.6 FPU, maybe?

Would be nice to have a summary page on pjrc.com that lists all of the really cool advanced features that Teensyduino has, and not found in the usual Arduino distos.
 
If the FPU supports atanf somehow yes, then it makes use of it. I don't know! - maybe run a benchmark or take a look at the assembler-output ?
But i guess, the answer is "yes"
 
You must log in or register to reply here.
Back
Top