Which programming languages do you use most? - Page 1
Forum section: electronics / general

author: Tris20
author_rank: Regular Contributor
timestamp: August 04, 2013, 03:22:10 pm
content: 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?

author: free_electron
author_rank: Super Contributor
timestamp: August 04, 2013, 03:43:43 pm
content: Here is what i useBasic. 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 codeVerilog for FPGA and IC designPL/M on 8051 processorsForth on robotics

author: Kremmen
author_rank: Super Contributor
timestamp: August 04, 2013, 04:04:55 pm
content: OK here's mine, more or less:Various assemblers for embedded and industrial machine control on 8008, 8085, 8051, Alpha, Data General EclipsePL/M for the MCUs for same purposesC++ for business data systems (mostly retail back office and store chain control), as well as embedded stuffVHDL for CPLD and FPGA developmentBorland Turbo Pascal for machine control and general PC stuffDelphi for PC applicationsJava for various bits and piecesPHP for web developmentPython and Perl for general scriptingSQL for Oracle, MS-SQL and MySQL DB developmentLISP for AutoCAD automationProlog for some experimental stuff

author: Aeon
author_rank: Contributor
timestamp: August 04, 2013, 04:07:29 pm
content: during my EE-studies I learned several programming languages.(Pascal/Delphi (School))C/C++Java/AndroidPerlPythonAssembly (AVR)VHDLa little MatlabBashscriptPHP/html/javascript for webfrontendsI 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.

author: jpb
author_rank: Super Contributor
timestamp: August 04, 2013, 04:49:43 pm
content: at present:SMLC/C++a little bit of Perlwhen 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 scriptinglanguage 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 doprovide 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.

author: jancumps
author_rank: Unknown
timestamp: August 04, 2013, 05:06:56 pm
content: 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, FortranMy 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.

author: ovnr
author_rank: Frequent Contributor
timestamp: August 04, 2013, 05:32:46 pm
content: 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.

author: c4757p
author_rank: Super Contributor
timestamp: August 04, 2013, 05:47:41 pm
content: Not employed in EE yet, but these are my preferred languages for different things:PIC (8-bit), AVR, MIPS, 8051 assembly: microcontroller, of courseC: microcontroller, PC applicationsC++: PC applicationsVerilog: FPGA/CPLDPython: PC scripting (test automation, etc), small applicationsMATLAB: when Python's not mathy enough

author: Bored@Work
author_rank: Super Contributor
timestamp: August 04, 2013, 06:39:30 pm
content: PowerPoint when needing to program manager brains.

author: Tris20
author_rank: Regular Contributor
timestamp: August 04, 2013, 06:54:18 pm
content: 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?

author: c4757p
author_rank: Super Contributor
timestamp: August 04, 2013, 06:55:25 pm
content: Quote from: Bored@Work on August 04, 2013, 06:39:30 pmI second this, it might seem like a joke but should be taken perfectly seriously.

author: tanstaafl
author_rank: Contributor
timestamp: August 04, 2013, 07:06:01 pm
content: at work kdb+, c++ and a bit of java (trying to avoid it)for my personal projects mainly c or c++

author: Ericho
author_rank: Regular Contributor
timestamp: August 04, 2013, 07:24:07 pm
content: -PicbasicAs a hobbyist it works fine for me

author: free_electron
author_rank: Super Contributor
timestamp: August 04, 2013, 07:57:50 pm
content: Quote from: Bored@Work on August 04, 2013, 06:39:30 pmah.. the infamous 'slideware'

author: Psi
author_rank: Super Contributor
timestamp: August 04, 2013, 08:51:47 pm
content: Embedded programming - C (AVRStudio)PC application programming - Delphi (Delphi 7/XE)

author: andyturk
author_rank: Frequent Contributor
timestamp: August 04, 2013, 10:50:13 pm
content: Current job:C/C++PythonPrevious jobs:SQLRubyPerlJavaObjective-CPrologAssemblyHP-41CCoolest language I've seen recently:q/kdb+

author: tanstaafl
author_rank: Contributor
timestamp: August 04, 2013, 11:09:18 pm
content: Quote from: andyturk on August 04, 2013, 10:50:13 pmmight be until you have to spend 8 hours a day working with itActually 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

author: digsys
author_rank: Unknown
timestamp: August 04, 2013, 11:28:44 pm
content: AssemblerVB6MASM

author: westfw
author_rank: Super Contributor
timestamp: August 05, 2013, 04:20:39 am
content: 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.

author: andyturk
author_rank: Frequent Contributor
timestamp: August 05, 2013, 05:36:28 am
content: Quote from: tanstaafl on August 04, 2013, 11:09:18 pmI suspect those hours are well paid.QuoteYuck. Trying to write Java/C++ as if it was q is goofy.

author: c4757p
author_rank: Super Contributor
timestamp: August 05, 2013, 06:33:52 am
content: Goofy indeed. On the bright side, it has got to be better than trying to write Java as Java

author: millerb
author_rank: Regular Contributor
timestamp: August 05, 2013, 07:03:57 am
content: 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.

author: JuKu
author_rank: Frequent Contributor
timestamp: August 05, 2013, 11:07:21 am
content: Embedded: CDesktop: C#Hw: verilog

author: Neilm
author_rank: Super Contributor
timestamp: August 05, 2013, 05:50:02 pm
content: 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 BasicIf 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

author: hans
author_rank: Super Contributor
timestamp: August 08, 2013, 09:41:47 pm
content: FPGA: VHDLEmbedded: C / assemblerDesktop 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.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#

author: westfw
author_rank: Super Contributor
timestamp: August 08, 2013, 10:56:48 pm
content: 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.))

author: Tris20
author_rank: Regular Contributor
timestamp: August 09, 2013, 09:52:11 am
content: 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?

author: ptricks
author_rank: Frequent Contributor
timestamp: August 09, 2013, 10:44:06 am
content: embedded--------C - XC sereis from MicrochipASMOshonsoft Basic - really easy to use basic that compiles well and has very similar code between versions for AVR,PIC,8085,z80http://www.oshonsoft.com/Coocoox COS for the ARM stuffhttp://www.coocox.org/CoOS.htmPC-----------------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/

author: Kremmen
author_rank: Super Contributor
timestamp: August 09, 2013, 07:07:32 pm
content: Quote from: Tris20 on August 09, 2013, 09:52:11 amC 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 objectshttp://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.

author: westfw
author_rank: Super Contributor
timestamp: August 09, 2013, 10:23:23 pm
content: QuoteI 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.QuoteYes, 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.

author: nctnico
author_rank: Super Contributor
timestamp: August 09, 2013, 11:26:35 pm
content: 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.

author: WarSim
author_rank: Frequent Contributor
timestamp: August 09, 2013, 11:52:20 pm
content: 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.

author: boz
author_rank: Regular Contributor
timestamp: August 18, 2013, 05:52:30 am
content: Embedded: C (mplab 32 and 8 bit)PC: Delphi or LazarusThe Wife: Chocolates

author: andyturk
author_rank: Frequent Contributor
timestamp: August 18, 2013, 06:21:04 am
content: Quote from: boz on August 18, 2013, 05:52:30 amTry giving her a foot massage.Oh yeah.

author: Otatiaro
author_rank: Regular Contributor
timestamp: August 19, 2013, 12:06:31 pm
content: 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.

author: AntiProtonBoy
author_rank: Frequent Contributor
timestamp: August 30, 2013, 03:55:02 pm
content: C, C++, Objective-C, GLSL

author: rizzy
author_rank: Contributor
timestamp: September 08, 2013, 08:14:50 pm
content: Please don't take it too seriously but I couldn't withstand

author: WarSim
author_rank: Frequent Contributor
timestamp: September 08, 2013, 09:32:58 pm
content: Quote from: rizzy on September 08, 2013, 08:14:50 pmGreat a PTCD flashback

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 08, 2013, 10:17:06 pm
content: 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.

author: dr.diesel
author_rank: Super Contributor
timestamp: September 08, 2013, 10:20:37 pm
content: Quote from: mikeselectricstuff on September 08, 2013, 10:17:06 pmIf you ever find yourself needing something very similar under Linux, check out gambas3. It's quite good, feature complete and like VB6, super easy.

author: firewalker
author_rank: Super Contributor
timestamp: September 08, 2013, 10:24:26 pm
content: 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=837910http://download.microsoft.com/download/e/f/b/efb39198-7c59-4ace-a5c4-8f0f88e00d34/vb6mousewheel.exeAlexander.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 08, 2013, 10:26:46 pm
content: Quote from: firewalker on September 08, 2013, 10:24:26 pmTried a few things including that, but have never managed to get mouse scrolling working reliably with the mouse I use, especially under Win7

author: c4757p
author_rank: Super Contributor
timestamp: September 08, 2013, 10:27:32 pm
content: Quote from: mikeselectricstuff on September 08, 2013, 10:17:06 pmProbably 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 08, 2013, 10:34:17 pm
content: Quote from: c4757p on September 08, 2013, 10:27:32 pmI have a deep mistrust of anything that takes me further away from the underlying assembly.... VHDL makes me itch.

author: c4757p
author_rank: Super Contributor
timestamp: September 08, 2013, 10:38:18 pm
content: That's because it's not VerilogMaybe 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 inlineasmstatement 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!

author: IanB
author_rank: Super Contributor
timestamp: September 08, 2013, 10:45:19 pm
content: Quote from: mikeselectricstuff on September 08, 2013, 10:34:17 pmThat'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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 08, 2013, 10:49:55 pm
content: Quote from: c4757p on September 08, 2013, 10:38:18 pmProbably 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.QuoteI'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!

author: firewalker
author_rank: Super Contributor
timestamp: September 08, 2013, 10:50:06 pm
content: Quote from: mikeselectricstuff on September 08, 2013, 10:26:46 pmTBH never tried VB6 on a non WinXP system. After that addon I had no problems.Alexander.

author: firewalker
author_rank: Super Contributor
timestamp: September 08, 2013, 10:53:58 pm
content: Alexander.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 08, 2013, 10:55:04 pm
content: Quote from: IanB on September 08, 2013, 10:45:19 pm..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.

author: c4757p
author_rank: Super Contributor
timestamp: September 08, 2013, 10:59:34 pm
content: Quote from: mikeselectricstuff on September 08, 2013, 10:55:04 pmOoh.... that sounds horrifying...

author: firewalker
author_rank: Super Contributor
timestamp: September 08, 2013, 11:01:08 pm
content: Hours of fun! /Me runs!Alexander.

author: c4757p
author_rank: Super Contributor
timestamp: September 08, 2013, 11:11:13 pm
content: Quote from: firewalker on September 08, 2013, 10:53:58 pmRuby: 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...

author: IanB
author_rank: Super Contributor
timestamp: September 08, 2013, 11:21:20 pm
content: Quote from: mikeselectricstuff on September 08, 2013, 10:55:04 pmI 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 thenextFP 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.

author: HackedFridgeMagnet
author_rank: Super Contributor
timestamp: September 09, 2013, 12:52:06 am
content: 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.Quote(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.

author: firewalker
author_rank: Super Contributor
timestamp: September 09, 2013, 07:52:55 am
content: Ha, I forgot Pascal. Actually I useLazarus.Alexander.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 09, 2013, 08:38:28 am
content: Quote from: HackedFridgeMagnet on September 09, 2013, 12:52:06 am

author: jaxbird
author_rank: Frequent Contributor
timestamp: September 09, 2013, 08:39:33 am
content: 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

author: JTR
author_rank: Regular Contributor
timestamp: September 09, 2013, 10:09:17 am
content: I code mostly in assembler, C and VB6 which, of course, all means that my most often used language is FOUL language.

author: andyturk
author_rank: Frequent Contributor
timestamp: September 09, 2013, 05:26:22 pm
content: Quote from: c4757p on September 08, 2013, 11:11:13 pmI duck-punched a class once. I felt dirty afterwards.

author: Kjelt
author_rank: Super Contributor
timestamp: September 09, 2013, 08:37:44 pm
content: For embedded SW: mostly C (99%) and 1% assembli only whena) it can't be done in C (like shifting with carry)b) it is MUCH faster in assemblic) the compiler screws upFor 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)

author: marshallh
author_rank: Unknown
timestamp: September 09, 2013, 08:44:19 pm
content: Verilog and C, c#

author: hughes_k
author_rank: Contributor
timestamp: October 07, 2013, 12:34:36 am
content: 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 terminalC for embedded software.MATLAB for data analysis. It's a subpar language, but the mathematical functions and plotting abilities available are second to none.

author: Richard_Fry
author_rank: Contributor
timestamp: October 07, 2013, 02:32:39 am
content: C for embeddedVHDL on CPLDsVB.net for any quick windows apps to talk to hardware and I don't go much further than that for PC apps

author: psycho0815
author_rank: Regular Contributor
timestamp: October 07, 2013, 07:53:01 am
content: At work (i'm a Software Developer, not EE):Java,some vb, vb.net, vbaCOBOL, well Delta ADS actually, but no one knows what that is, anyway.At Home/Hobby:C/C++ for embedded stuffAssembler on AVR if i have toPython for almost any scriptingtask these dayssome shellscripting

author: GeorgeHahn
author_rank: Contributor
timestamp: October 07, 2013, 09:02:21 am
content: Embedded - C (though I'd love to see Rust on embedded)Desktop - JS to C# to Python and beyond

author: filip_cro
author_rank: Regular Contributor
timestamp: October 07, 2013, 11:00:05 am
content: C - microcontrollersassembler - I need to use it in school.

author: WarSim
author_rank: Frequent Contributor
timestamp: October 07, 2013, 04:13:01 pm
content: Quote from: psycho0815 on October 07, 2013, 07:53:01 amNot 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.

author: flattermann1822
author_rank: Contributor
timestamp: October 07, 2013, 04:45:28 pm
content: C for embedded,C# forms for simple gui applications,labview for testing and measurement,java/android

author: twistedresistor
author_rank: Contributor
timestamp: October 07, 2013, 05:00:09 pm
content: 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.

author: GadgetUK
author_rank: Contributor
timestamp: October 07, 2013, 05:17:25 pm
content: 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.

author: MirXas
author_rank: Newbie
timestamp: October 07, 2013, 05:56:20 pm
content: In my opinion, C is for embedded electronics (uC's and other).Pascal - for schools, newbies (to learn the basics)

author: Abstr7ct
author_rank: Regular Contributor
timestamp: October 07, 2013, 06:07:11 pm
content: General Purpose Programming: C, C++Embedded System Programming: CDigital Design: VHDLAt 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.

author: dannyf
author_rank: Super Contributor
timestamp: October 07, 2013, 06:43:31 pm
content: I use one language exclusively: whatever works.

author: elektronchika
author_rank: Contributor
timestamp: October 07, 2013, 07:44:54 pm
content: I use VHDL for FPGA and SystemVerilog for verificationC/C++ for MCUNothing special...

author: xstream
author_rank: Newbie
timestamp: October 07, 2013, 10:46:28 pm
content: From most to least used:PHPJavaJavaScriptCVB

author: i_like_sparks
author_rank: Contributor
timestamp: October 08, 2013, 12:38:48 am
content: I use mostly MATLAB for quick prototyping and C++ to make it fast.

author: 99wilksjam
author_rank: Newbie
timestamp: October 09, 2013, 01:25:57 am
content: 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.

author: perfect_disturbance
author_rank: Regular Contributor
timestamp: October 09, 2013, 01:52:32 am
content: I'm going to drop an esoteric one here ColdFusion (hey what can I say it's my day job)When I get to choosePython for web and system stuff.Java for object oriented stuffPerl for text processing.C for embeddedReally 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.

author: zapta
author_rank: Super Contributor
timestamp: October 09, 2013, 02:07:49 am
content: 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.

author: cloudscapes
author_rank: Regular Contributor
timestamp: October 09, 2013, 03:28:29 am
content: C for 32bit micros.Basic (bascom) for AVRs. I started on these before I learned C, so if I were to learn themagainfor 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.

author: HackedFridgeMagnet
author_rank: Super Contributor
timestamp: October 09, 2013, 04:46:28 am
content: 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/

author: true
author_rank: Frequent Contributor
timestamp: October 09, 2013, 05:05:15 am
content: English.

author: klox
author_rank: Newbie
timestamp: October 09, 2013, 10:07:39 pm
content: Anyone else program in Spanish?

author: c4757p
author_rank: Super Contributor
timestamp: October 09, 2013, 10:12:04 pm
content: The last time I tried that, my family threatened me with a visit to the psychiatrist.

author: kphannan
author_rank: Unknown
timestamp: October 10, 2013, 01:34:46 pm
content: I have to say quite a varied assortment:Java - User facing applications (along with Objective-C)C - EmbeddedC++ - EmbeddedObjective-C - iOS & Mac systems - some C / C++ for real low level stuff.Bash - scripting - glue to hold projects together - automationPerl - similar uses to BashPHP - websitesC / 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++.

author: davemisbehave
author_rank: Unknown
timestamp: October 16, 2013, 11:50:26 pm
content: 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.

author: perfect_disturbance
author_rank: Regular Contributor
timestamp: October 17, 2013, 02:24:03 am
content: Quote from: davemisbehave on October 16, 2013, 11:50:26 pmDon't fear C++ It's just c with objects and objects rock.

author: denizcan
author_rank: Regular Contributor
timestamp: October 18, 2013, 01:54:21 am
content: 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 asthisand C++ is better than you in doing that.. except from virtual methods, only addition isthis.. 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:Code:// using usart0 as spiusart0Spi.open();MCP4921 dac;dac.setPort(usart0Spi);dac.setValue(1234);Code:// using spi0spi0.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?

author: denizcan
author_rank: Regular Contributor
timestamp: October 18, 2013, 02:08:44 am
content: 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..Code: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"..

author: andyturk
author_rank: Frequent Contributor
timestamp: October 18, 2013, 05:54:28 am
content: Quote from: denizcan on October 18, 2013, 02:08:44 amCode 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.QuotePatience, young grasshopper.C++ exception handling makes sense when you understandwhyit 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 checkeverythingand check itall 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 theRAIIidiom. 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.QuoteYep. 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 usingEigenin an embedded environment, for some badass number crunching. Very cool stuff.

author: denizcan
author_rank: Regular Contributor
timestamp: October 18, 2013, 11:18:05 am
content: QuoteWhat 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..QuoteAgain 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 boldcurrent implementationis 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..

author: westfw
author_rank: Super Contributor
timestamp: October 23, 2013, 05:58:01 am
content: QuoteNo 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*?) Oh, wait!Code: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?

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: October 23, 2013, 05:02:38 pm
content: 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.

author: sjheiss
author_rank: Newbie
timestamp: October 26, 2013, 05:03:44 am
content: Quote from: HackedFridgeMagnet on October 09, 2013, 04:46:28 amI'm glad someone mentioned Piet.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.

author: blewisjr
author_rank: Frequent Contributor
timestamp: October 26, 2013, 11:57:32 am
content: I know many programming languages but they ones I use the most right now are...AVR Assembler (AVRASM2)CI 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.

author: denizcan
author_rank: Regular Contributor
timestamp: October 26, 2013, 12:29:11 pm
content: Quote from: westfw on October 23, 2013, 05:58:01 amWhat'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..

author: denizcan
author_rank: Regular Contributor
timestamp: October 26, 2013, 12:47:22 pm
content: QuoteWhere 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:Code: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:Code:Byte radioBuffer;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 thingif (radioEvent.wait(100)){//packet receivedradio.readFrame(radioFrame);// handle packet}elseradio.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 thisCode:if (radio.receive(radioBuffer, 100)){//frame received}Still, Where is non-static behaviour?

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: October 26, 2013, 01:47:49 pm
content: 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.

author: andersm
author_rank: Super Contributor
timestamp: October 26, 2013, 02:22:09 pm
content: Quote from: denizcan on October 26, 2013, 12:29:11 pmYou 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.

author: denizcan
author_rank: Regular Contributor
timestamp: October 26, 2013, 08:59:14 pm
content: Quote from: 0xdeadbeef on October 26, 2013, 01:47:49 pmNope 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 RAMtoday, 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 Cin 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..

author: denizcan
author_rank: Regular Contributor
timestamp: October 26, 2013, 10:24:32 pm
content: Quote from: andersm on October 26, 2013, 02:22:09 pmI 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 useWord Queue::pop(T& value)This makes usage a lot easier:Code:Short v;if (queue.pop(v)){// use v, as an exampledac.setValue(v);}the other is easier when you use as parameter:Code: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:Code:Short buffer;Queue<Short> queue(buffer, sizeof(buffer));Static allocation is not asdynamicas dynamicallocation 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..

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: October 26, 2013, 10:45:26 pm
content: Quote from: denizcan on October 26, 2013, 08:59:14 pmWell, as you claimed I wrote the opposite of what I wrote, I kinda gave up on reading all the futile details.Quote from: denizcan on October 26, 2013, 08:59:14 pmPretty 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.Quote from: denizcan on October 26, 2013, 08:59:14 pmI 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.Quote from: denizcan on October 26, 2013, 08:59:14 pmAnd 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.Quote from: denizcan on October 26, 2013, 08:59:14 pmTrue. 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++.Quote from: denizcan on October 26, 2013, 08:59:14 pmNot really.Quote from: denizcan on October 26, 2013, 08:59:14 pmGUI 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.Quote from: denizcan on October 26, 2013, 08:59:14 pmNope.Quote from: denizcan on October 26, 2013, 08:59:14 pmWrong 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.Quote from: denizcan on October 26, 2013, 08:59:14 pmOur 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.Quote from: denizcan on October 26, 2013, 08:59:14 pmIf 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.

author: denizcan
author_rank: Regular Contributor
timestamp: October 31, 2013, 11:26:56 am
content: You claim something but you do not give any measurable data.. For instance:QuoteWhy? 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 thanusual, 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?QuoteAgain, 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.QuoteYes 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 onimplementation- 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:Code: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 settingswindow.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:Code:label.allocateTextBuffer(80);orCode:Char labelBuffer;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.QuoteCompiler 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 makingcallingthem 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.QuoteAgain, no solid info, no measurement. Please at least give a task and why polymorphism is not up to that..QuoteOk, 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?

author: westfw
author_rank: Super Contributor
timestamp: October 31, 2013, 07:26:49 pm
content: QuoteIsn't a lot of polymorphism handed at compile time? Function overloading is considered polymorphism, for instance.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: October 31, 2013, 09:51:38 pm
content: 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.

author: denizcan
author_rank: Regular Contributor
timestamp: October 31, 2013, 10:08:57 pm
content: Quote from: westfw on October 31, 2013, 07:26:49 pmoverloads 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 callCode:0x000001E6 6801 LDR r1,[r0,#0x00]; load vptr to r10x000001E8 6809 LDR r1,[r1,#0x00]; load function pointer to r10x000001EA 4788 BLX r1; call r1direct function callCode: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:Code:void UART_Open(int iUartId){switch(iUartId){case 0://open uart 0, bla blabreak;case 1:// oprn uart 1 bla blabreak;}}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..

author: Slothie
author_rank: Regular Contributor
timestamp: October 31, 2013, 10:18:01 pm
content: Quote from: Tris20 on August 04, 2013, 06:54:18 pmIn 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.

author: denizcan
author_rank: Regular Contributor
timestamp: October 31, 2013, 10:33:21 pm
content: QuoteNope, 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..QuoteNope 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:Code: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..

author: Tris20
author_rank: Regular Contributor
timestamp: November 02, 2013, 01:08:08 am
content: 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!.