Which programming language to learn

As the kids say these days, "true dat," and I was being somewhat loose with the interpretation of "C++." Compilers aren't supposed to call themselves C++ if they only support a subset (like basic classes and nothing else).

You wouldn't call ActionScript 3 C++, for example, but it is object oriented, and supports classes. This is kinda-sorta what I meant (he said red-faced). So in retrospect, exchange C++ with OOP, and add an asterisk for dealing with the limited capabilities of the typical uC.

For your AVRs, are you using Wiring by any chance? Wiring is said to be "simplified C++," though I've never been sure what features are included/discluded.

If not, what is your language of choice?

As far as handling when exceptions are thrown, I prefer to treat exceptions as features.

-- Gordon

Reply to
Gordon McComb
Loading thread data ...

OK. Fair enough. I was thinking in terms of full ANSI-C++, which GCC *does* support. There are lots of people who play fast and loose with what they call their compiler.

Actually, I probably would call it a subset of C++, which I think is fair and honest.

At our club, there is quite a bit of 8-bit micro-controller usage, and almost everybody is using some version of C (usually a subset that does not support floating points, long precision, etc.) To date, I have not seen our members using C++ subset or OOP languages for the 8-bit micro controllers yet. Doesn't mean that it is not happening, just that I have not seen it.

I've never heard of Wiring. I'll have to check up on it.

My hobby is programming languages. I eventually got tired of waiting for somebody to put together a language with the features I wanted, so I wrote my own. It is called Easy-C and you can read up on it here, if you are so inclined:

Since there is no standard definition of what "object-oriented" means, some people might not accept my claim that Easy-C is an ojbject-oriented language. To be specific, I support static method calls and I use a slightly different syntax to do it:

In C++:

result = object.method(arg, ....);

In Easy-C:

result := method@(object, arg, ...)

Virtual methods are supportable, but it requires some work from the user to make them happen.

The bottom line is that I like it and I use it. I have used it to compile code for the x86, MIPS, and AVR computer instruction sets.

I was actually talking in terms of implementing exceptions. They place a serious burden on the the compiler/linker/run-time system. It was exciting figuring out how to make all of that work efficiently back in early '90's.

-Wayne

Reply to
waynegramlich

AVR CPUs can be programmed in C++. If you download the Atmel board support package, you get a whole integrated development environment that uses GCC.

The "Wiring" project has been supplanted by the "Arduno" cult, which is a family of AVR boards with their own dialect of C++. The tool chain is really GCC, with a front end to simplify things a bit.

I can't see using anything smaller than an AVR at this late date. We're past the Basic Stamp era.

Above the low-end hobbyist level, there's some real-time Java and a lot of C++. Willow Robotics has a "robotics operating system" which is just Linux with some publish/subscribe message passing. Stanford and Caltech like Java.

Boston Dynamics' Big Dog, by the way, uses C++ code on a ruggedized Pentium 3 on QNX.

John Nagle

Reply to
John Nagle

=A0 =A0 John Nagle

Funny about that, just because they use GCC doesn't make it C++. It seems to me if you take away garbage collection and constructors and the rest from C++ what you have left is "C". There is simply not enough memory available to do anything useful in a PIC or AVR if you use a "C++ environment". When all the overhead for true inheritance and garbage collection and such is used the available code space drops to near zero for useful work ... in a PIC/AVR environment!

It's true the reuse of code libraries is an advantage but it is not now, nor never has been, limited to C++. As I stated in my previous response the use of a language is determined by the environment that you are running in, not your development environment. If you develop in a C++ environment but IFDEF out all the C++ constructs you are still coding in "C" and can make the same errors if you are not careful that you get in a "C" environment.

C is not a bad language but it can be abused, but then so can most other languages. Bad code is bad code no matter what environment it is developed in, some languages tend to minimize the abuse but don't stop it.

What the bottom line is that C and assembly are the predominant languages for small controllers, others (including Basic) are used but when it comes to packing in code to small environments they can't compete.

My 2 cents worth.

Monty

Reply to
monty

Hi Monty,

Well, I can say that C++ can be used and does work on the AVR. The Arduino use the C++ compilers.

I'm not sure why you're mentioning garbage collection. There is no garbage collection as part of C++. Inheritance has zero impact on code size (so I'm not sure what overheads you're referring to). Virtual functions cause a per-class vtable to be created, which adds a small amount of overhead, but it's only one function pointer per virtual function, and nothing forces you to use virtual functions.

There is an official subset of C++ called Embedded C++, and the C++ support available on the AVR by GCC definitely exceeds that subset.

I have worked on entire phone GUIs written in Embedded C++ (not on an AVR, but under linux), so it's still quite a powerful subset of C++.

For me, I really like using C++ for ADT (Abstract Data Types), and for that, there is no signifancant code overhead compared to coding it in C.

To use C++ on the AVR, requires a small piece of support code to be added, the entirety of which I'll include here:

#include void * operator new(size_t size) { return malloc(size); } void operator delete(void * ptr) { free(ptr); } __extension__ typedef int __guard __attribute__((mode (__DI__))); extern "C" int __cxa_guard_acquire(__guard *); extern "C" void __cxa_guard_release (__guard *); extern "C" void __cxa_guard_abort (__guard *); int __cxa_guard_acquire(__guard *g) {return !*(char *)(g);}; void __cxa_guard_release (__guard *g) {*(char *)g =3D 1;}; void __cxa_guard_abort (__guard *) {}; extern "C" void __cxa_pure_virtual(void); void __cxa_pure_virtual(void) {};

Reply to
dhylands

Lets see, I see a call to malloc and free in these functions and you say there is no garbage collection?? Must be some real magic here if there is no garbage collection to handle memory allocation. Do you run to a screaching halt when memory becomes fragmented?

Also try checking out your includes and see what happens when the extern "C" is handled. I think you will find out that classes go by the way side and are turned into structures. Most of the libraries I have looked at that are C compatible are loaded with IFDEF's removing classes and converting them into global structures and data. There comes a point when maintenance of this type of code becomes a real nightmare and should be avoided. Code reuse can easily become code abuse when to much is tried to make them compatible. In my opinion it is better to create seperate C/C++ libraries then try to make one library serve both languages. This may shock some but the more you try to cram ino a page of code the more of a maintenance problem it becomes. I firmly believe that the maximum length of any routine is 2 text pages, more than that it becomes much more difficult to maintain and debug.

When you are working on a processor that counts it RAM in bytes not Mega bytes even a "small virtual table" is an excessive waste of valuble resources. Let me get things straight, I have nothing against C

++ but every language has it's place. How much code can be reused in a 1K program memory anyway. A good set of fully debugged libraries is much more practical. Before anyone jumbs on me for the paragraph above in relation to thisone I know JSR's eat both types of memory but a balance needs to be reached between code maintainability and code space.

I also have yet to see an embedded linux environment on a PIC. Whole different world.

As I have said in all my posts, each language has it's own use and I believe the orginal question was which language is best for robotics. Every robot I have built use several small controllers communicating with a central core to handle overall logic. When these seperate functions get rolled into a single small controller every byte of RAM and Code space becomes precious. Therefore C/ASM in the controllers and if there is one, C++ or Java in the core. They really are two different worlds when it comes to which language to use.

Monty

Reply to
monty

The commonly excepted definition of garbage collection is the automatic freeing of unused allocated memory. The C++ language specification does not support garbage collection. Conversely, Java *requires* garbage collection.

-Wayne

Reply to
waynegramlich

You're using "garbage collection" in an idiosyncratic way. Normally, the term is used for a system that simply "notices" that a data structure is no longer accessible, and frees it for itself.

The GNU libc implementation of free() will notice and coalesce adjacent freed blocks, but if memory gets fragmented... yep, system comes to a screeching halt.

I really like C libraries written to be pseudo object-oriented, and then a thin C++ interface layer on top of them.

Yes.

That would be... interesting :)

Reply to
Joe Pfeiffer

I guess I'm showing my age because before C++ came around "garbage collection" was the term we used for the process to manage all those disjoint blocks of memory created by repeated calls to malloc/free. To be honest most of the work I have done does not utilize free/malloc calls. The memory is simply too tight to use that overhead. C can exist quite well without those tools, I=92m pretty sure C++ cannot exist without them at all, I may be wrong. You learn to manage memory without them.

Most =93embedded programmers=94 today expect an OS or RTOS to exist to manage a lot of this stuff for them. Embedded programming is a term that has morphed over the years. It no longer means the same thing now it did 15 years ago, again =93a whole different world=94 then and now. What most consider an embedded environment now is: lot of memory both code and ram, a SD disk, an LCD interface, etc. Most of you out there have only seen my first computer in history books (KIM-1 using a teletype capable printer/terminal, 20 ma loop, for interface).

My first post was to say that what determines the first language to learn still holds true: It depends on the environment you will or expect to be working in! I still like Forth though I haven=92t used it for years :):)

Monty

Reply to
monty

The term "garbage collection" has been used for automatic recovery of unclaimed storage since McCarthy's LISP 1.5 book in the early 1960s. Knuth discusses storage management in "Fundamental algorithms", from 1967, and does not use the term "garbage collection" in the context of systems where the programmer must explicitly release space.

In embedded work, it's quite common to allocate new objects at startup, and never release them. This is as effective with C++ as it is in C, plus you get object initialization. It's very useful for things that have some configuration at startup. Embedded Java programmers often work this way, so as not to invoke Java's garbage collector at all.

Active use of dynamic memory does require more memory, but that's a scaling issue, not a language issue.

People are still writing very tiny embedded programs on very tiny processors. That's fine, but it's not the upper levels of control. Today's tiny programs probably control one motor. Many R/C servos have a CPU in them. All the Bioloid ones do. But they're not in overall charge of the robot.

John Nagle

Reply to
John Nagle

Hi Monty,

Ahh, we just call that the heap, or dynamic memory allocation (use of free/new and friends).

C++ has dynamic memory alloaction, just like C. In todays world garbage collection is used in langauges like Smalltalk, Java, and lisp.

The difference is whether the allocated objects are freed explicitly (like C and C++ do) or automatically (garbage collection). Garbage collection has much more overhead than just a simple heap, which in turn has much more overhead than global variables.

C++ has no more requirement of the heap than C does. Just like you can write perfectly good programs in C which don't use the heap, you can also write perfectly good programs in C++ which don't use the heap. Whether you choose to use the heap has more to do with your data and data structures, and nothing to do with the language (at least when we're talking about C and C++). Admittedly, many C++ programmers have some burned in belief that they must use new and delete for all variables, but that's just due to bad teaching at school.

C++ has been much maligned about being bloated and slow, when in fact its the way the language is used that makes the code bloated and slow, not the language itself.

I do embedded programming professionally, and you still see both types of devices, the small one with limited memory, and no OS, and the bigger one, often running linux with a full OS. It really depends on what your're doing.

Dave Hylands

Reply to
dhylands

John why do I get the feeling you are in upper management and have lost site of the "real world". Do you think Micro chip would have spent the money to develop a picaxe chip if there was not a rather large market for "tiny" processors? The majority of control is done by tiny processors, do yopu think the code writes it's self? C++ has become a mangerial chopping block for software engineers. I really believe they have lost site of the fact that C++ simply wastes resources in small environments but they have been caught up in the hype that you can't maintain "C" code and you have to develop in C++. What most mangers don't realize is that yes they use a C++ compiler but the developers write in C far more code then is believed. Just because you wrap the code in a C++ compiler doesn't make it C++!

...and for those of you that have forgotten this tread is not about C+

  • vs C it was the question :

And I responded with the choice should be based on the environment you are programming for!

BTW my small controller handles PWM output to 2 motors, reads 2 Quad encoders and tracks position info including move to location commands, handles the I2C communications with the central controller,also a RS232 for link for what ever, and several failsafe bump sensors. For small robots this small controller has room in it to completly handle the robot in solving a 6x12 maze but currently is not used that way. I opted for a Propeller chip board to coordinate the motor controller and several IR distance sensors. Oops another language enters the fray, SPIN!

Monty

Reply to
monty

No... I first heard garbage collection used to mean automatic deallocation when I learned LISP in the mid 1970s. Your use of it to mean more general memory management is the first time I've ever encountered that usage.

There's still a whole world out there that's lower-end than the sorts of RTOSs you're describing. I wouldn't want to guess which has more developers, though.

Reply to
Joe Pfeiffer

What I meant here was tongue-in-cheek, as in "if it acts broken, it's a

*feature*!

The best unhandled exception (that doesn't crash the program) is the one that looks like it was meant to happen. I live for those, and I don't charge my clients any extra for them! :-)

-- Gordon

Reply to
Gordon McComb

There's a free Ada compiler, called GNAT, bundled into GCC - in most Linux installations it's in an additional package, usually called something like gcc-ada or gnat-gcc. On Linux or Windows it's a really solid and up to date compiler. Like GCC it can target AVR, I don't have (yet) much experience of this embedded aspect of the GNAT Ada compiler, but I know it can be done.

Reply to
Ian Clifton

Thanks for the information.

Reply to
David Mitchell

Also you can download the latest Ada 2005 from this site (for free):

formatting link
Jerry

Reply to
jdpetre

When ADA first came out, we used to joke amoungst the system programmers where I worked that FORTRAN and COBOL were legal subsets of Ada. It is a very big language, but the package idea is kind of neat.

As for a first language for embedded ... why not just buy into the Arduino stuff, and use the Java based Wiring/Processing? Processing is a perfectly good language, provided you are using AVR's exclusively, and in particular the Arduino.

As for a single language which runs everywhere ... ANSI C is hard to beat. The gotchas concerning the pointer and memory management notwithstanding, C compilers are everywhere, cost from $0 to $little, and generate reasonably efficient code.

Of course, I like Forth too ... but YMMV 8-)

Reply to
Spam

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.