EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: Tris20 on August 04, 2013, 03:22:10 pm
-
Hey, I'm an undergrad doing EE and this year we've been doing a bit of C++. Over the next few years this will expand and we'll be using Matlab and doing some VHDL as well. My question to you all is: What languages have you used most during employment, which did you enjoy the most/least and what kind projects did you use the respective languages for?
-
Here is what i use
Basic. From rocky mountain basic on an hp150 workstation to visual basic on windows. Even on microcontrollers. It's quick and gets the job done. Ideal for one of a kind programs, testing scripts and run-once programs.
C for embedded code
Verilog for FPGA and IC design
PL/M on 8051 processors
Forth on robotics
-
OK here's mine, more or less:
Various assemblers for embedded and industrial machine control on 8008, 8085, 8051, Alpha, Data General Eclipse
PL/M for the MCUs for same purposes
C++ for business data systems (mostly retail back office and store chain control), as well as embedded stuff
VHDL for CPLD and FPGA development
Borland Turbo Pascal for machine control and general PC stuff
Delphi for PC applications
Java for various bits and pieces
PHP for web development
Python and Perl for general scripting
SQL for Oracle, MS-SQL and MySQL DB development
LISP for AutoCAD automation
Prolog for some experimental stuff
-
during my EE-studies I learned several programming languages.
(Pascal/Delphi (School))
C/C++
Java/Android
Perl
Python
Assembly (AVR)
VHDL
a little Matlab
Bashscript
PHP/html/javascript for webfrontends
I use which languages gets the job done best. For uControllers mostly C and sometimes Assembly, for FPGA/CPLD VHDL. The rest mostly for Programms on the PC/Smartphone etc.
I think its pretty normal to know several Programming languages. In my most recent Projects I used Python for a PC Programm and VHDL for an CPLD.
-
at present:
SML
C/C++
a little bit of Perl
when I first graduated in Engineering almost all my programming was in FORTRAN.
I have programmed in assembler (ARM, 6502, 8086), Prolog, Java, BASIC (BBC and others), Verilog.
I've learned/looked-at but not really programmed in ADA, Haskell, Python, Scala, F#, Ruby, Pascal, various others I've forgotten.
I think it is a good idea to get a little experience in samples of the main types of language. So a procedural language like C/C++ or Java or ADA or FORTRAN;
a hardware language such as Verilog or HDL, a functional language such as SML or Haskel or OCAML or F# and an assembler like ARM or MIPS or 8086, a scripting
language such as Perl.
Most engineers don't do any programming in functional languages (I only came to them late and because I'm a Computer Scientist now) but I think they do
provide a good mental discipline and will make you look at your programming in a very different way which might be useful even if you continue to use C/C++ etc.
-
Professional life: C++, Java, PL/SQL and SQL, unix scripting and all hypes since 1996.
For personal / studies: assembler for 6800x & 8088; (object)Pascal, Cobol, Fortran
My love goes to C++ and Java. (And to Grady Booch and the Gang of Four).
Some people on this forum would catalog me as a pinguin guy.
-
C# wherever I can, C on microcontrollers (with some PIC assembly where needed), usual JS/PHP/etc stuff for web development, and the occassional smattering of Python/Lua/etc.
C# is a very nice language to work with. I've been playing with some Verilog lately, but can't find the time (and :effort:) to really do anything with it.
-
Not employed in EE yet, but these are my preferred languages for different things:
PIC (8-bit), AVR, MIPS, 8051 assembly: microcontroller, of course
C: microcontroller, PC applications
C++: PC applications
Verilog: FPGA/CPLD
Python: PC scripting (test automation, etc), small applications
MATLAB: when Python's not mathy enough
-
PowerPoint when needing to program manager brains.
-
Hahaha^^^^ this one made me laugh. These are really good responses! For those that have already posted as well as those who are yet to post what's the most interesting program you've had to write so far and how long did it take you?
-
PowerPoint when needing to program manager brains.
:D
I second this, it might seem like a joke but should be taken perfectly seriously.
-
at work kdb+, c++ and a bit of java (trying to avoid it :D)
for my personal projects mainly c or c++
-
-Picbasic
As a hobbyist it works fine for me 8)
-
PowerPoint when needing to program manager brains.
ah.. the infamous 'slideware'
-
Embedded programming - C (AVRStudio)
PC application programming - Delphi (Delphi 7/XE)
-
Current job:
C/C++ :-+
Python ::)
Previous jobs:
SQL :=\
Ruby :palm:
Perl :palm:
Java :-+
Objective-C :P
Prolog :-DD
Assembly :-/O
HP-41C :-//
Coolest language I've seen recently:
q/kdb+ (http://www.kx.com/q/d/q1.htm) :scared:
-
Coolest language I've seen recently:
q/kdb+ (http://www.kx.com/q/d/q1.htm) :scared:
might be until you have to spend 8 hours a day working with it ;D
Actually not that bad... just kx has an interesting view of how to write code... here is the java/q interface for your amusement...
http://kx.com/q/c/kx/c.java (http://kx.com/q/c/kx/c.java)
-
Assembler
VB6
MASM
-
C.
You can write C programs in a whole bunch of the more "modern" languages.
Not that that's the way it should be done. Probably.
-
might be until you have to spend 8 hours a day working with it ;D
I suspect those hours are well paid. ::)
here is the java/q interface for your amusement...
Yuck. Trying to write Java/C++ as if it was q is goofy.
-
Goofy indeed. On the bright side, it has got to be better than trying to write Java as Java >:D
-
For embedded stuff, it's all C with the occasional tiny bit of assembler in some rare situations. I work with AVR, PIC, Arm and 8051. Verilog for FPGA work.
On the desktop side:
For Windows stuff that needs a GUI I lean on C#. Everything else is C++ (mostly OpenGL centric stuff).
For OS X and iOS obviously ObjC/Cocoa though most projects I work on are ~75% C++.
Linux, mostly C/C++. If I need GUI parts I lean on GTK and make liberal use of Glade. There's been the occasional Qt project.
Back in the day I leaned heavily on Visual Basic. I stuck with VB 6 for a looong time. I started out with version 2 so I got comfortable with it. Never bothered with VB.Net as I didn't see any reason to choose that over C#.
For scripting stuff I use python where ever I can get away with it. I still have to do a lot of stuff in Bash and Windows shell script. Occasionally I have to work with perl and ruby, though I prefer not to.
For the back end web stuff I lean heavily on python, usually Django projects these days though I have a few active things that are just straight cherrypy with sqlalchemy. I used TurboGears in the past for stuff. I used to do a lot in PHP, though that's pretty rare these days. Most of those leaned on either Code Igniter or CakePHP. Those were the fun PHP projects, having a frame work to lean on. I started out with PHP when it was in version 3. Back then everybody wrote their own half cocked shitty "frameworks", if you even bothered to take that approach at all. Further back I got started with vb/asp stuff.
For web front end stuff, it's javascript, obviously. I make good use of jQuery. I don't stray far from canned CSS templates. I'm pretty weak on web presentation layer stuff.
As far as IDEs go, I don't play favorites. I like the major ones, VS, Eclipse and XCode. I use emacs for Verilog. Keil uVision for embedded ARM and 8051. I've been using pyCharms lately for Python stuff, though I still use Komodo from time to time as well as emacs. For Java stuff I prefer NetBeans. I use Atmel Studio for the AVR stuff and mikroC for PIC. For the oddball Lisp project I use emacs/slime with SBCL.
-
Embedded: C
Desktop: C#
Hw: verilog
-
Programming FPGA / CPLDs I use VHDL.
If I do any embedded stuff (not that I do in my current job) its either C or C++
If writing anything for calibrating our products I have to use Visual Basic |O
If writing test programs / hw debug then C, C++, C# or VB depending on what I have been doing recently.
If having to do data acquisition, then Labview.
Neil
-
FPGA: VHDL
Embedded: C / assembler
Desktop PC: C#.NET, occasional C++ (looking to expand on that, with Qt for example)
Websites: in past PHP, SQL, Javascript and CSS. However, it's a clusterfuck. |O |O |O
I used to also program in Python and tried Java, and although Python is nice, I find myself writing little programs just as fast or faster in C# these days.
Java was for choosing between two evils, went for C#
-
A lot of "modern programming" consists not of understanding the programming language itself, but in knowing about all the "usual libraries and accepted techniques." So knowing C or C++ is not enough; you need to know how to use CMSIS or ASF (and when not to), POSIX and which parts aren't present on your particular chip, the intricacies of the preferred RTOS, OS, or proprietary environment, or the currently licensed graphics libraries and how to use them to create a GUI app that will fit seamlessly on the users desktop/tablet/phone without causing user pain. (consider, for instance, CADSoft's initial release of EAGLE on the MAC, which was more-or-less a recompilation of their linux version to run under X windows using the linux infrastructure that exists on MacOS. I thought it was a pretty clever move, technically, and I wish more companies would do the equivalent, but it was definitely NOT a "Mac Application.")
(This also shows up when you get simplified "tutorials" for a language. I've been doing the online "CodeCademy" "class" for Python, and I think I've got the basics of the core language. Which qualifies me to go work for a company that does their major work in pythong NOT AT ALL, really. Or, way back when, I was able to modify/fix a file archiver that was written in MacLISP, but I'm not at all a LISP programmer.)
Finally, understanding the application can be more important than understanding the programming language. You end up seeing an unfortunate number of awful programs written by great coders who didn't understand the problem, and a similar number of awful programs written by problem experts that didn't know enough about programming. (The latter frequently get masked by the increased performance of computers.)
"Good" employers will have realistic expectations; just because you graduated with a 4.0 average doesn't mean you can write android applications immediately, but having only written iPhone apps doesn't mean you won't come up to speed on Android pretty quickly. (Or PIC vs AVR vs ARM.) (If you can get past the HR department screening software. (Which is why colleges with placement services are so valuable. A company can build of a relationship with a university so that they KNOW what they're getting when someone has a B average but flunked EE311.))
-
Really good post there west. Very informative. Correct me if I'm wrong here but it sounds like you're suggesting that programming is more "can you get the job done using whatever tools you can get your hands on?" than "are you a good programmer?" which would make sense. I'd imagine though that having a good grasp of the language as early as possible is a major bonus though. Looking through these posts I'm certainly going to put in the effort to up my C knowledge over the next few years.
On a side note could someone explain there difference in layman's terms between C,C++ and C#?
I've looked it up a few times and I still don't really understand the difference between them and why you would use one in preference to the other?
Also, do you guys ever use much Matlab?
-
embedded
--------
C - XC sereis from Microchip
ASM
Oshonsoft Basic - really easy to use basic that compiles well and has very similar code between versions for AVR,PIC,8085,z80
http://www.oshonsoft.com/ (http://www.oshonsoft.com/)
Coocoox COS for the ARM stuff
http://www.coocox.org/CoOS.htm (http://www.coocox.org/CoOS.htm)
PC
-----------------
PurerBasic - simple, fast, cross platform, one license, about $100, gets you linux, windows, and mac support. Programs are compiled so they don't need external files, or libs or dll files, just an exe to run .
http://www.purebasic.com/ (http://www.purebasic.com/)
-
[...]
On a side note could someone explain there difference in layman's terms between C,C++ and C#?
I've looked it up a few times and I still don't really understand the difference between them and why you would use one in preference to the other?
Also, do you guys ever use much Matlab?
C and C++ are traditional programming languages that are compiled (or cross-compiled) into native machine code for the target processor. Their difference is that C++ is an evolution of C, introducing the concept of objects http://en.wikipedia.org/wiki/Object-oriented_programming (http://en.wikipedia.org/wiki/Object-oriented_programming), in the form of classes. C++ is therefore an object-oriented language with numerous further developments from C, that are not so directly related to OO concepts. C and C++ are available in principle for any environment, subject only to the availability of a compiler. The GNU Compiler Collection (GCC) that we all have learned to love is available for a huge number of relevant environments, specifically for PC, ARM and most other common MCU mfgs and families. It is equally capable of compiling C and C++ as needed with numerous options directing code output.
C# is Microsofts proprietary language, similar to Java in concept. Both Java and C# are normally compiled into pseudocode, i.e. not the primitive level machine code. The pseudocode is then executed by a runtime environment that also manages the resources and security of the running environment. This brings several benefits in that a misbehaving program has far less chances of adversely affecting independent software just sharing the hosting computer system. A heavy server can run a large number of independent, mission critical applications and this kind of isolation is highly desirable. Of course same is achievable for C and C++ code as well, but with other means and perhaps not quite so "automatically".
That would be the "layman" explanation. There are of course further details but this would offhand be the main difference.
-
programming is more "can you get the job done using whatever tools you can get your hands on?" than "are you a good programmer?" which would make sense.
I would put those phrases closer to synonymous; you could replace the second one with "are you a good XX programmer" where XX is some specific language.
I'd imagine though that having a good grasp of the language as early as possible is a major bonus though.
Yes, probably. Although my argument implies (I think) that you should have a "good grasp" of more than one language. But, you know, if you have to start arguing with your co-workers about how your odd program construct really is "correct" because of "paragraph 11.3.2 of the specification where it says...", then you probably should have written it differently. "Obfuscated code" is sorta neat, but I don't think that being able to write it, or decipher it, is a valuable real-world skill.
-
IMHO programming is more than just knowing a language. To get some actual work done you need libraries. Getting to know the libraries takes a lot of time.
-
Being a good programer is an ability in dependant of any language.
Knowing the white paper of a language adds to your toolbox.
Knowing an environment (eg libraries etc) enables you to deploy your skills.
All three are needed for success.
I get a kick out of comments like. "C++ introduced the idea of OOP". OOP was the natural progression of modularization that we the systems programers employed. Serialization was the natural progression of dynamic resource management. What C++ did was offer an excellent language platform to automate allot of the management burden from the programer. We the systems programers or yore, where using serialization before JAVA and OOP before C++. The initial adopters saw C++ as an excellent tool for existing practices. Yes it is true that C++ is used in schools to introduce OOP because it is the simplest construct to teach it, but that is method not mode.
-
Embedded: C (mplab 32 and 8 bit)
PC: Delphi or Lazarus
The Wife: Chocolates :)
-
The Wife: Chocolates :)
Try giving her a foot massage.
Oh yeah. >:D
-
Hello,
I guess I'm not exotic ... C for embedded (ARM ASM occasionally for low level stuff) and C# for desktop.
That's what I do most and what I enjoy most.
I can write code in tens of language, from PIC16 ASM to lisp/prolog, but as previously said, the language is just a tool to express yourself, not the way you do it. At the end of the day, it's all compiled to be processed by the same hardware.
Knowing the platform (processor) and knowing the inner working of the compiler (I use the compiler to write ASM code faster, I don't use a compiler because I couldn't do it without) is a must to write efficient code. Always ask yourself how the compiler will compile your last line of code, and don't just make a guess, verify it.
Thomas.
-
C, C++, Objective-C, GLSL
-
Please don't take it too seriously but I couldn't withstand ;)
Dennis Ritchie - Write in C (https://www.youtube.com/watch?v=H4YRPdRXKFs#)
-
Please don't take it too seriously but I couldn't withstand ;)
Dennis Ritchie - Write in C (https://www.youtube.com/watch?v=H4YRPdRXKFs#)
Great a PTCD flashback :)
-
Mostly C, occasional assembler, some VB6, a bit of VHDL.
I used to use Turbo Pascal under DOS a lot.
From what I know about C++, it seems a good idea in principle but too resource-heavy for small microcontrollers.
Surprised to see a few other VB6'ers - thought I was the only one who was that unfashionable... I avoid doing PC SW whenever possible, but VB is very quick for knocking up anything from a quick hack to test some hardware to producing reasonable-looking end-user utils to throw files quickly out of USB serial ports.
Performance is OK but has some infuriating quirks (no unsigned types, no scroll-mouse support), and a PITA to deploy (DLLs /install needed). And if I need to give a customer source, they can't officially buy VB6 for themselves.
-
Surprised to see a few other VB6'ers
If you ever find yourself needing something very similar under Linux, check out gambas3. It's quite good, feature complete and like VB6, super easy.
-
Mostly C. Also Python, PyQt and KDE framework stuff. VB6, (a touch of VB .NET) and Gambas. Once I used Basic4Android. Good stuff for rapid development.
For VB6 and mouse scroll:
http://support.microsoft.com/?id=837910 (http://support.microsoft.com/?id=837910)
http://download.microsoft.com/download/e/f/b/efb39198-7c59-4ace-a5c4-8f0f88e00d34/vb6mousewheel.exe (http://download.microsoft.com/download/e/f/b/efb39198-7c59-4ace-a5c4-8f0f88e00d34/vb6mousewheel.exe)
Alexander.
-
Mostly C. Also Python, PyQt and KDE framework stuff. VB6, a touch of VB .NET and Gambas. Once I used Basic4Android. Good stuf dor rapid development.
For VB6 and mouse scroll:
http://support.microsoft.com/?id=837910 (http://support.microsoft.com/?id=837910)
http://download.microsoft.com/download/e/f/b/efb39198-7c59-4ace-a5c4-8f0f88e00d34/vb6mousewheel.exe (http://download.microsoft.com/download/e/f/b/efb39198-7c59-4ace-a5c4-8f0f88e00d34/vb6mousewheel.exe)
Alexander.
Tried a few things including that, but have never managed to get mouse scrolling working reliably with the mouse I use, especially under Win7
-
From what I know about C++, it seems a good idea in principle but too resource-heavy for small microcontrollers.
Probably depends on the platform. GCC adds no extra overhead (not one byte) when compiling C++ for AVR. Obviously you pay for whatever features you use. For some applications, I find namespaces and function/operator overloading to be quite useful, and basic class methods don't use any extra space over functions which operate on structs, so that can be handy as well, if only to clean up the code a bit.
-
From what I know about C++, it seems a good idea in principle but too resource-heavy for small microcontrollers.
Probably depends on the platform. GCC adds no extra overhead (not one byte) when compiling C++ for AVR. Obviously you pay for whatever features you use. For some applications, I find namespaces and function/operator overloading to be quite useful, and basic class methods don't use any extra space over functions which operate on structs, so that can be handy as well, if only to clean up the code a bit.
I have a deep mistrust of anything that takes me further away from the underlying assembly.... VHDL makes me itch.
-
That's because it's not Verilog ;)
Maybe it helps to have studied compilers a bit before - if I'm trying to squeeze a lot into a small space, I'm usually pretty good at predicting where the compiler will emit stinky assembly. Then I just replace that section with an inline asm statement and a little comment describing it.
If I'm not trying to squeeze, I really don't care what the compiler craps out as long as it runs!
-
I have a deep mistrust of anything that takes me further away from the underlying assembly.... VHDL makes me itch.
That's a valid concern with C++. A C compiler generates pretty much exactly the code you wrote, with nothing added and no hidden surprises. With C++ there is a higher level of abstraction (which is good, in general), but it does mean the compiler can generate and insert extra code that you didn't actually write yourself.
On the other hand, if you want exactly the same functionality from your program when written in C you would have to write by hand the extra code that the C++ compiler generates automatically. So another way of looking at it is that if you really want your program to have those functions, then a C++ compiler can simplify your task. A C++ compiler doesn't add unnecessary overhead, it just adds the necessary code to do exactly what you ask it to do. If you don't ask the C++ compiler to do clever things there will be no bloat.
-
That's because it's not Verilog ;)
Probably right, but I don't do enough FPGA stuff to justify re-learning, and even with Verilog you have no hope of looking at RTL or the P&R'd design and finding a bug in your source or the compiler. Except maybe for CPLDs, which are simple enough to be able to spot when it's using more resources than it should.
Maybe it helps to have studied compilers a bit before - if I'm trying to squeeze a lot into a small space, I'm usually pretty good at predicting where the compiler will emit stinky assembly. Then I just replace that section with an inline asm statement and a little comment describing it.
If I'm not trying to squeeze, I really don't care what the compiler craps out as long as it runs!
I'm typically optimising for speed rather than size - I often look at the assembly it generates and tweak the C code to improve it - it took me a long time to move from assembly to C, so I often write code which treats the C compiler as little more than a glorified macro-assembler!
-
Tried a few things including that, but have never managed to get mouse scrolling working reliably with the mouse I use, especially under Win7
TBH never tried VB6 on a non WinXP system. After that addon I had no problems.
Alexander.
-
(http://i.imgur.com/T9cMfjg.png)
:P :P :P
Alexander.
-
A C compiler generates pretty much exactly the code you wrote, with nothing added and no hidden surprises.
..apart from when a compiler bug makes it decide to not save quite all context it should in the ISR code..
Memory allocation is one of the more useful things a C compiler generally does better than even a good assembly programmer, but if it goes wrong, it can be a nightmare to track down.
-
..apart from when a compiler bug makes it decide to not save quite all context it should in the ISR code..
Ooh.... that sounds horrifying... :scared:
-
Hours of fun! /Me runs!
Alexander.
-
*comic omitted*
:P :P :P
Alexander.
Ruby: Monkey-patch their modules and duck-punch their classes to reprogram them to be interested in us?
What? These are "real" terms used by (not only) Ruby programmers... (http://en.wikipedia.org/wiki/Monkey_patch)
-
..apart from when a compiler bug makes it decide to not save quite all context it should in the ISR code..
I had endless fun once when a Fortran compiler failed to emit an appropriate floating point guard instruction before the return statement at the end of a subroutine. As a result a floating point overflow created when the excessively large 80 bit value in an FP register was down converted to the 32 bit single precision return value got left sitting in the processor status register like a ticking time bomb. Two subroutines later in the execution path the next completely innocent floating point instruction to be encountered triggered a floating point overflow exception, far away from the origin. This caused a tremendous amount of puzzlement.
A word to the wise: on Intel x86 hardware, a faulting FP instruction does not generate an exception (if exceptions are enabled), rather the next FP instruction to be encountered throws the exception. So if the very last FP instruction in a sequence might cause an exception, you must follow it by a floating point no-op (FNOP) instruction in order to cause the exception to be thrown. Compiler writers take note.
-
VB6 arrrrgh. Guys port your libraries, port your apps. Throw it away. I actually liked VBscript better than VB6 as it had no pretensions of being a proper language.
Goto VB.net
VB.net: 'you wont look back.
(had to say it)
I used to love doing Delphi, they were so far ahead of the game circa 2000.
I currently use:
c, C++, C#. I look at the dissassembly if i have to.
C++ would be better if there wasn't 10 different ways to do everything. It's ok when you write from scratch because then you can use a subset of the language, but often you get handed a big blancmange of code that has been written by 10 different people, that uses every feature of this feature rich language to no useful effect.
Unfortunately they are trying to do the same to C# language, KISS.
I am trying mixed c and C++ on embedded just so I can use templates. It seems ok, on Arm cortex.
I liked Java but not all the crazy enterprise stuff.
Hard to get by without Html, javascript, css.
Dislike python. terrible language but great set of libraries.
-
Ha, I forgot Pascal. Actually I use Lazarus (http://www.lazarus.freepascal.org/).
Alexander.
-
VB6 arrrrgh. Guys port your libraries, port your apps. Throw it away. I actually liked VBscript better than VB6 as it had no pretensions of being a proper language.
Goto VB.net
VB.net: 'you wont look back.
..except to install a trivial bit of code on another PC you need to install umpteen megs of .net framework. Worse than the VB6 DLL nonsense.
I used to love doing Delphi, they were so far ahead of the game circa 2000.
I did start looking at Delphi & got sidetracked - I liked that it produced a single .exe that would just run
-
These days I prefeer C based languages, from the basic ANSI C to java, C# etc. I used to really like C++, but mostly in the original vision of Mr. Stoustrup, it's become much too "tainted" a language these days.
Previously I have been a big fan of Borland's Turbo Pascal and used VB from version 1 (the original 720Kb floppy DOS version) until the last version 6.
For students wondering what is the most beneficial language to learn, my advise is no particular language. In my position, on average, I perform maybe 2-3 interviews a month, and honestly, I don't care about language syntax/specific stills etc. unless someone thinks a specific language is the only way (which shows lack of understanding and the fast route to a no hire).
It's all about understanding the fundamental concepts.
For senior positions I will not even get into any language. It will be purely based on personality, design concepts and past experience.
For junior positions, I will ask algorithm based questions and require solutions on a whiteboard, but any language or psuedo they prefeer.
Howeder for contractors I need specific proof of skills in the specific field they are being considered for. So if you are a Java developer and you are applying for a C# contract, there is no chance. Well actually it's unlikely that applicant would make it past HR :)
-
I code mostly in assembler, C and VB6 which, of course, all means that my most often used language is FOUL language.
-
Ruby: Monkey-patch their modules and duck-punch their classes to reprogram them to be interested in us?
I duck-punched a class once. I felt dirty afterwards.
-
For embedded SW: mostly C (99%) and 1% assembli only when
a) it can't be done in C (like shifting with carry)
b) it is MUCH faster in assembli
c) the compiler screws up
For a few PC applications: C++ and C# but I have a hard time since I program most of the time C and C# has so many differences ( I miss the #define) |O :-DD
-
Verilog and C, c#
-
C++ when I worked in the financial software world.
Nowadays:
Python for PC-side prototyping of data handling, barebone GUIs, and the like. It's quick and easy to put things together, and I love being able to prototype on the interactive terminal
C for embedded software.
MATLAB for data analysis. It's a subpar language, but the mathematical functions and plotting abilities available are second to none.
-
C for embedded
VHDL on CPLDs
VB.net for any quick windows apps to talk to hardware and I don't go much further than that for PC apps
-
At work (i'm a Software Developer, not EE):
Java,
some vb, vb.net, vba
COBOL, well Delta ADS actually, but no one knows what that is, anyway.
At Home/Hobby:
C/C++ for embedded stuff
Assembler on AVR if i have to
Python for almost any scriptingtask these days
some shellscripting
-
Embedded - C (though I'd love to see Rust on embedded)
Desktop - JS to C# to Python and beyond
-
C - microcontrollers
assembler - I need to use it in school.
-
COBOL, well Delta ADS actually, but no one knows what that is, anyway.
Not all of us here are to young to know of such things. :).
Some of us are SysAny's also. There is a wide range of skills here. Which is a good thing, IMHO.
-
C for embedded,
C# forms for simple gui applications,
labview for testing and measurement,
java/android
-
For programming microcontrollers i have never used anything else than C. Although ASM can speed up things if really necessary I've never been in a situation where it would be helpful to know.
As far as automating stuff on my PC goes i use good old batch files. If i needed something with a GUI i probably would tend to C#.
For automating measurements I've used a bit of LabView and Mathcad but only during my studies. When working with Microchip devices ProfiLab is something worth to look at. It is a bit LabView-esque but with less functionality. But for simple GUI stuff when in need it has never failed.
-
C for microcontrollers and old retro system programming, Java, C# .NET and Objective C for PC and mobile software development. Personally I still prefer to use C++ and Delphi for anything on Win32.
-
In my opinion, C is for embedded electronics (uC's and other).
Pascal - for schools, newbies (to learn the basics)
-
General Purpose Programming: C, C++
Embedded System Programming: C
Digital Design: VHDL
At one time, I tried Java for GPP and went as far as GUI during a Summer vacation, but I stopped after finishing a 3 credit Java-based OOP course in my EE program.
-
I use one language exclusively: whatever works.
-
I use VHDL for FPGA and SystemVerilog for verification
C/C++ for MCU
Nothing special...
-
From most to least used:
PHP
Java
JavaScript
C
VB
-
I use mostly MATLAB for quick prototyping and C++ to make it fast.
-
Good question!
I use PHP , HTML, JavaScript for web design and some backend stuff,
C++ for the odd program and then .NET sometimes. I would love to learn java, Maybe i'll invest in the time.
-
I'm going to drop an esoteric one here ColdFusion (hey what can I say it's my day job)
When I get to choose
Python for web and system stuff.
Java for object oriented stuff
Perl for text processing.
C for embedded
Really there are a ton of great programming languages out there learn a bunch and you'll find out you like a few for different reasons.
-
Professionally i am doing mostly c++ and java. Sometimes for large cloud systems, sometimes for small mobile devices.
Two emerging languages I plan to learn are Go and Scala.
-
C for 32bit micros.
Basic (bascom) for AVRs. I started on these before I learned C, so if I were to learn them again for the first time, it would surely be in C.
A tiny bit of VB when I need to make a quick tool to format data for me. Example, wrote a graphical tool that allowed me to draw out what kind of image I wanted on a 5x7 LED matrix, and it would spit out the nicely formated data and code I could simply paste in my "display driver". It's not "1 pin 1 led", it goes through rows and columns, so it was a little tricky.
(http://1.bp.blogspot.com/-htygRqHqAfo/TX0jLxiq-2I/AAAAAAAAAIA/aWW3F9ChPlw/s1600/ledmatrixapp.jpg)
-
climbed into ook, got damaged by brainfuck, can has teh Lolcodez, impressed with Piet.
http://net.tutsplus.com/articles/top-10-most-bizarre-programming-languages/ (http://net.tutsplus.com/articles/top-10-most-bizarre-programming-languages/)
-
English.
-
Anyone else program in Spanish?
-
The last time I tried that, my family threatened me with a visit to the psychiatrist.
-
I have to say quite a varied assortment:
Java - User facing applications (along with Objective-C)
C - Embedded
C++ - Embedded
Objective-C - iOS & Mac systems - some C / C++ for real low level stuff.
Bash - scripting - glue to hold projects together - automation
Perl - similar uses to Bash
PHP - websites
C / C++ is kind of a wash over which one for embedded programming. The smaller the device the more I tend toward C. ARM devices more C++.
-
My first programming experiences were in TI-BASIC on the TI-83 calculator.
For micros I use assembly if efficiency is the highest priority. Else C.
On computers I use C and avoid C++ if possible, as i'm somewhat of a C purist.
-
My first programming experiences were in TI-BASIC on the TI-83 calculator.
For micros I use assembly if efficiency is the highest priority. Else C.
On computers I use C and avoid C++ if possible, as i'm somewhat of a C purist.
Don't fear C++ It's just c with objects and objects rock.
-
I say, a persons job is the job she/he has been doing for last 6 mounts..
For last 12 mounts, I've been using:
- C++ for %90, for any embedded project (I don't know if it is 90, but I feel like it.. :)
- Assembly for critical sections
- Assembly for checking how C++ compiler is performing. (So far so good)
- Python for quick fixes
- .net (mono) for PC related, including Linux and OSX..
About C++, actually it is C compiler with additions of namespaces, templates, classes etc.. And for me, it is a lot more powerful than C.. The code written by it is much more reusable.. For me reuse is the much much more important than the performance and resource usage..
I always write nearly any part of project with C++, apart from reusability, it is syntactically better than c.. For instance:
core.init is better than initCore..
i2c1.start() is better than i2cStart, or startI2C..
uart.open() is better than openUart..
etc..
Actually you are writing in C++ if you are doing:
openUart(UART0);
you are passing a parameter that defines which resource to work on to driver software.. In C++ it is passed as this and C++ is better than you in doing that.. except from virtual methods, only addition is this.. if you are calling a static method, the generated code is same as C generates..
for instance, core.init compiles same to initCore..
I use overloading and inline methods frequently, which enables cleaner code..
Inheritance is really powerful, and also helpful.. For instance my SPI system is based on Spi and SpiNode class that are abstract.. Some MCU's have USART that may work as SPI and also dedicated SPI ports, or SSP.. All are diffent in hardware basis.. I subclassed Spi class for USART driven, SPI driven and SSP driven separately. However, an SpiNode doesn't need to know if it's Spi is based on USART, SPI, or SSP or even software based.. It just calls port->shift(..), port->shiftAsync methods.. That's it..
You can do this:
// using usart0 as spi
usart0Spi.open();
MCP4921 dac;
dac.setPort(usart0Spi);
dac.setValue(1234);
// using spi0
spi0.open();
MCP4921 dac;
dac.setPort(spi0);
dac.setValue(1234);
As you can see all the code looks same.. usart0Spi and spi0 are already defined in library. if you use one variable, for instance usart0Spi, all related methods are automatically included by linker.. And your USART is in SPI mode when usart0Spi.open() is run.. isn't it nice? :)
one time, I used ADXL345 in SPI mode sharing same SPI with other sensor.. How on earth a hardware designer makes this mistake I don't understand. It enters into I2C mode when an SPI transfer occur with other chip.. I didn't have spare hardware based SPI port, and I was using ADXL as oscillation detection so it must be read fast.. I just wrote SoftwareSpi, moved the other chip to GPIO pins and both chips started working..
Isn't it worth? :)
-
by the way, I think "C++ adds a lot of overhead" comes from template library and exceptions.. They are implemented really but really bad.. As if someone was playing with a toy. Just look at vector or queue class.. Ok, it is powerful, but how often are you going to use its power? None.. How much code it generates? A lot..
Exceptions are nearly useless on MCU. I mean, I except, concept is exception-al, however implementation makes it useless.. When you enable exceptions, it adds and adds tons of code, eats RAM.. When an exception occurs, rolling back takes ages.. I think it is designed by academics, and I think academics have no clue about practice..
If you don't use template library, exceptions etc, C++ is flawless.. For instance I just defined my Queue..
Queue<Short> q;
q.push(1);
q.push(2);
a = q.pop();
b = q.pop();
a = 1, and b = 2.. You can use same code for any valid type, even for structs.. How could you do this in C? If you look at the assembly it produces, you will regret saying "C++ is not for embedded"..
-
by the way, I think "C++ adds a lot of overhead" comes from template library and exceptions.. They are implemented really but really bad.. As if someone was playing with a toy. Just look at vector or queue class.. Ok, it is powerful, but how often are you going to use its power? None.. How much code it generates? A lot..
Code space isn't an issue if you're deploying under Linux (or some other multitasking OS). STL may not be appropriate for your mcu, but it's still an incredibly useful and well implemented body of code. Don't write it off as a "toy", learn from it.
Exceptions are nearly useless on MCU. I mean, I except, concept is exception-al, however implementation makes it useless.. When you enable exceptions, it adds and adds tons of code, eats RAM.. When an exception occurs, rolling back takes ages.. I think it is designed by academics, and I think academics have no clue about practice..
Patience, young grasshopper.
C++ exception handling makes sense when you understand why (http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization) it was added to the language. Exceptions are vastly better than explicitly checking an error return value after every function call, which is what some of us had to do in the old days. Yes, there's a lot of overhead with exceptions, but that's not because the language designers were silly academics, it's because writing "airtight" code is non-trivial--you have to check everything and check it all the time.
That said, I turn off exception handling for code intended to run on an embedded system--not necessarily because of the overhead, but because I'm not using the RAII (http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization) idiom. Scoped resource allocation doesn't work that well when you've got a small amount of RAM to deal with. So instead of allocating objects and runtime with malloc/new, it's better to just make them static so you know exactly how much memory you need at link time (not including stack usage, of course). Thus, if you're not allocating stuff at runtime, you don't really need exceptions.
If you don't use template library, exceptions etc, C++ is flawless.. For instance I just defined my Queue [...]
Yep. Templates are cool. They're sort of like #define macros on steriods. Assuming you have access to a good compiler (e.g., GCC 4.7) they only get expensive if you end up with too many instantiations.
I'm working on a project that's using Eigen (http://eigen.tuxfamily.org/index.php?title=Main_Page) in an embedded environment, for some badass number crunching. Very cool stuff.
-
Code space isn't an issue if you're deploying under Linux (or some other multitasking OS). STL may not be appropriate for your mcu, but it's still an incredibly useful and well implemented body of code. Don't write it off as a "toy", learn from it.
What makes you think that I have not learned from it? As I said, it is powerful, however most of the time you do not need that much power.. Simplicity is the key for me.. It might not be a problem if you think of PC environment, but it isn't for embedded. At least yet.. RAM is a scarce resource now.. When it is not, it might be appropriate. However, I again say, simplicity is the key..
C++ exception handling makes sense when you understand why it was added to the language.
Again what makes you think that I do not know the value of exceptions? Aside from making you free from error checking macros/statements, it also helps resource control etc etc.. On PC programming I always prefer exceptions to error codes. What I am saying: current implementation, I have phrase this in bold current implementation is not worth -again in bold- on embedded. It takes to much time to roll back. CPU is halted for just for a simple error. As you know in MCU application halting CPU is nearly unacceptable..
-
For instance I just defined my Queue
No you didn't; you just used a definition of Queue that someone else wrote, which could be appropriate for your deeply embedded microcontroller, or it could have sucked in a bunch of methods with several layers of abstraction (queues use containers, right?) that use dynamic allocation of memory to resize and issue exceptions under some circumstances.
(and did they really use "push" and "pop" for a FIFO queue? OMG *why*?)
[edit] Oh, wait!
Queue<Short> q;
q.push(1);
q.push(2);
a = q.pop();
b = q.pop();Whose implementation of "Queue" is this? It's not compatible with the standard definition, but perhaps since you said to avoid the STL, this is a custom version?
-
The question is which language to use for what purpose.
For a PC program, I don't see any reason to use C anymore. Depending on the situation, I would use Java or C#, while I'd mess with C++ only for time critical or low level stuff.
For a typical microcontroller project with realtime requirements and limited resources, C is the only sensible decision for anything from 8bit AVRs up to 32bit ARMs - at least in a commercial environment.
At the real low end (8bit PICs with like 128 bytes of RAM and just a few opcodes or some integrated peripheral controllers) ASM is still the only way to go.
Using C++ for microcontroller projects with only a few dozen (or maybe even some hundres) kilobytes of integrated SRAM and realtime requirements seems usually like a bad idea. You can use encapsulation and inheritance, but some core features of object oriented programming like non-static object instances and polymorphism are usually not usable if RAM and performance counts. Generally, it's very hard to impossible to keep full control of RAM allocation in object oriented languages. And the risk to get a heap or stack overflow is unacceptable in an embedded system.
Of course in a small hobby project it might be acceptable to waste resources - after all hobby µC programmers also mess around with basic interpreters, SW float implementation and usually put all of their code in the main loop to avoid messing with interrupts and DMA transfers. But in a commercial environment where every Cent counts, wasting resources means wasting money.
-
climbed into ook, got damaged by brainfuck, can has teh Lolcodez, impressed with Piet.
http://net.tutsplus.com/articles/top-10-most-bizarre-programming-languages/ (http://net.tutsplus.com/articles/top-10-most-bizarre-programming-languages/)
I'm glad someone mentioned Piet. :D I once was very into it briefly, and thought about further developing npiet, but lost interest before I started...
I mostly write in C/C++, for anything (when applicable, of course). In the past I've used C# and Java, mostly when learning to develop simple games. I would never recommend making a game in Java; the engines and libraries are terrible, as is their support and documentation.
I've used some x86 assembly (mostly MASM) when practicing reverse engineering of Windows programs. ASM is still my favorite, since I have a hard time understanding abstract concepts. With ASM you can see and control everything, and nothing is hidden in the background, unless you do some macro assembly, but even then it's still easy to understand.
I've used a tiny bit of Python, but don't remember any. In theory I like it, but don't really like interpreted languages. I also want to get into Haskell (which I'm disappointed no one mentioned), but for some reason I can't get myself to start.
-
I know many programming languages but they ones I use the most right now are...
AVR Assembler (AVRASM2)
C
I am still in assembler mode for learning Micro controller stuff but I do love C and use that for most of my little desktop applications when I write them which is not often at all. At some point I will probably use C on a micro. Probably when I switch to ARM or whatever 32 bit chip I decide on.
-
For instance I just defined my Queue
No you didn't; you just used a definition of Queue that someone else wrote, which could be appropriate for your deeply embedded microcontroller, or it could have sucked in a bunch of methods with several layers of abstraction (queues use containers, right?) that use dynamic allocation of memory to resize and issue exceptions under some circumstances.
(and did they really use "push" and "pop" for a FIFO queue? OMG *why*?)
[edit] Oh, wait!
Queue<Short> q;
q.push(1);
q.push(2);
a = q.pop();
b = q.pop();Whose implementation of "Queue" is this? It's not compatible with the standard definition, but perhaps since you said to avoid the STL, this is a custom version?
What's your point? If we use C++, we have to use STL? If I say Queue, do I have to define a class that is compatible what guys before me does? Are all you have done is universal? Could we not define (in programming language sence, not mathmatical sence) our own implementation of any concept? I don't care what Queue means in the point of view of a Computer Scientist. What I care is how long it takes me to write virtualy bug free, resource friendly application. That's it.. If it is rewriting queue, tasking, hardware abstraction layer classes etc. etc.. which I have already done, so be it.. Try using your "standard" library on a MCU and see how resource eating useless monster it is..
-
Using C++ for microcontroller projects with only a few dozen (or maybe even some hundres) kilobytes of integrated SRAM and realtime requirements seems usually like a bad idea. You can use encapsulation and inheritance, but some core features of object oriented programming like non-static object instances and polymorphism are usually not usable if RAM and performance counts. Generally, it's very hard to impossible to keep full control of RAM allocation in object oriented languages. And the risk to get a heap or stack overflow is unacceptable in an embedded system.
Of course in a small hobby project it might be acceptable to waste resources - after all hobby µC programmers also mess around with basic interpreters, SW float implementation and usually put all of their code in the main loop to avoid messing with interrupts and DMA transfers. But in a commercial environment where every Cent counts, wasting resources means wasting money.
Where do you get those ideas? Do you have on hands experience or just speculating? Do you have to use "non-static object instances"? Have you measured the cost of encapsualtion and inheritance?
Encapsulation:
class A
{
private:
void doSomething();
};
what is the cost of private method?
Inheritance. Means children behave different. Most of the time it is done by switch clause and function pointers.. What is the cost of switch and function pointers? The best implementation is the same what C++ does..
non-static:
Do you always use new MyObject style object creation? What about this:
Byte radioBuffer[64];
CC1101Spi radio;
GpioInterrupt radioInterrupt;
int main()
{
spi0.open();
radioInterrupt.setPin(P1_1);
radio.setPort(spi0);
radio.setSelectPin(P1_2);
radio.setInterrupt(radioInterrupt);
radio.open();
Event radioEvent;
while (1)
{
radio.receiveAsync(radioEvent);
// do something,
// do other thing
if (radioEvent.wait(100))
{
//packet received
radio.readFrame(radioFrame);
// handle packet
}
else
radio.stopAsync();
}
}
This opens spi0, creates an GpioInterrupt. Binds both to CC1101Spi radio. Calls receiveAsync() which initiates reception, and sets the given callback when reception is completed, while radio is active it does other things, than waits for radio, if reception completed in 100ms, it reads frame, else it stops reception, and loops..
I want to show you that there is no need of dynamic allocation even in very complicated tasks.. If you don't need async behaviour it is just this
if (radio.receive(radioBuffer, 100))
{
//frame received
}
Still, Where is non-static behaviour?
-
Well, maybe you should re-read my post again as you seem to have read things that I didn't write. E.g. I mentioned encapsulation and inheritance as positive examples which you can use without heavy costs. You seem to have read the opposite, so it's kinda hard to argue with people who don't even closely read the things they get upset about.
Anyway, as soon as you create an instance of a non-static object (which you do all the time in a normal object oriented program - most of the time without even noticing it), you allocate RAM and the constructor is called if there is one (else the object members are initialized as 0). If you consider a normal OOP scenario, where objects are created and destroyed all the time, this creates a significant overhead.
Besides, as I pointed out, dynamic allocation alone is a no-go in a typical microcontroller project.
-
Could we not define (in programming language sence, not mathmatical sence) our own implementation of any concept? I don't care what Queue means in the point of view of a Computer Scientist.
You obviously don't care about communicating with other developers either. I've run into a couple of programmers who insisted on inventing everything themselves and using their own nomenclature. Every time it was a pain trying to figure out what they actually meant when using supposedly standard concepts like "lists" and "queues" and so on. Didn't help that by ignoring all the litterature and work that had gone before them, their re-invented wheels were usually pretty bad.
-
Well, maybe you should re-read my post again as you seem to have read things that I didn't write. E.g. I mentioned encapsulation and inheritance as positive examples which you can use without heavy costs. You seem to have read the opposite, so it's kinda hard to argue with people who don't even closely read the things they get upset about.
Anyway, as soon as you create an instance of a non-static object (which you do all the time in a normal object oriented program - most of the time without even noticing it), you allocate RAM and the constructor is called if there is one (else the object members are initialized as 0). If you consider a normal OOP scenario, where objects are created and destroyed all the time, this creates a significant overhead.
Besides, as I pointed out, dynamic allocation alone is a no-go in a typical microcontroller project.
Nope I read it.. I think you didn't read mine..
From your claim in real time application C++ in few kilobytes is bad idea.. Those include encapsulation, inheritance, and polymorhpism.. Encapsulation, and inheritance are ~usable according to you, but polymorphism is not.. What I understood is: not using any of those is preferable.. Am I wrong? I just wanted to say that what you claimed "may"s have no cost.. Nothing different from C, you do not need to think about, they are neutral element. Ok, lets drop encapsulation and inheritance.. Let's say we are saying same..
I wrote inheritance accidentally, but what I meant was polymorphism. I said that your similar switch case, or function pointer C implementation would be probably be worst than what C++ produces.. Calling a virtual function just adds one direct load (vtable), and an extra indexed load (method address).. Two instructions more.. Just that.. But if you want to implement same behaviour in C, you use switch statement, which adds lots of comparison and jump.. C++ is more efficient than C in that sense.. In C, if you want to prevent switch case you use function pointer, than you lost a pointer size of RAM, which is equivalent to the cost of vtable pointer. What about 3 functions? It would be better using a struct that holds function pointers, and a link to that struct in RAM.. Produced code would be even worst than what C++ produces.. So, what's the difference? Let say C compiler is clever and produced the same instructions C++ produced, than the difference may not be the MCU resource you use, but it is the time resource you spend typing.. In any sense, polymorphism is more powerful and more efficient than C equivalent..
I also I tried to mention that you do not need dynamic allocation as much as you do not need it in C. From your and others claim, C++ seems to mean dynamic allocation. This is as much overhead in C as it is in C++.. Which is unrelated to C++..
OOP is one thing, C++ is other thing.. You can do OOP in C as well as in C++.. For instance you can write a window manager, and different widgets such as Label's, Button's etc. -which are nice examples to OOP- in both languages.. In both examples they would eat nearly same resources.. I also claim that C implementation would cost more if you are not carefull.. But if you use C++, your code would be more solid and you would spend less time.. Also, if one language is able to to do something easyly, which eat resources, does not mean it is a resource eating language..
Keeping in mind the above, even in realtime applications, if it solves nice, using polymorphism is better than not using it..
If you are using a MCU with 128B of RAM today, unless it does something very very simple, and unless it is wise using it, I am sorry but you are doing it as hobby, not as a professional. Or your time is cheaper than what you create.. Are you designing devices that are mass produced, in millions? If not, lets say, you spend 1 dolar more, and you produce 1000 units. You will lose $1000. If using some tool saves me a few days in development and even if it saves me after production (in app programming, remote access, etc. etc), than it's worth wasting some resources and spending $1000 more. If $1000 is much for your project, than your time is cheap. I recommend you leaving that project and finding a better one. For my projects, most of the time, the cost of the board is much less than how much my time costs. As I said, C++ is more efficient than C in general coding habbits.. Than I am not wasting though.. :)
If you do a little search you would see that new chips are cheaper and more resourceful than old "toy" chips..
-
Could we not define (in programming language sence, not mathmatical sence) our own implementation of any concept? I don't care what Queue means in the point of view of a Computer Scientist.
You obviously don't care about communicating with other developers either. I've run into a couple of programmers who insisted on inventing everything themselves and using their own nomenclature. Every time it was a pain trying to figure out what they actually meant when using supposedly standard concepts like "lists" and "queues" and so on. Didn't help that by ignoring all the litterature and work that had gone before them, their re-invented wheels were usually pretty bad.
I am trying to have nice library that is "MCU ready" and I think you are exaggerating a little bit.. If STL was common, well known, used by everybody, than I would agree with you.. It is interresting to taste, teach in schools, but you won't see it in programs much. Even its naming conventions is not compatible with mine, which will make me force wrapping around it..
Besides, every well known library has its own Queue definition.. Qt has QQueue, .net has Queue.. as such.. I have a very comprehensive library -let say Qt of MCU- so mine has its own..
Queue::push pushes the given argument into the list, ::pop pops from the list and returns it, in first in first out order.. Comes from Fifo, that's why push and pop there.. I will rename those to enqueue, and dequeue. However I have to refactor my projects. And I will for the sake of clearity. List::add adds the item to the last, List::insert inserts the item before.. etc. etc.. Similar to Qt's and .net's Queue and List classes. I am not using exceptions. pop returns value filled with 0 if there is no item in the list. Queue::push returns true if successful, however if you want result for pop, you use Word Queue::pop(T& value) This makes usage a lot easier:
Short v;
if (queue.pop(v))
{
// use v, as an example
dac.setValue(v);
}
the other is easier when you use as parameter:
if (queue.hasItem())
dac.setValue(queue.pop());
Another difference from the standard Queue is the fact that my implementation is not dynamic. It allocates in constructor.. You may give how many items to allocate, default is 16.. If you don't want to use heap, which I prefer as it cost 8 bytes more for heap linked list record for each heap allocation in 32 bit environments, you may:
Short buffer[16];
Queue<Short> queue(buffer, sizeof(buffer));
Static allocation is not as dynamic as dynamic :) allocation however it is still powerfull. At least you dont have to think about head-tail indexes etc.. You may pass queue object to other classes/functions/methods.. It may act something like a link between objects..
STL's definition is a little ugly. queue::pop pops, you access it by queue::front which calls destructor.. Not efficient, two calls.. Unnecessary. Did someone said destructor?
What's wrong with mine? What's the "reinvention"? It is just adaption, making it MCU safe.. Err, may be adoption.. :)
-
Nope I read it.. I think you didn't read mine..
Well, as you claimed I wrote the opposite of what I wrote, I kinda gave up on reading all the futile details.
From your claim in real time application C++ in few kilobytes is bad idea.. Those include encapsulation, inheritance, and polymorhpism.. Encapsulation, and inheritance are ~usable according to you, but polymorphism is not.. What I understood is: not using any of those is preferable.. Am I wrong? I just wanted to say that what you claimed "may"s have no cost.. Nothing different from C, you do not need to think about, they are neutral element. Ok, lets drop encapsulation and inheritance.. Let's say we are saying same.
Pretty simplye: everything that can be done during compile time usually doesn't cost much during runtime (apart from wasting a bit of RAM and code maybe). Everything that has to be done during runtime (e.g. polymorphism) should be avoided.
I wrote inheritance accidentally, but what I meant was polymorphism. I said that your similar switch case, or function pointer C implementation would be probably be worst than what C++ produces.. Calling a virtual function just adds one direct load (vtable), and an extra indexed load (method address).. Two instructions more.. Just that.. But if you want to implement same behaviour in C, you use switch statement, which adds lots of comparison and jump.. C++ is more efficient than C in that sense.. In C, if you want to prevent switch case you use function pointer, than you lost a pointer size of RAM, which is equivalent to the cost of vtable pointer. What about 3 functions? It would be better using a struct that holds function pointers, and a link to that struct in RAM.. Produced code would be even worst than what C++ produces.. So, what's the difference? Let say C compiler is clever and produced the same instructions C++ produced, than the difference may not be the MCU resource you use, but it is the time resource you spend typing.. In any sense, polymorphism is more powerful and more efficient than C equivalent..
I wouldn't deny that OOP is elegant for many problems. I do deny though that a compiler can ever create more efficient code in case of polymorphism (and many other things) than a clever programmer.
Again: yes, OOP may save you some time during development, but you lose control control over resources. Which is ok for powerful systems but not for typical microcontroller stuff.
I also I tried to mention that you do not need dynamic allocation as much as you do not need it in C. From your and others claim, C++ seems to mean dynamic allocation. This is as much overhead in C as it is in C++.. Which is unrelated to C++..
And again: dynamic allocation of objects is what you do in a typical OO program all the time. When manipulating Strings, Lists, Vectors etc. you create and destroy objects all the time - even if you might not even notice it. In C, you can easily avoid dynamic allocation altogether. And in a microcontroller with small RAM you better do so. Firstly because real dynamic heap allocation costs runtime, secondly because you can't afford to end in a heap overflow.
OOP is one thing, C++ is other thing..
True. But it doesn't make much sense to program in C++ and avoid OOP. Or let's say than you're programming C and just call it C++.
You can do OOP in C as well as in C++..
Not really.
For instance you can write a window manager, and different widgets such as Label's, Button's etc. -which are nice examples to OOP- in both languages.. In both examples they would eat nearly same resources.. I also claim that C implementation would cost more if you are not carefull.. But if you use C++, your code would be more solid and you would spend less time.. Also, if one language is able to to do something easyly, which eat resources, does not mean it is a resource eating language..
GUI programming is really the best example where object orientation makes sense. In C you're forced to copy large section of code over and over again or you need to mess your code with switch cases and/or function pointers. But do you create large GUIs in a typical microcontroller project? Usually not.
Keeping in mind the above, even in realtime applications, if it solves nice, using polymorphism is better than not using it..
Nope.
If you are using a MCU with 128B of RAM today, unless it does something very very simple, and unless it is wise using it, I am sorry but you are doing it as hobby, not as a professional. Or your time is cheaper than what you create..
Wrong again. I would never mess around with a lowend PIC as a hobby. And yes, they are still used in commercial applications for stuff to wake up the main µC etc.
Indeed I recently analyzed PIC ASM code at work to estimate effort for a functional change or porting to a newer PIC device. Luckily we then decided to stay with the old solution.
Are you designing devices that are mass produced, in millions? If not, lets say, you spend 1 dolar more, and you produce 1000 units. You will lose $1000. If using some tool saves me a few days in development and even if it saves me after production (in app programming, remote access, etc. etc), than it's worth wasting some resources and spending $1000 more. If $1000 is much for your project, than your time is cheap. I recommend you leaving that project and finding a better one. For my projects, most of the time, the cost of the board is much less than how much my time costs. As I said, C++ is more efficient than C in general coding habbits.. Than I am not wasting though.. :)
Our projects are usually produced in the hundreds of thousands. Saving 5 Cents for some transistor saves 15000€ for the part alone if you produce 300000 units, even letting aside stockkeeping and set-up costs. So wasting 1€ or more on a bigger CPU is out of question. Indeed, when looking at the overall costs, the SW development is only a small (and fixed) fraction. So some additional man hours for SW efforts really don't make much of a difference.
If you do a little search you would see that new chips are cheaper and more resourceful than old "toy" chips..
If you had ever worked on a real big-scale commercial project, you would know how unrealistic it is to quickly google a new chip and than use it in a safety-relevant environment. Validation of new devices, stockkeeping etc. costs a lot. Much more than a few weeks of SW development anyway.
-
You claim something but you do not give any measurable data.. For instance:
Everything that has to be done during runtime (e.g. polymorphism) should be avoided.
Why? How did you measure the cost of polymorphism.. You just say "NO".. Give an example to a problem. Cost in C, cost in C++. I gave you one problem, 4 solutions, one solved by switch-case, other function pointer, other pointer table, and final one is virtual method. Virtual method costs: one vtable pointer read, one method address read. Which is a lot faster, a lot less code, and neater than usual, I insist on usual, C coding style.. Here I insist on coding style. You can optimize everything but usual coding approach is more important.. This is a measurement, what is yours?
nd again: dynamic allocation of objects is what you do in a typical OO program all the time.
Again, no examples.. It is not C++ issue, it is library you are using or your approach.. You don't have to do any dynamic allocation. It's totally up to your implementation. I coded operating system, HAL, graphics drivers, window management system, string handling routines, etc. etc. with NO HEAP USAGE.. Only GUI system has its own buffer. Window manager uses given buffer for clipping map calculation. Think about stuffed widgets, the behind is obstructed by others, graphic system calculates maps of open areas which needs to be done in runtime.. GUI uses some part of given buffer as line buffer -to reduce clip region check-, and overlay handling.. All of them allocate incrementally, and release totally, again no heap, GUI's internal memory manager does this.. Which is ultra fast.. This is the nature of the system. Even if you coded it in C you also have to use the same method.. It's not the language, it is the method.
To sum: In common practice yes you do a lot of dynamic stuff. But you can, I did, avoid it.
Quote from: denizcan on October 27, 2013, 07:59:14 AM
You can do OOP in C as well as in C++..
Not really.
Yes you can.. Just think about window manager written in C. All C implementations are ugly BTW. You create a widget, while creating you pass its handler callback function. The manager creates a struct that holds information about that widget, your widget has a switch statement in its handler function that handles the incoming message. If it does not handle a message or handles but needs some help from default, it calls default handler.. etc. etc. Windows and containers has a list of containers, and widgets. Etc. From start to finish OOP. And if this isn't a RAM and ROM costly polymorphism, what is it?
The bad thing is, usual implementations -I insist on implementation- do use dynamic allocation to hold widget record. With C++, as object also can store window manager stuff, you can avoid dynamic allocation.. C++ implementation is A LOT neater.. Just look at this:
Label label;
Button button;
Window window;
KS108Display display;
void handleButtonClick(void* sender, void* param)
{
label.setText("Button clicked");
}
int main()
{
core.init();
display.open(); // with default pin settings
window.setBounds(display.bounds);
label.setLocation(0, 0);
label.setTest("Label1");
button.setLocation(64, 0);
button.setText("Press Me");
button.onClick = handleButtonClick;
window.add(label);
window.add(button);
application.setDisplay(display);
application.setMainWindow(window);
application.run();
}
You just created a window, a label, a button and an action when button is clicked. I bypassed keyboard, pointer stuff, they are similar, giving keyboard object to scan pins and corresponding keys such as KEY_LEFT, KEY_RETURN etc, and introducing this keyboard to application. Rest is handled by system.. As Window, Button etc classes also holds stuff related to window management actually C++ prevented dynamic allocation intrinsically..
Also strings in setText etc are not string class, they are plain Char* pointers.. No allocation. If you want Label etc to hold its text, you explicitly mention that:
label.allocateTextBuffer(80);
or
Char labelBuffer[80];
label.setTextBuffer(labelBuffer);
This time label marks a flag that what Char* text field points to is allocated buffer. label.setText now copies the given null terminated string to the buffer pointed by text field..
As you can see, dynamic allocation is implementation dependent, not a MUST.
I wouldn't deny that OOP is elegant for many problems. I do deny though that a compiler can ever create more efficient code in case of polymorphism (and many other things) than a clever programmer.
Compiler is not as clever as programmer. However, programmer is not as careful as compiler.. You are talking about a programmer that is always careful. This is really back braking. Not all of the code needs super optimization. For instance for a GUI, pixel processing needs to be ultrafast. But context stuff, such as graphics.drawString(..), graphics.drawLine(..) does not have to be. At that level, the method is more important than the brute force power. You will have nearly no benefit from making calling them fast. You will have millions of pixels to be send, but hundreds of call to the given methods. So, I focus my optimization TIME to the low level stuff, not high level. Compilers help with polymorphism solves that different behavior need.
Keeping in mind the above, even in realtime applications, if it solves nice, using polymorphism is better than not using it..
Nope.
Again, no solid info, no measurement. Please at least give a task and why polymorphism is not up to that..
Our projects are usually produced in the hundreds of thousands. Saving 5 Cents for some transistor saves 15000€ for the part alone if you produce 300000 units, even letting aside stockkeeping and set-up costs. So wasting 1€ or more on a bigger CPU is out of question. Indeed, when looking at the overall costs, the SW development is only a small (and fixed) fraction. So some additional man hours for SW efforts really don't make much of a difference.
Ok, I admit, you are in different area with different problems.. And you are right, the setup and production cost is important on your products.. My approach does not suit your business. What I design are usually relatively big sophisticated systems produced in at most a few thousands. 128 Byte MCU has no place to fit in. The software development time is the main issue, not the hardware. Ethernet, graphical GUI, multiple boards with LINBUS/CANBUS/RF communication are just starters.. As hardware is usually ADC, DAC, a few analog signal conditioning and power stuff, the processing, filtering, detection, decision, signal generation etc are usually all done by software.. The customer always wants new things and the time to market is important for them. They don't question a few $ more for a system.. So for me, using same code on different platforms and being able to program without reading details in MCU documentation is a lot more important than a few parts of the code to be super fast, or super resource/cost efficient.. I am lucky, huh? :)
-
Everything that has to be done during runtime (e.g. polymorphism) should be avoided.
Isn't a lot of polymorphism handed at compile time? Function overloading is considered polymorphism, for instance.
-
Maybe it's less confusing when we differ between runtime/dynamic polymorphism and static polymorphism. The wording doesn't seem to be 100% consistent. E.g. in a Java book I read some years ago, the author used the term only for runtime polymorphism.
Anyway, again: obviously what can be done during compile time might create code overhead, but usually doesn't create much runtime hit.
Besides, initially I said that the language depends on the task and environment. Of course if you limit yourself to certain language features, use your own class libraries etc., C++ can also be used in a microcontroller environment with limited resources. Still with every layer of abstraction you lose control over the resources. E.g. if you use (packed) structs and unions, you know exactly where each byte of your data is located. If you use a static object to encapsulate the data structure, this is not the case anymore. If you use a function pointer to handle e.g. configuration on the function level, you know exactly what the CPU will be doing. If cast objects during runtime, you can create a large runtime hit without even noticing.
And regarding the "you can use OOP in plain C" argument of denizcan. Of course you can mimic OOP in C. Hell, you could even mimic Logo or Lisp in C. Still, due to missing features of C, you can never e.g. create encapsulation with the same level of security. E.g. if a C module exports a function or variable to other modules of the same function group (->function/variable can't be static), this global function or variable will be always accessible to the whole project. Either by importing the private header containing the according declarations or by just adding the missing declarations to your file. So your encapsulation is worthless.
Indeed, proper encapsulation would be the main benefit in our projects from my point of view. Then again, working with hundreds of developers all over the world is already complicated enough with C as we need pretty extensive coding guidelines to limit the things you could do in C to those that should be used in our projects. With C++ it would be so much harder to define which language features to use in which situations and which to avoid under which circumstances.
-
Everything that has to be done during runtime (e.g. polymorphism) should be avoided.
Isn't a lot of polymorphism handed at compile time? Function overloading is considered polymorphism, for instance.
overloads done in compile time. virtual methods are handled in runtime.. to call a virtual method, cpu reads the first pointer field in the object (begin first depends on single or multiple inheritance), this is vtable pointer, then it reads the address of the method from that table.. this is the debade:
virtual function call
0x000001E6 6801 LDR r1,[r0,#0x00] ; load vptr to r1
0x000001E8 6809 LDR r1,[r1,#0x00] ; load function pointer to r1
0x000001EA 4788 BLX r1 ; call r1
direct function call
0x000001E6 F000FD7C BL.W Dispaly::open (0x00000CE2)
On both r0 points to object.. As you see virtual method call adds two extra load instructions, if you use pointer, such as display->open(). That means two extra cycles. They add nothing on static variables such as: display.open(); On static variables as compiler knows the last overridden method, it is same..
I think people are exaggerating. I frequently come across what C++ haters write:
void UART_Open(int iUartId)
{
switch(iUartId)
{
case 0:
//open uart 0, bla bla
break;
case 1:
// oprn uart 1 bla bla
break;
}
}
int main()
{
UART_Open(0);
}
This is a lot, far more, horribly unoptimized. I cannot find an adjective to describe it. Also a guy -I do not mean 0xdeadbeef- writing this code cannot say C++ is not for realtime or anything else.. Just compile that, and compare with my virtual uart0.open(); as you can see it is call to static object, compiler selects the correct method address in compile time, and just calls it. This is something like switch statement with 0 cost.. The C implementation creates a lot of instructions. C++ implementation is faster.. Only cost is a pointer in RAM (vtable) for that object, and pointers to methods, the rest is the same as C..
-
Hahaha^^^^ this one made me laugh. These are really good responses! For those that have already posted as well as those who are yet to post what's the most interesting program you've had to write so far and how long did it take you?
In the 80s in my first job I wrote a UHT Miilk production scheduling system on a Commodore PET 32K, with twin 400K disk drives. I was working at a minicomputer software house at the time and they gave me the job because someone from United Dairies called them up and I'd mentioned I'd written a timetable management program on the PET when I was at school.....
Probably not the most difficult challenge of my career but certainly the oddest. As a result I know more about the production of UHT milk (at least in the 80s) than I'd prefer to mention.
-
E.g. if you use (packed) structs and unions, you know exactly where each byte of your data is located.
Nope, you can.. class and struct are the same. If you have a packed class, than you have packed struct.. Only exception is vptr if you have virtual method..
If cast objects during runtime, you can create a large runtime hit without even noticing.
Nope you dont. Unless you explicitly enable run time type info on compiler and use dynamic_cast<> operator.. Those are nice tools on PC helping to find errors and other exotic stuff. However not needed on embedded.. I must reprase: you explicitly write dynamic_cast<MyClass*>. It is also really uggly to write though.. :)
this is just a pointer cast:
Widget* w = &button;
Widget* w = (Widget*)0x1234;
They are exactly same in C and C++. It means you know the type, just assign the address.. Predictable to the last bit.. Same code..
As far as I understand, people are strongly biased from the C++ stuff produced for PC.. As C is less powerful, programmers can not go beyond, this inablity made people think that C was more efficient.. If I were to write Linux from scratch I would write total in C++ with my additions, such as better method pointers.. I mean I would add it to GCC.. :)
-
In the 80s in my first job I wrote a UHT Miilk production scheduling system on a Commodore PET 32K, with twin 400K disk drives. I was working at a minicomputer software house at the time and they gave me the job because someone from United Dairies called them up and I'd mentioned I'd written a timetable management program on the PET when I was at school.....
Probably not the most difficult challenge of my career but certainly the oddest. As a result I know more about the production of UHT milk (at least in the 80s) than I'd prefer to mention.
^^ haha, nice!.