C++ What is and isn't implemented in the Arduino IDE

Dyslexicbloke:
Is there documentation somewhere that will tell me what parts of C++ are and aren't implemented.

sprintf being a prime example ...

One thing that will help in your searching is to understand that the compiler, the language, and the run-time libraries are three distinct entities.

sprintf is a function in the C(++) run-time library. It's only connection to C(++) is that it is included with most toolsets. I've actually used sprintf in a Pascal program.

The Libc (run-time libraries included with the AVR port of GCC) documentation can be found here...
http://www.nongnu.org/avr-libc/

That all sounds perfectly reasonable and I am well aware of the physical limitations.

AVR-gcc implementation of the compiler and library ? It sounds as though I should know what that is and I suspect that it is only the tip of the iceberg.

Clearly the terminology I used isn't correct, what I need to know is what is available in a standard Arduino IDE, irrespective of how it got there, that comes later.
I am sure that if I went looking for C++ solutions on Google I would find loads of solutions many of which don't work/arn't implemented in the Arduino IDE.

I am more than happy to do the research and reading but I don't know what to look for to get me started.
In fact I am far more concerned about asking silly questions that I could have answered by doing a bit of reading.

sprintf ... in other places, I was a little confused I think I have used it in php

Thanks for the link and the pointer to look into libs, that will be easier now I have an idea where to look
I am really green at this, I only just discovered that I can look at a library file in the IDE, they don't format well in notepad ... Oops

Cheers
Al

The Libc (run-time libraries included with the AVR port of GCC) documentation can be found here...
AVR Libc Home Page

Thanks for that! The Language Reference on the Arduino website seems very abbreviated.

sprintf is a function in the C(++) run-time library. It's only connection to C(++) is that it is included with most toolsets.

Actually, sprintf() is part of the official ANSI/ISO C and C++ language standards.

Also the microcontroller being based on the classic Harvard computer architecture is probably another 'restriction'?

Wouldn't think so. About the only place this would show up would be the fact that pointers to functions are in a different address space as pretty much all other pointers (PROGMEM would be in the program address space as well). Even so, I don't see this added twist make pointers much worse than they already are. :slight_smile:

I've actually used sprintf in a Pascal program.

Weren't you afraid you'd cause the world to end when you ran it? :expressionless:

-j

The Language Reference on the Arduino website seems very abbreviated.

Arduino doesn't have its own language actually, that's just a set of utility functions (I'd call them the Arduino API) which make it easy to interface with the Arduino hardware.

It wouldn't have made sense to write a "language reference" page where Arduino specific stuff would've been lost in yet-another-c++-reference.

:slight_smile:

I am not afraid to say that I am finding the avr-libc link very hard going ....
Not understanding the constructs doesn't help either.

Someone just suggested, as an answer to another question, that I define a function, at least I think that is what the line of code is doing.

I am really struggling with what can be done and how to go about it, I guess its all part of learning a new skill.
It will only get better and easier as I go, its the getting started that stings.

SO ... Am correct in thinking that I should look at a C++ reference for possible solutions to problems and then check if those solutions are implemented in avr-libc?

I would choose a C reference, instead, like K&R or Harbison and Steele.

And then check the reference for any variations to the standard. Most will be in large functions (like sprintf()!) and floating point.

Note, it depends on what compiler you are using. For example, on Linux (Fedora) if I install the arduino software via the yum repository, compiler is fairly new (4.6-ish), while if I use the compiler that is supplied with the Arduino 1.0.1 tarball, it is rather old (4.3.2) which is several years old, and 4 major revisions out of date. A lot has changed in the C++ world since 2008.

I am using Arduino 1.0.1 in windows 7 (64) but I think I am a long way from attempting to get to grips with a different OS or compiler variant.

It has been suggested that I might be better with Eclips with the Arduino plugin but I am concerned about stepping too far outside the norm until I have a more than a rudimentary understanding of what I am trying to work with.

I have managed, with a great deal of help from board members, to build a my first simple library but I have a long way to go.

One thing you should probably understand is what is even meant by IDE, mainly because the only part of the Arduino IDE that's actually 'Arduino' is the editor. The underlying library is AVR Libc, which you've been introduced to, the compiler is gcc, an open source compiler with an AVR compatible implementation, and avrdude is the program used to download the compiled binaries to the microcontroller.

If your real goal is to become proficient at programming, your best avenue honestly is to focus on learning C++ on the PC. Remove the microcontroller from the equation. Once you are proficient with C++ on it's own, it'll be far easier to make the transition to programming in the AVR environment. There are far more resources for learning C++ than there are for learning AVR programming. And honestly, a high percentage of the 'tutorials' out there for AVR programming are real good examples of how not to do things.

sprintf atoi, print, getc (from stdio) sin(), random() and anything that requires you to include a ".h" file (in plain c/c++) are NOT part of the language .

They are lib's supplied with language, they may be defined in the standards but they are still just add ons .

If you look at the language the syntax does not say ant thing about them.

Mark

holmes4:
sprintf atoi, print, getc (from stdio) sin(), random() and anything that requires you to include a ".h" file (in plain c/c++) are NOT part of the language .

They are lib's supplied with language, they may be defined in the standards but they are still just add ons .

If you look at the language the syntax does not say ant thing about them.

Mark

Wrong. The C standard defines two levels, hosted and freestanding. The freestanding environment does not include a library, but the hosted level does include a full library definition. I was on the original C standards body (X3J11) from its inception through the first C standard (the 1989 ANSI standard for the US, and the 1990 ISO standard for the whole world). The C99 standard defines some 250 pages of text describing the libraries.

I believe the C++ standard is similar, in that it provides a full library. Now in environments like the Arduino, you get a subset of the full library, but the standard does specify the library.

jraskell,
that sounds like a great plan, in fact it is probably the only truly sensible plan but unfortunately it just isn't going to cut it.

I have systems that need new automation due to changes and additions.
Fortunately the tasks are not that onerous and I will get away with clunky programming if I have to.
I defiantly don't have clunky as a goal or even a long term acceptable solution but if needs must it will do for now.

I just bought a couple of Nanos so I can build some simple modules, PWM charging control for the PV's being the most pressing.
Having a couple of boards to hand will allow me to keep experimenting and learning whilst one of them gets on with something important.
Measuring a voltage and a few currents whilst driving a few FET's isn't going to be taxing but I don't want to be messing with a live system that has the fate of my batteries in its grasp.

It wouldn't have made sense to write a "language reference" page where Arduino specific stuff would've been lost in yet-another-c++-reference.

But it would make sense to extend the reference to other available functions and refine the documentation when useful. For example the Serial.print is used a lot, but not covered in the reference. Same for the String library. And some indications on how the selection of libraries etc. has an impact on the usage of memory would also be great...

A lot has changed in the C++ world since 2008.

Any pointer that explains the major differences between 2008's avr-gcc 4.3.2 and 2012's 4.7.2 ?

Of course there is gcc.gnu.org, where 4.7.2 changes page says (as an example)

The AVR port's libgcc has been improved and its multilib structure has been enhanced. As a result, all objects contributing to an application must either be compiled with GCC versions up to 4.6.x or with GCC versions 4.7.0 or later.

Support has been added for the AVR-specific configure option --with-avrlibc=yes in order to arrange for better integration of AVR-Libc. This configure option is supported in avr-gcc 4.7.2 and newer and will only take effect in non-RTEMS configurations. If avr-gcc is configured for RTEMS, the option will be ignored which is the same as specifying --with-avrlibc=no. See PR54461 for more technical details.

Support for AVR-specific built-in functions has been added.

but this is probably Chinese for most Arduino users. And it only covers the latest differences.

MichaelMeissner:
For example, on Linux (Fedora) if I install the arduino software via the yum repository, compiler is fairly new (4.6-ish), while if I use the compiler that is supplied with the Arduino 1.0.1 tarball, it is rather old (4.3.2) which is several years old, and 4 major revisions out of date.

I notice that the Arduino 1.5beta released yesterday also uses avr-gcc-4.3.2 for the AVR architecture, and arm-none-eabi-gcc-4.4.1 for the SAM architecture.

For example the Serial.print is used a lot, but not covered in the reference.

Except here:

which is linked to on the main page.

Same for the String library.

Exactly the same:

under Data Types, String - object.

And some indications on how the selection of libraries etc. has an impact on the usage of memory would also be great...

They all use some. 8) OK, that's covered.

I definitely need glasses :frowning: there are even 2 strings on that page...

Hi Dyslexicbloke, I think this can help you:

It's a multimeter kit sold by Sparkfun and while it's not Arduino, the processor is the same (ATMega328). The great thing here is the source code. Is included in that site.

Cheers!

Dyslexicbloke:
sprintf being a prime example ...
I found it quite by accident and then discovered that the Arduino implementation is limited with respect to its standard form.

As far as I know, the only "problem" with sprintf (and sscanf) is that the default library excludes the floating point code in order to save space.

For what I do, I NEED floating point support, so I "patched" my "libc.a" files to remove the "standard" sprintf and sscanf code and replace it with the floating point version.

It does make the resulting sketches about 1.5K larger, but that's never been a problem for me (so far).

In case you are interested, here's a script to automate "fixing" libc.a to support floating point:

#!/bin/bash
################################################################################
# fixfp - script to install floating point support into Arduino printf library
#
# For more information, see this post:
# http://arduino.cc/forum/index.php/topic,124809.msg938573.html#msg938573
################################################################################

STATUS=0

## Exit if libc.a isn't here
test -e libc.a
if [ ${?} -ne 0 ]; then {
        echo "File 'libc.a' not found - exiting"
        exit 0
} fi

test -e libc.a.orig
let STATUS+=${?}

test -e vfprintf_flt.o
let STATUS+=${?}

test -e vfscanf_flt.o
let STATUS+=${?}

if [ $STATUS -eq 0 ]; then {
        echo "Floating point patch already performed - exiting"
        exit 0
} else {
        cp libc.a libc.a.orig
        ar -dv libc.a vfprintf_std.o
        ar -dv libc.a vfscanf_std.o
        ar -xv libprintf_flt.a vfprintf_flt.o
        ar -xv libscanf_flt.a vfscanf_flt.o
        ar -rv libc.a vfprintf_flt.o
        ar -rv libc.a vfscanf_flt.o
        echo "Floating point patch installed."
} fi

Hope this helps...