next topic »

[Reply #15 on:]

you can do pretty-much anything.

So you can define your own classes in a pde/ino file? As I say, I never tried, but I was under the impression you had to create a seperate .cpp file to do that.

Whatever it is, it really aint C++ if you can't define classes.

[Reply #16 on:]

Well you can, as this illustrates:

Code:

typedef class
  {
  public:
    int bar;
  } tFoo;

tFoo a;
 
void handler ()
  {
  a.bar = 42; 
  }
 
void setup ()
{
  handler ();
}

void loop () {}

However there is a problem if you try to pass your own defined class to a function, because of the automatic function prototype generation, which puts the prototypes before where the type is defined.

I just raised a bug report about that a few minutes ago:

http://code.google.com/p/arduino/issues/detail?id=973

On the bright side, if I may say without sounding pompous, most people who define a class in C++ would put it into its own .h files. That is really where class definitions belong. Then they can be shared between multiple .cpp files. You can do that under the Arduino IDE (making a new tab), it compiles correctly, and is easy to work with.

Whatever it is, it really aint C++ if you can't define classes.

Yep, you can define classes.

[Reply #17 on:]

OK, I suppose I should have said define *and* use. LOL.

Sort of like a write-only memory device. ;-)

In any case, I'm glad to be in C++. No questions of "pretty much" or "bug reports".

[Reply #18 on:]

most people who define a class in C++ would put it into its own .h files. That is really where class definitions belong.

I would disagree. Or say that if indeed most people are doing it this way, they are doing it wrong. You put the declarations (basically, prototypes for the class methods) into a .h file, but the the source for the methods is in a .cpp file. You definitely *don't* want this included in every file that simply want to use a class!

[Reply #19 on:]

OK, I suppose I should have said define *and* use. LOL.

My example used the class. It compiles.

You put the declarations (basically, prototypes for the class methods) into a .h file, but the the source for the methods is in a .cpp file. You definitely *don't* want this included in every file that simply want to use a class!

I don't get your point here. You put the definition in a .h file. You can put the implementation into the .ino file, or make another .cpp tab for it. Probably neater to put it into a separate file. So say you want implement class foo, you make foo.h and foo.cpp. What is the major problem with that?

In any case, I'm glad to be in C++. No questions of "pretty much" or "bug reports".

Right. So C++ has no bug reports?

But I've come across weirder and harder to understand (and therefore workaround) bugs -- most recently I had some code that would throw up spurious errors (some name collision of some sort going on under the hood, I suspect), but _would_ compile without error when the offending code was placed in a seperate .h file and then inlined in the sketch in the same place via a #include directive.

That just about did it for me.

Perhaps you should calm down and post the code in question, and try to understand the techniques required to work around any issues you have. The IDE has some idiosyncrasies, designed to make things easier for beginners. Now you can throw out the whole lot, and move to a pure avr-gcc environment, or keep the friendliness of the IDE and develop strategies for avoiding the issues that friendliness causes.

[Reply #20 on:]

Let me put it to you like this. If you move away from the IDE, perhaps use a custom Make file, or use the Atmel Studio itself, you will no doubt eliminate some of the things that are bugging you. But, and this is important, you will replace them with other things that will annoy you. There is no perfect development environment.

[Reply #21 on:]

But, and this is important, you will replace them with other things that will annoy you. There is no perfect development environment.

No, of course not. But as there are degrees of evil, there are degrees of imperfection.

I probably should say, just to establish a bit of context, that I've dealt with many, many different development environments over the years, ranging over all sorts of hardware. The Arduino IDE was in no way the worst I've dealt wth. But very far from the best as well. (In fact, to be honest, it really does rank down there in the suckiness stakes. But I have dealt with worse.)

On a more positive note, there are many things apart from the IDE that I like about the Arduinos very much. I *love* the bootloader and the plug-and-play USB programming model. (I grew up with the old school development boards that you spent about a week getting set-up to get to "hello world" with. Intel, then Motorola, then MIPs.) I like the Atmel mega chips. I *love* the wealth of 3rd party libraries that means that just about any device you can think of interfacing with an Arduino probably has at least some basic code already available for it.

Which is why, overall, I am an Arduino fan.

But I am not a programming novice. I've been programming in C before there was even ANSI C, much less C++. Arduinos are for beginners. Fine. But I see no reason they have to be *only* for beginners.

So no, I don't expect "perfect" in a development environment. But emacs and gcc and make is pretty damned good, IMHO -- at least it's always something I've gotten along with. That's not to say "perfect". But, as they say, even the Sun has its spots. :-)

I'm glad there are options for those with differing tastes. Perhaps we can agree to agree on this.

[Reply #22 on:]

But I am not a programming novice. I've been programming in C before there was even ANSI C, much less C++. Arduinos are for beginners. Fine. But I see no reason they have to be *only* for beginners.

Speaking as somebody who has used C since 1977 or 1978 and was on the original ANSI X3J11 C standards committee, I tend to agree with you in terms of the IDE trying to simplify and protect users.  But as you point out not everybody who programs Arduinos needs the training wheels.  In terms of development environments, I tend to be old school, and still haven't warmed to any graphical IDE, and only use it as a compilation unit and bootloader.

[Reply #23 on:]

and try to understand the techniques required to work around any issues you have.

Found the definitive workaround, as discussed earlier in the thread.

You find the IDE "friendly". I find it a buggy PITA. Let's agree to disagree. And be happy for each other that you can use the IDE, and I can choose not to.

[Reply #24 on:]

In terms of development environments, I tend to be old school, and still haven't warmed to any graphical IDE, and only use it as a compilation unit and bootloader.

I suspect our tastes are similar, and I'm now very happy to report that I now don't even require the IDE for compilation or bootloading. Recommended.

BTW, good job on ANSI C.

[Reply #25 on:]

Mostly just to avoid the unnecessary recompilations, I guess. The "make" way of doing things is to rationally manage a build so things don't get recompiled unless they actually need to be, after all. So a little bit of a speed of build benefit, and probably a bit more satisfaction that things are being done "properly", if you will.

Did you realize Arduino 1.0.1 does this?  Seriously, it does.  I know....

I developed the code, originally in November 2010, as part of a patch on issue 393.  It was resubmitted 1 year later as issue 638.

http://code.google.com/p/arduino/issues/detail?id=638

Last December it was committed into Arduino's github repository, and eventually released as part of Arduino 1.0.1.

I'm sure that does nothing to sway you to prefer the IDE over vim & a makefile... but when talking about ways command-line based make is superior to the Arduino IDE, avoiding recompiling files based on timestamps and dependency analysis has been part of Teensyduino for 1.5 years and now, as of 1.0.1, is officially a feature of the Arduino IDE.

[Reply #26 on:]

You can bypass the IDE's preprocessing by placing all your code in .cpp and .h files, instead of .ino or .pde.  You still need to have at least 1 .ino or .pde file which has the same name as the directory it's in.  But that file can be empty.

The Arduino IDE supports .cpp, .c, and .h files within your sketch.  They are NOT preprocessed in any way.  If you want to use the normal Arduino functions, you must add the #include <Arduino.h> line in each .cpp file.

Within those .cpp files, you can define classes and use templates.  You can also use them in .ino files, but there's a pretty good chance the IDE's not-too-smart preprocessing step will attempt to extract global-scope function prototypes.  But that preprocessing stuff is NEVER used on .cpp files.

Likewise, the .cpp files are NOT parsed for includes to infer which libraries to link into your code.  So in that empty .ino file, you can place #include <Library.h> lines, merely as directives to the IDE's build system to tell it which libraries to link.  Then you can include only the library headers needed in specific .cpp files which call those library classes.... so your other .cpp files remain free of namespace clutter.

Very few people seem to know this feature exists, but indeed the Arduino IDE does support real C++ compilation without troublesome preprocessing.  You merely need to add the .cpp files to the directory, and then do your coding in those .cpp files instead of .ino files.

Of course, there are a couple C++ things you don't get, not because of the IDE, but due to limitations in the underlying AVR toolchain.  The avr-gcc compiler does not support exceptions, and avr-libc does not provide the C++ stdlib classes & functions.

But you can bypass the preprocessing step.  It's as easy as just creating .cpp files in the sketch directory!

[Reply #27 on:]

Very few people seem to know this feature exists, but indeed the Arduino IDE does support real C++ compilation without troublesome preprocessing.  You merely need to add the .cpp files to the directory, and then do your coding in those .cpp files instead of .ino files.

Excellent info, thanks Paul for the tips and insights. My cup runneth over with options... :-)

Choice is good. And Arduino development with the option to bypass the "helpful" preprocessor is better.

Hopefully a few more people will now be alerted to these basic choices available. I'm sure I can't be the only one glad to get the "sketch" preprocessing out of the picture! :-)

[Reply #28 on:]

You can bypass the IDE's preprocessing by placing all your code in .cpp and .h files, instead of .ino or .pde.  You still need to have at least 1 .ino or .pde file which has the same name as the directory it's in.  But that file can be empty.

The Arduino IDE supports .cpp, .c, and .h files within your sketch.  They are NOT preprocessed in any way.  If you want to use the normal Arduino functions, you must add the #include <Arduino.h> line in each .cpp file.

I mentioned that in reply #1, but thanks Paul for putting it more forcefully.

Also thanks for the tip about the way that unnecessary file are not recompiled every time. The IDE keeps getting better!

[Reply #29 on:]

Mostly just to avoid the unnecessary recompilations, I guess. The "make" way of doing things is to rationally manage a build so things don't get recompiled unless they actually need to be, after all. So a little bit of a speed of build benefit, and probably a bit more satisfaction that things are being done "properly", if you will.

Did you realize Arduino 1.0.1 does this?  Seriously, it does.  I know....

I developed the code, originally in November 2010, as part of a patch on issue 393.  It was resubmitted 1 year later as issue 638.

http://code.google.com/p/arduino/issues/detail?id=638

Last December it was committed into Arduino's github repository, and eventually released as part of Arduino 1.0.1.

I'm sure that does nothing to sway you to prefer the IDE over vim & a makefile... but when talking about ways command-line based make is superior to the Arduino IDE, avoiding recompiling files based on timestamps and dependency analysis has been part of Teensyduino for 1.5 years and now, as of 1.0.1, is officially a feature of the Arduino IDE.

I'll agree that the update to the IDE improves the Arduino build process,
But the IDE even with this improvement still doesn't completely avoid doing unnecessary things or do what can be done with Makefiles.
Yes the update can prevent rebuilding of certain files for a given sketch under certain circumstances,
but since the IDE doesn't build core or Arduino library archives and store them independently of IDE sketch build area,
the IDE must rebuild library archives when say changing board types or restarting the IDE.
Because of the build methodology, the IDE also doesn't (can't) remember the compiled objects across instances of the IDE
even for the same sketch.
i.e. bring up IDE, build a sketch, exit IDE, bring up IDE for the same sketch - EVERYTHING rebuilds.
Even in the cases where the IDE is smart enough to not to re-compile core objects, it still
re-archives them into a local core library.

Overall, it is a build methodology problem. The IDE falls down in certain advanced capabilities because of
the methodology used and it is very difficult if not impossible to push the IDE to be "smarter" do things
differently without having to actually modify the IDE JAVA code.

With makefiles it is possible to do things in a more traditional way like
create 1 core library and 1 set of true libraries for each board type
and with proper dependencies never have to rebuild them again no matter what sketch uses them
or across sketch builds unless there is a change to the actual library code.

Consider an IDE like Atmel's AVR studio. It's build methodology was to use build on top of Makefiles so
that it can do things like allow you to  override everything and use your own makefiles.

What annoys me the most about the IDE is that while it works quite well for certain work flows
and for novices, some of its implementation decisions - most of which would not have affected novices work flow
or impact their ease of use, get in the way of or even prevent doing certain more advanced things.

An Arduino library being able to call another Arduino library is very problematic with the current IDE build methodology.
Yeah, there is a hack to allow it to work today, but it involves adding header files to the actual user sketch - which is a
kludge since the sketch really doesn't care about such sub library dependencies.
Another, being able to source level debug using other Atmel tools.
Those types of problems can go away if a slightly different build methodology were used.

So for me, the building/re-building of modules unnecessarily isn't my biggest concern, what concerns me more is that
certain things like conditional compilation, (sketch being able to control compilation options of libraries), libraries being
able to call other libraries, library code being able to detect and conditionally change based on board type
(not processor type, or having to poke around for "magic" defines), being able to source level debug are the killers.
Heck even the ARDUINO define for the core code revision is not available in a header file as the build methodology
assumed things were only going to be built with the IDE.
It would be nice if the IDE developers would at least consider the ability to build makefiles around their core libraries
for the more advanced uses that want to use Makefiles so that they can do things like source level debugging
as some of the way they are doing things make it more difficult for building Arduino sketches with Makefiles.


--- bill