How many people code in C these days, and if so, why? - Page 1
Forum section: electronics / general

author: IanB
author_rank: Super Contributor
timestamp: May 03, 2020, 03:42:33 pm
content: I think the last time I wrote any code for a C compiler was about 20 years ago. Since then, using C++ has just been more convenient. After using C++, C just seems too painful and restrictive.There are often coding discussions here, where people seem to be talking about "C", but I'm not sure if everyone is being precise in their language, or if they may actually be using a C++ compiler? For instance, Visual Studio technically has a C compiler, but it is somewhat hidden and you have to take special steps to invoke it.If you do write in C these days, what is the reason? Is it because there is no C++ compiler for your target hardware, or are there special advantages to C that make you prefer it?

author: Yansi
author_rank: Super Contributor
timestamp: May 03, 2020, 03:58:33 pm
content: This thread should be locked. NOW.

author: Warhawk
author_rank: Frequent Contributor
timestamp: May 03, 2020, 04:03:30 pm
content: Quote from: IanB on May 03, 2020, 03:42:33 pmCode what? I've been in the industry for more than 10 years and have never seen anything else but C (with small exceptions such as ASM and C++) for embedded applications. And I am talking about quite big projects for industrial automation and automotive. In my opinion, C offers a good balance between portability, readability, comfort, and the level of abstraction between the hardware and software. More sophisticated language, higher the level of abstraction, and less control of the hardware. This is a big deal for realtime applications. I like that I can open the ASM listing and C side-by-side and see how my code works.So my two cents - C for embedded, Python for "getting things done".

author: Karel
author_rank: Super Contributor
timestamp: May 03, 2020, 04:06:25 pm
content: I find C++ a horrible language, so I use plain C most of the time.For GUI development I use Qt which is a C++ framework. This requires to use C++ and classes.But I only write the bare minimum of C++, necessary to use Qt.Fortunately you can write pure C code in .cpp files and it will compile fine (most of the time!).Also, many modules that have nothing to do with the GUI, are in plain C and contain lines like:Code:#ifdef __cplusplusextern "C" {#endifThis way I can write real plain C code also in Qt (C++) projects.

author: maginnovision
author_rank: Super Contributor
timestamp: May 03, 2020, 04:10:33 pm
content: I mostly use C++ because it's easier and cleaner to get some things done. I use C a lot for some smaller projects and projects where C++ is really not an option. One processor I work with the linker chokes on C++ generated intermediate files constantly so it's basically not allowed unless you want to figure out which parts of the C++ code it didn't like.

author: Warhawk
author_rank: Frequent Contributor
timestamp: May 03, 2020, 04:18:02 pm
content: Quote from: Karel on May 03, 2020, 04:06:25 pmKarel, In my opinion you combined the worst from both worlds. I used to have a colleague who programmed everything in ASM. His C files were #asm #endasm directives everywhere. A nice gentleman but I had to let him go. Nobody understood his work.

author: Karel
author_rank: Super Contributor
timestamp: May 03, 2020, 04:38:50 pm
content: Quote from: Warhawk on May 03, 2020, 04:18:02 pmI have never been out of a job and caring about your opinion is very low on my priority list.Maybe I was a bit rude. I apologize.

author: Kalvin
author_rank: Super Contributor
timestamp: May 03, 2020, 04:43:11 pm
content: I use C in projects that are targeted for smaller processors with limited RAM/code space and/or no C++ compiler [with decent price or code quality] is available for the given processor. For the projects with more target processor resources available and support for at least C++11, I prefer [a small subset of] C++. Said that, I am now using C in the current project due to the fact that the project team is more comfortable with using C instead of C++.Ps. I also check quite often the assembly code generated by the compiler so that I do not write anything stupid which would bloat my code.

author: coppice
author_rank: Super Contributor
timestamp: May 03, 2020, 04:48:20 pm
content: Quote from: IanB on May 03, 2020, 03:42:33 pmI think the last time I wrote any code for a C++ compiler was about 23 years ago. Using C has always been more convenient. After using C, C++ just seems too painful and restrictive.There are often coding discussions here, where people seem to be talking about "C++", but I'm not sure if everyone is being precise in their language, or if they may actually writing C, and just compiling it using a C++ compiler? For instance, Visual Studio technically has a C++ compiler, but many of us use it to compile the same C source code files we compile with GCC, IAR and other C compilers.If you do write in C++ these days, what is the reason? Is it because there is no C compiler for your target hardware, or are there special advantages to C++ that make you prefer it?

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 03, 2020, 04:50:20 pm
content: I also mostly use C, and also consider C++ a monster with too many quirks.C compilers are virtually available for any target, are robust.I mostly do embedded dev these days though as far as programming goes, and otherwise a few command-line tools. I used to write GUI apps in C in the past, very rarely these days, although I have written a cross-platform GUI library in C based on OpenGL which allows to write cross-platform GUI apps in C in a decent way. Not too shabby but I wouldn't want to spend my whole time doing this anyway.My use of C is pretty object-oriented though (at least in the base concepts of OO), and with C properly used and mastered, I've never really found C++ to add much convenience for that overall. Of course, YMMV a lot.C++ is too complex IMHO, and promotes a kind of OO programming that can yield monster code bases that can be very hard to evolve. Badly used inheritance, for example, can make your life a hell in the long run. Of course this is not specific to C++, it's common with many OO languages that support multiple inheritance. Another pitfall with C++ is that in practice, it's a very "fragmented" language, because it's so complex that most developers tend to use their own subset. Lastly, C++ compilation times are much longer than C compilation times, which granted is not that important, but that's an additional benefit of using C in my eyes.

author: IanB
author_rank: Super Contributor
timestamp: May 03, 2020, 04:54:21 pm
content: Quote from: Karel on May 03, 2020, 04:06:25 pmQuoteThese two statements are in contradiction to each other. If your source file has a .cpp extension you are invoking the C++ compiler and complying with the C++ language standards.So we can put you in the group of people who use C++, even if you are restricting yourself to a subset of the language.

author: coppice
author_rank: Super Contributor
timestamp: May 03, 2020, 04:58:59 pm
content: Quote from: IanB on May 03, 2020, 04:54:21 pmIf that's the kind of logic you use, you could have a great career as a religious apologist.

author: Karel
author_rank: Super Contributor
timestamp: May 03, 2020, 04:59:53 pm
content: Quote from: IanB on May 03, 2020, 04:54:21 pmFormally you are correct, I use both C and C++.

author: IanB
author_rank: Super Contributor
timestamp: May 03, 2020, 05:00:33 pm
content: I sense (as I expected) that C is used for embedded work on low level hardware.However, C++ offers a vast toolkit of features to choose from, and you are not obligated to use them all. You can restrict yourself to a small subset and still have a more comfortable time while writing compact, efficient and transparent code.Anyway, I got my answer. Many people are writing in C these days, and [in this forum] it is [mainly, it seems] for embedded applications.

author: bd139
author_rank: Super Contributor
timestamp: May 03, 2020, 05:02:34 pm
content: I still write stuff in C. In fact I'm just working through fixing 20 years of pain in a 95KLOC C program. Why do I still use it:1. Knowledge is retained and valuable for 30 years now. That was a good investment as it allows you to get really good at the language.2. The toolchains available are mature, light weight and reliable.3. Relative simplicity allows compilers to make excellent optimisations.4. It's small enough to fit in your head.5. It works the same on everything from embedded to desktop applications.6. It's low enough level to be used for system programming and with abstractions high enough to build high level applications with.7. It's damn fast.8. It allows you to decide where your performance tradeoffs are made.9. Intent can be clearly expressed.The above program discussed has been rewritten twice so far. One talented individual rewrote it in C++ using templates and boost. It never worked and was too difficult to extend. It was also 20% slower. Someone came along and thought hey lets do it in C#. Nope! Better than C++ but still too slow (70% slower creating objects galore) and eats 400Gb (yes 400Gb) of memory. I'm sure someone will come along and suggest Rust soon and blow a lot of money unsuccessfully rewriting it again.For now I'll look objectively at each problem and invest in that 30 year knowledge in that 20 year old codebase. Which is older than Rust, older than C# and older than a version of C++ that even begins to make sense.For ref this is a high level matching engine, not a system program and not embedded. It reads a DSL and reference data from disk into memory and then streams about 100 megabits of traffic in peak (per process), matches, tags and routes it. It has had uptimes of over three years for a single process historically speaking.The only problems are is it's an unsafe language, which is solved mostly using your brain a bit longer, then Valgrind and Coverity...Edit: I will not this is not my day job. I'm doing this because it's fun and accidentally getting paid for it on the side. My day job is running entirely the opposite of this and dealing with the several order of magnitude more pain.

author: Karel
author_rank: Super Contributor
timestamp: May 03, 2020, 05:03:44 pm
content: Quote from: IanB on May 03, 2020, 05:00:33 pmMaybe I'm an exception but all non-GUI software I write for the pc is written in C using gcc, not g++!

author: coppice
author_rank: Super Contributor
timestamp: May 03, 2020, 05:06:57 pm
content: Quote from: IanB on May 03, 2020, 05:00:33 pmC is still used heavily for server, and HPC applications, as well as embedded.

author: IanB
author_rank: Super Contributor
timestamp: May 03, 2020, 05:07:43 pm
content: Quote from: coppice on May 03, 2020, 04:58:59 pmReligion is about vague, unprovable assertions.Technology is about facts.It is a fact that some things that will be accepted by a C compiler will be rejected by a C++ compiler, and vice versa. So if you compile "C" with a C++ compiler, there is no guarantee that your code will be accepted by a C compiler. The standards are different.Quote from: Karel on May 03, 2020, 05:03:44 pmIf you invoke gcc on a file with .cpp extension it will use the C++ compiler unless you force it to do otherwise. Similarly, if you invoke gcc on a file with a .c extension, then it will use the C compiler by default. So if your files have a .c extension, then I will agree that you are using C.

author: IanB
author_rank: Super Contributor
timestamp: May 03, 2020, 05:09:40 pm
content: Quote from: coppice on May 03, 2020, 05:06:57 pmInteresting. Post edited.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 03, 2020, 05:10:58 pm
content: Different tools for different tasks. For me, C# is great for UI-based stuff. C++ comparatively sucks for that, but is great for graphics API stuff (DirectX, OpenGL, etc.). And C is great for lower level hardware stuff.I suppose the best software developers learn ALL the tools and use the best one for the job, rather than sticking with one and getting offended when anyone disagrees.Geez guys.

author: Karel
author_rank: Super Contributor
timestamp: May 03, 2020, 05:17:13 pm
content: Quote from: IanB on May 03, 2020, 05:07:43 pmYes, my files have .c extensions.

author: rstofer
author_rank: Super Contributor
timestamp: May 03, 2020, 05:39:22 pm
content: How many of the advanced features of C++ are used in the Linux operating system? I don't know the answer but I think it is zero. Linux is written in C. I'm pretty sure Windows is as well. Both are really huge code bases but somehow it all works out.I have spent about 20 years trying to build up any enthusiasm for C++ and I just can't get there. I'm just too old to learn C++ and, since I'm not trying to cure world hunger, I don't see any reason to bother. Most of my work is in the embedded space and C++ doesn't bring much to the dance.I'll stick with Fortran and C while the world moves on.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 03, 2020, 05:45:28 pm
content: Quote from: rstofer on May 03, 2020, 05:39:22 pmI hear ya...but if you want a lot of fun try writing a ray tracer for 3D graphics.It's a ton of fun, and C++ is almost mandatory. Although I think C and C++ are pretty much interchangeable with those graphics API's.And then tie that into a C# interface and GUI.And yeah, I have lots of fond memories of FortranAre there still compilers available for that?? Hmm.......

author: nctnico
author_rank: Super Contributor
timestamp: May 03, 2020, 05:49:55 pm
content: Quote from: IanB on May 03, 2020, 03:42:33 pmI code a lot in C. Mostly on microcontrollers and projects which where written in C. If I have a chance I like to use C++. Using objects makes for cleaner interfaces (like having functions with default arguments and the same functions with different parameters) and I like that I can avoid pointers in C++. And then there is the STL library which has many useful features. I'm not saying C++ is perfect for everything. I use Lua as well and likely Python will be added at some point.

author: Kjelt
author_rank: Super Contributor
timestamp: May 03, 2020, 05:52:15 pm
content: Quote from: IanB on May 03, 2020, 03:42:33 pmI graduated in the 90s became an EE , since then had 12 SW jobs with 5 companies and I solely have written C and now for the testing some Python.First companies the target was 64kB upto 1MB with 100-200klocsLast company is 650+MB code, est. 300+Mlocs and growing, I luckily only work wit 20Mlocs of that, and still everything except the unittests and other tests is in C.Why? Because the companies use it and want it and it still is the defacto standard for serious industrial machines and real time hardware. If you program GUIs or games or internet stores, websites etc. choose something more appropriate for that.

author: IanB
author_rank: Super Contributor
timestamp: May 03, 2020, 05:54:15 pm
content: Quote from: engrguy42 on May 03, 2020, 05:45:28 pmYup. We still maintain Fortran code at work.There was a time when Fortran compilers could do better optimizations and produce faster code than C compilers. It may still be the case sometimes for all I know. I think there is still an arms race going on between the compiler writers.

author: Kjelt
author_rank: Super Contributor
timestamp: May 03, 2020, 05:55:57 pm
content: By the way, ever tried reprogramming 300Mlocs of C code that is tested and prooven over 25 years, and then start all over in another language?How many thousands of SW engineers and hundreds of millions of $ would that cost ?

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 03, 2020, 05:57:36 pm
content: Quote from: Kjelt on May 03, 2020, 05:52:15 pmI assume when you're dealing with commercial/industrial products you generally want low cost and efficiency, which I assume pushes companies towards lower level languages with fewer frills and memory and hardware requirements and costs. So I imagine C and ASM and the lower level stuff are the go-to languages in those environments.

author: IanB
author_rank: Super Contributor
timestamp: May 03, 2020, 05:58:18 pm
content: Quote from: Kjelt on May 03, 2020, 05:52:15 pmI think there is a large space for industrial and scientific software between those two extremes. For instance, would you rather write a Spice circuit simulator in C or C++?

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 03, 2020, 06:19:50 pm
content: Quote from: IanB on May 03, 2020, 05:58:18 pmI don't think it's an either/or proposition necessarily. I can imagine writing the GUI for a Spice simulator in C# since it's so quick and easy, but for the core simulation stuff you might want to write it in the most optimizable and fast language (maybe on that has ready access to pertinent math libraries) needed for the actual timestep simulation stuff. And if you're writing it for specific hardware to speed up simulations (like a GPU, for example) that adds another consideration, depending on the best API for that hardware.

author: technix
author_rank: Super Contributor
timestamp: May 03, 2020, 06:33:43 pm
content: I do, and I have three reasons for it:1. Efficiency. C generates little surprising and/or additional code, even if you aren't exactly extremely familiar with your compiler. This allow you to think in terms of assembly instructions and clock cycles for an embedded software project, but you don't have to really mind the minute details like register allocation, ABI and even actual assembly mnemonics. And in the corner case when it arises, you can inline assembler directly. Also C has a tiny runtime, which means code is small and efficient.2. Portability. For higher level programs I still prefer C over other languages, as it provides excellent portability between various operating systems. My daily driver machine runs macOS on Intel, and some of my projects target Raspberry Pi. As long as I stick to C + POSIX-compliant libc + a few common dependencies like libcurl, libfastcgi and nginx, I can expect my C code, debugged on my macOS workstation, work as designed on the Pi after just a recompile. I can even switch out the compiler if I want (clang on macOS, gcc-9 on Pi.) Don't get me started on C++ as that thing has such a fragile ABI. (There is a reason why Apple now implements the macOS C++ ABI on top of the Objective-C ABI, as that is just more reliable.)3. Control. C gives me full control of the program flow - no garbage collection throwing timings out of the window, no unexpected initializer calls, no confusing operator overloads, etc.

author: Picuino
author_rank: Super Contributor
timestamp: May 03, 2020, 07:14:43 pm
content: C vs C++Vim vs EmacsSpaces vs TabsThey are all religious wars. It is very difficult to make arguments without ending arguing personally.

author: IanB
author_rank: Super Contributor
timestamp: May 03, 2020, 07:52:38 pm
content: Quote from: Picuino on May 03, 2020, 07:14:43 pmI think this thread has done a pretty good job of showing otherwise. People here have been able to present clearly articulated reasons for choosing one thing over another. It doesn't have to be a religious war.

author: Picuino
author_rank: Super Contributor
timestamp: May 03, 2020, 08:25:04 pm
content: In that case I will dare to give my opinion.I use C as an amateur programmer of microcontrollers. For 8 bit PIC microcontrollers there are only C compilers and that is enough.I have also used GCC (C++) for embedded code in the Arduino environment. I think C++ has some advantages when it comes to making separate libraries and separating the developer environment from the user environment. I also appreciate the ability to bring variables and methods together into one class. Namespaces and instantiation are also a good ideas. But you are also at risk of making bad software more easily than in C. And you can't use all the C++ capabilities in embedded environments because of all the overhead involved.

author: Kjelt
author_rank: Super Contributor
timestamp: May 03, 2020, 09:08:54 pm
content: Quote from: engrguy42 on May 03, 2020, 05:57:36 pmFor the first few companies you are correct.Those sold millions of products and each $cent of the BOM was carefully weighed.The last company sells a few hundred machines a year, the cheapest machine costs more than $15 million, the most expensive more than a hundred million $, still the code is in C and it runs on industrial boards with VxWorks but also on an industrial Linux server.So it is hard to generalize.

author: Kjelt
author_rank: Super Contributor
timestamp: May 03, 2020, 09:12:31 pm
content: Quote from: IanB on May 03, 2020, 05:58:18 pmI rather would write that in an OS independent language like Python I guess, more customers. But that is not my field of expertise. And I hate that Python is runtime not compile time.I always stayed close to the hardware, HSI stuff, electronic driver software , motion control, that kind of stuff.I have nothing against C++ or C# by the way , I takeover good habits like the setters and getters you can use that in C also. I don't see the added value of inheritance outside environments like guis like windows where it is the basic way of doing things.Oh well we all row with what the boss has used in the past.

author: coppice
author_rank: Super Contributor
timestamp: May 03, 2020, 09:28:18 pm
content: Quote from: IanB on May 03, 2020, 05:58:18 pmWe know what Spice was written in. Versions 1 and 2 were in Fortran. Version 3 was released in 1989 in C, but its not clear when development began. C++ compilers were getting common by 1989, but might not have been common when development began. So, it not clear if they freely chose C over C++, or they were constrained. Until the mid 90s there were certainly strong reasons one might want to avoid C++, as it kept changing. Many new compiler releases broke existing code. So, for timing reasons Spice might not be the best candidate for looking at whether people choose C or C++.

author: splin
author_rank: Frequent Contributor
timestamp: May 03, 2020, 11:54:46 pm
content: C++ might be better described as a metamorphic (ok, that might only apply to rocks - perhaps it should be 'subject to regular metamorphosis') than OO language. I might eventually manage to get my C++ code from the late 90's past the syntax checker of the latest revision compiler but semantically who knows what it would actually do?When the language evolves faster than your ability to learn the changes you know it's time to abandon ship and settle back into your comfort zone with straight C, warts and all.

author: IanB
author_rank: Super Contributor
timestamp: May 04, 2020, 12:18:24 am
content: Quote from: coppice on May 03, 2020, 09:28:18 pmI was just trying to pick an example that would resonate with people here. Maybe not Spice specifically, but my domain of expertise is in computer simulation software, and it would be hard to consider C as a candidate programming language in a domain that has complex object models, notwithstanding the need for high performance. One has to trade code performance against human performance. Higher level language constructs make things more efficient for the people writing and maintaining the code.

author: coppice
author_rank: Super Contributor
timestamp: May 04, 2020, 12:45:37 am
content: Quote from: splin on May 03, 2020, 11:54:46 pmI think some of us were probably so alienated by C++ endlessly changing in the 90s, that we really can't look at it objectively any more.

author: dmills
author_rank: Super Contributor
timestamp: May 04, 2020, 09:47:18 am
content: Probably a certain truth to that, frigging language would not keep still for long enough for you to actually finish anything....C++ has some good bits, but it is such a vast sprawling mess these days that every engineer knows a DIFFERENT 20% of the language, for me it suffers from not being high level enough to be really efficient for GUI and suchlike work (Where you really want OO), while being just too big and with far too many footguns to make it attractive for small things.That and the fact that on most platforms there is ONE C ABI, while C++ seems to have many depending in subtly ways on compiler options... Makes library things harder then they need to be.C for low level or where speed matters, something MUCH higher level for GUI and suchlike bullshit.

author: Karel
author_rank: Super Contributor
timestamp: May 04, 2020, 11:01:20 am
content: Quote from: dmills on May 04, 2020, 09:47:18 amQt for Python:https://www.qt.io/qt-for-python

author: JPortici
author_rank: Super Contributor
timestamp: May 04, 2020, 11:18:00 am
content: I almost only use C. the microcontrollers i use for both work and hobby only have C compilers. Wish they had C++ sometimes.Maybe i can find some other languages like python or ada but the support is nonexistent (no debug, no USB libraries for example) so there is no point in using those.The only things i don't do in C or C++ are apps, which are done in visual basic (basic 4 android / ios is AWESOME. To hell with java)I believe that if you work with hardware there isn't much you can use besides C. All those reports that C is a fading language are not aimed at people who work with hardware. C will outlast us all

author: bd139
author_rank: Super Contributor
timestamp: May 04, 2020, 11:21:12 am
content: Yes C will indeed outlast us all. Most of the Internet runs on C too.

author: coppice
author_rank: Super Contributor
timestamp: May 04, 2020, 11:36:56 am
content: Quote from: bd139 on May 04, 2020, 11:21:12 amC will certainly outlast C++. C++ usage has decreased a lot in recent years, whether its business server stuff moving to Java, or PC stuff moving to C#.

author: Karel
author_rank: Super Contributor
timestamp: May 04, 2020, 12:24:58 pm
content: One could say that C is the most import programming language, together with Java.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 04, 2020, 12:29:17 pm
content: Take this for what it is of course, but the TIOBE index is in line with this:https://www.tiobe.com/tiobe-index/

author: BBBbbb
author_rank: Unknown
timestamp: May 04, 2020, 12:51:33 pm
content: Few remarks:- In embedded space C is dominant. In safety critical industries C is absolutely dominant. Only space I know Cpp is dominant is Game Dev.- Writing C style in Cpp is not C! There are differences between them. The more complex your SW gets, you'll find yourself digging through obscurities and undefined behaviors... and there are differences...- I used to know Cpp, then I looked at what's done in Cpp17 (and Cpp20), and I have no idea what's going on.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 04, 2020, 01:04:30 pm
content: Quote from: BBBbbb on May 04, 2020, 12:51:33 pmYes. I often warn against this. The standards for the common "subset" between C and C++ are quite different on a number of points.Quote from: BBBbbb on May 04, 2020, 12:51:33 pmAs I often say, C++ looks like some kind of "all you can eat buffet".It's a bit as though, to stay afloat for that long, the C++ committee had to add (/borrow from other languages) as many features and paradigms as they possibly could, and it's still going strong.

author: rstofer
author_rank: Super Contributor
timestamp: May 04, 2020, 06:34:18 pm
content: Quote from: engrguy42 on May 03, 2020, 05:45:28 pmThere is gfortran which is fully compliant with Fortran 95 and implements large chunks of Fortran 2003 and Fortran 2008. It seems to accept the fixed format arrangement of Fortran 77 and earlier.Or, stepping back 50 years or so, I have an IBM1130 emulation running on an FPGA and I can use IBM Fortran IV (which wasn't fully Fortran IV) that I know and love. Sure, it doesn't have the .EQ. type operators and it's missing a lot of other stuff but it, and compilers like it, got us to the Moon. BTW, the 1130 Fortran compiler used 27 passes because the source and the compiler had to fit in machines as small as 4K words. The company machine I used had 8k and my emulation has 32K, the max. The original ran at about 400 kHz and mine runs at 50 MHz.I mess around with Fortran quite a bit. There are some classic functions that come up in engineering school (particularly in the math courses) that are worth coding up just for giggles. Something like Euler's Method for solving differential equations comes to mind. Could I write the code in C or C++, sure! But it belongs in Fortran.MATLAB comes into play quite a bit and the scripting language is somewhat similar to Fortran.Just pick the right tool for the job and move on.In C, I can get data hiding with static variables and I can limit the scope of functions by declaring them static. It's nowhere near as sophisticated as the C++ class but it gets much of the benefit. I use the same 'getters' and 'setters' concepts.

author: tszaboo
author_rank: Super Contributor
timestamp: May 04, 2020, 10:34:36 pm
content: C is great and it is worth learning. They absolutely should start all programmer courses with it. And C++ with all it's fault, extends on it. Even if you dont use a language all features, you can use the underlying ideas when you write code. For example, you can take the OO aspects, and write better C code for microcontrollers.That being said, I'm not a programmer. I'm an EE, who uses programming as a tool to get another job done. I learned python a few years back, and it was a game changer for me. I never want to write C code ever, which would run on a PC. If any of my colleague does it, then my typical question is " whats wrong with you, you could've written that code in python, probably 2 lines". And it is.I occasionally still write C code. Bringing up a MCU or something like that. Or honestly, spending a few days on setting up compilers, linker files, debuggers, licenses for all these, just to write a bitbanging SPI in a few minutes, or something trivial like that. Constantly repeating in myself " this would be 5 minutes on a PC with some REPL".I am wondering when is it all going to change. I mean, I used to write ASM code for PIC16 and AVR8. And most kids are learning some bastardized C++ as Arduino. We've come a long way, but not far enough.

author: bd139
author_rank: Super Contributor
timestamp: May 04, 2020, 10:45:36 pm
content: We went all the way a while ago and everyone misunderstood it (FORTH)

author: nctnico
author_rank: Super Contributor
timestamp: May 04, 2020, 11:15:23 pm
content: Quote from: NANDBlog on May 04, 2020, 10:34:36 pmA few years ago I wanted to give embedded Lua a try to run on a microcontroller (AFAIK there is also micro-Python nowadays). Lack of time and the Lua environment needing more work than I cared for at the moment prevented me from going further. A lot of code doesn't need to run at lightning speed but does stuff which is complicated enough. A high level language certainly helps to make implementing high level functionality easier. Recently I finished a project which involves an embedded Linux platform. The customer can change the functionality using a Lua script (which talks to a device specific API written in C).IMHO there is certainly a future for using languages like Lua and Python on microcontrollers. C and C++ are not very effective to write complicated control algorithms; C and C++ get in the way quickly. But this will probably end up in another 'assembler versus C' like debate which lasted for over a decade.

author: coppice
author_rank: Super Contributor
timestamp: May 04, 2020, 11:18:24 pm
content: Quote from: nctnico on May 04, 2020, 11:15:23 pmPython is a bit of a resource hog, but I've seen people using Lua on quite small devices.

author: IDEngineer
author_rank: Super Contributor
timestamp: May 04, 2020, 11:24:44 pm
content: Answering the subject line: Probably 95% of my freshly authored code is in C99. The other 5% is Assembly on whatever platform, to hand-optimize specific sections of code.I learned C++ when it was released, figuring it was the natural evolution of C. C++ taught me how to recognize when a language is too cumbersome: When you have to think more abouthowto express something in the language rather than actuallydoingit. That's what I always liked about C... it just feels so natural. Like a good oscilloscope, the tool disappears. It just becomes an extension of my brain, like my own fingers are probing the circuit (scope) or my own fingers are moving bits around (language). If you have to keep the scope manual handy, or the language docs open in another window, your tools are getting in your way.I did a HUGE (and very successful) project in Java a few years back. Essentially C with a layer of OO on top. So, like C++ and just as useless. Haven't had a need to touch it since.I recently learned Python to help teach a university course. OMFG. The bad features of many languages, with very few of their advantages. Could I get better at it? Sure... but why? Its major "advantage" is "it has so many canned libraries available". But that's true of C and many other languages. I'm glad I learned Python because now I can honestly steer students AWAY from it.On most platforms, C is the first compiler that is offered. Other languages then (sometimes) follow, using C to build their environment. Which means that whatever platform you're considering, C is probably available. That's a darned strong recommendation for any language.I'm open minded enough to learn new languages (hence Java, and Python). But the real world where actual work gets done and projects get shipped keeps bringing me back to C and Assembly. Maybe I'd feel differently if I worked on mainframes or something where you're widely abstracted from the hardware. But for the work I do down here in the trenches, where the line between hardware and firmware/software gets blurry in a hurry, it just keeps being C.YMMV, not trying to start an(other) argument, just my $0.02, standard disclaimers, etc.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 04, 2020, 11:54:58 pm
content: Quote from: coppice on May 04, 2020, 11:18:24 pmLua is great, and the interpreter is quite small in size (although still not that small for very small devices, but I think there are very stripped down Lua interpreters for those.)Thing to consider though is that, to do anything really useful with Lua, the basic object you have at your disposal is a dynamic table. Dynamic tables ARE Lua (if you wanted to sum it up very shortly.) And so they are not that great a fit for devices with a very small amount of RAM.Now of course you can still do stuff in Lua without using tables, but from my experience, you'd be pretty limited. Just a small thought.

author: bd139
author_rank: Super Contributor
timestamp: May 05, 2020, 07:19:17 am
content: Lua. Hmm.https://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF

author: amyk
author_rank: Super Contributor
timestamp: May 06, 2020, 12:03:53 am
content: I still use C becase it's simple and it works. Both embedded and desktop (Win32). "Modern C++" seems to have developed a disgusting fetish for abstraction and while the source may seem smaller, it creates a hugely bloated binary.

author: spudboy488
author_rank: Regular Contributor
timestamp: May 06, 2020, 12:00:20 pm
content: I develop PCB test equipment in a one man shop. I have 2 preferred CPUs (PIC16F689 and PIC18F46K22) that I use depending on the project. I initially coded in assembly on the 689 but switched to Hi-Tech C when I started using the 46K22.For me, using C allowed, basically, the same code can be used on both CPUs. There are obviously differences but the low level stuff is handled in the libraries I wrote. This hides the CPU differences from the high level test functions. I have base software that will set up each CPU depending on various #define statements and all I have to add is the custom test routines for the project.

author: Picuino
author_rank: Super Contributor
timestamp: May 06, 2020, 01:04:02 pm
content: In an electronics blog like this there will be many examples of microcontroller programmers who prefer to program in c because it is the best or the only high-level language option.But in the world of computer programming, the c language is also the best option for many projects. Operating systems such as Linux, Windows or OSX, drivers, languages ​​interpreted as Python or PHP and even compilers of other languages ​​are all programmed in c.According to the TIOBE index, the C language is the most widely used of all, much more than C++https://www.tiobe.com/tiobe-index/Although C++ is like C with improvements, it seems that the greater complexity of the language is precisely an argument against it.One more reason to program in C is that it is very portable. You can port C libraries between different systems, but C++ libraries cannot. There is not always a C++ compiler available.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 06, 2020, 01:37:58 pm
content: I wouldn't dismiss the benefits of an object-oriented language like C++, or especially C#. As an engineer, it is an incredibly logical and somewhat obvious approach to designing software. A bit like functional programming (eg, FORTRAN functions) on steroids.You treat stuff as objects, with user inputs/interfaces/controls, internal processes, and outputs. Especially if you're modelling/simulating real world stuff it's extremely logical and efficient, IMO.For example, if you're going to simulate a car, it has user interfaces (steering wheel, brakes, gas pedal), internal functions, and outputs. And if you build a model of the car engine and its controls, it's a fully functional block of code you can reuse the next time you simulate a car. Just tweak the object's parameters and you have a different engine.Yeah, some seem to prefer functional, rather than object oriented, and they may have a point in some applications. But if you're simulating real world stuff it's wonderful, IMO.Of course if you're not simulating real world stuff, and doing more abstract stuff, then maybe it's overkill. I've used it to simulate/model control systems, it's great. You end up with a block of code that defines the hardware, maybe even comprised of sub-objects you connect together, and tweak the parameters and you're ready to go. Wonderful.Personally, I couldn't care less what others use, and what's more popular. Different tools for different jobs. And it seems the higher level languages (C++, C#, etc.) are better for more abstract uses, and the lower levels (C, ASM, etc.) for more direct hardware-based stuff.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 06, 2020, 02:22:45 pm
content: Note that you can write (as some of us have already pointed out) code in an object-oriented manner in C. Whether it's more clunky than using C++ is all a question of perspective. As long as you know how to do it, and don't want to implement fancy OO features (which are often highly debatable anyway), doing that in C is not really that much clunky. I'm used to it. I've done that both in C and C++, and quite frankly, if done right, it doesn't even take more lines of code in C, or not significantly so. I'll admit that if you do that, you'll get less "verification" from the compiler, so in that respect, you need to be extra careful.The same goes for functional programming - you can pretty much program in a pure functional way in C. But to be frank, contrary to OO, where it doesn't really add any overhead compared to C++ (again if done right, and again as along as you don't try super fancy paradigms), pure functional programming in C WILL add overhead (sometimes considerable) compared to true functional programming languages that natively optimize a lot of internal data structures and data passing.You can of course also use a mix of approaches.

author: radioactive
author_rank: Regular Contributor
timestamp: May 06, 2020, 02:30:59 pm
content: For me, it is C99 unless I have to write a user interface that will run on Windows. In that case, Java.If you need some embedded scripting capabilities, why not use 'C' for that too?.https://github.com/jpoirier/picoc

author: tom66
author_rank: Super Contributor
timestamp: May 06, 2020, 02:35:06 pm
content: Most of the software I write is C or Python.If it's embedded, it's 99% C (and about 1% assembler, processor dependent.)I've been wondering if I should move to C++ for a certain recent project, but I'm half way in and that's a long curve to get up to speed in a new-ish language.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 06, 2020, 02:36:09 pm
content: Quote from: SiliconWizard on May 06, 2020, 02:22:45 pmAbsolutely true. You CAN do just about anything with any software, just like you can probably build a house using only a screwdriverIMO, what's important is that folks are familiar with each of the tools enough to know what's best for each task, and not restricted by a vague bias based on minimal experience.

author: ace1903
author_rank: Regular Contributor
timestamp: May 06, 2020, 02:45:14 pm
content: C is easier to learn by doing. Many of my colleagues started as electrical engineers with no background in computer science.When they were newbies, we used to give them small tasks to do in project that was 100k+ sloc. All of them completed successfully in a week by looking at the rest of the code and a couple of books.After 3 months they were capable of doing tasks of any order of complexity. Of course, there was support from system architect and obligatory and regular code reviews.The same approach doesn't work for projects in C++. To be good software developer in C++ need some background in computer science.Learning by studying books and doing exercises instead of regular tasks. Code review in C takes an hour or two (incremental patch). Good C++ review is more hours and is much more difficult.Newbies tend to finish tasks fast in C++ but at the expense of resource leaks and random crashes.When I say C++ I think all the features of C++, not C way of programming in C++The ratio of good C developers vs good C developers is something like 1 to 50.C++ makes a better product but it will be expensive.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 06, 2020, 02:59:44 pm
content: Quote from: ace1903 on May 06, 2020, 02:45:14 pmAgain, isn't the important question "What problem do I need to solve?", rather than what's "easier"?I'm surprised nobody has mentioned C#. I think if you want to very quickly and efficiently develop GUI's on Windows that's probably at the top of the list.And if you're doing math-intensive stuff you probably want a language that happens to have some excellent math libraries available so you don't waste time coding them from scratch.And if you're doing graphics-type stuff (ray tracing, etc.) you want a language that fits more closely with what graphics hardware manufacturers' API's develop and support.And if you're coding at a lower hardware level you want an language that is light and efficient for that.And on and on and on...As with most things in the universe, it depends. There's no right answer for everyone. Just be sure to evaluate the problem and look for the best tool that's available. Unfortunately a lot of people take the approach "Oh, I like this, therefore everyone has to like it and think it's the best".

author: Wolfgang
author_rank: Super Contributor
timestamp: May 06, 2020, 03:28:01 pm
content: I've worked in the software industry for 30years+.I've worked in C/C++/COBOL/Pascal/FORTRAN/Assemblers/LUA/Python/PL1/Java/...I've written several languages myself for specialized purposes.My view on (sometimes religious) language debates:- With a clean mind you can solve a problem in (almost) all languages, sometimes more elegant, sometimes harder.- Even the best language cannot keep idiots from coding garbage.- Every good code has this ratio: 10% solution of the problem, 90% defense against idiots.Now (retired) I use:- Plain C for hard numerics (math, speed) and on microcontrollers (Arduino)- Python on the desktop. Reason: Elegant, efficient, lot of useful libraries.

author: ace1903
author_rank: Regular Contributor
timestamp: May 06, 2020, 03:33:23 pm
content: In an ideal world, there will be 50+ C++ developers equally good in math for signal processing and a little bit of hardware (to know to use logic analyzer scope...).But in real-world if you try to find them, either half of them would hate math or will be from some distant country with cultural differences.There was an interesting story from Dropbox I think. They know that C++ is best for them, the product has already a stable code base and benefits from C++.But the available workforce forces them to migrate whole product towards some javascript framework..They have great ideas for new features and improvements but sadly C++ developers don't want to learn their proprietary code base and find it uninteresting and not challenging enough.Couple of days ago I asked project developed in Matlab\python to be ported in C++ for the production environment. Got hundreds of views because description contained neural networks and machine learning.Sadly only one C++ developer applied for the job.

author: Wolfgang
author_rank: Super Contributor
timestamp: May 06, 2020, 04:13:51 pm
content: IMHO, C++ has been expanded to death. The language has become completely unwieldy due to featuritis,is hard to read and its so easy to shoot yourself in the foot.If you use all features to the fullest (multi inheritance, ...) its so easy to write code even the inventor willnot understand anymore after two weeks. C++ tries to do too much, has too many side effects, is hard to debug,not very suited for realtime or small hardware stuff due to memory issues, not extremely fast either, so ...If your problem just calls for a reasonable object-oriented language and performance is not critical -Python. You do the same in a fraction of the code. If its close to hardware or raw speed - pure C.

author: profdc9
author_rank: Frequent Contributor
timestamp: May 06, 2020, 04:26:01 pm
content: I use C++ somewhat for embedded programming but sparingly. Mostly I have used C. I have tried C++ from nearly the beginning in the early 90s.At first, the compilers were flaky and produced code that didn't work. This was eventually fixed.But the C++ added every "kitchen sink" feature that every other language had. Writing a compiler for C++ must be horrendous.The problem with C++ for embedded programming, as I see it, is that it is difficult to audit what code is produced (in size and complexity) when using some of C++ more advanced features. Templates will bloat code enormously. Virtual functions and methods are ok and are probably my favorite feature of the language, but you must be careful casting pointers to make sure that the correct vtables are referenced. However, other languages do polymorphism better (e.g. Objective C). Exception handling is a hot mess. It introduces so many potential code paths that it is very difficult to know how your code will unwind. gotos are better in my opinion because at least you know where the code is jumping to and where its jumping from. Overloaded functions and operators may look nice but also add the possibility of calling the wrong function, especially if the overloaded function has nearly identical functionality (for example, a reference counted version of a regular function). Add to that weird rules for constructors, destructors, when they are called, etc., and you got something deeply confusing and waiting for human error.C may be the manual transmission of coding languages, but it's going to get you there, and you're going to know how much the engine revs when it does.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 06, 2020, 05:02:01 pm
content: Quote from: engrguy42 on May 06, 2020, 02:36:09 pmI think we managed to all be reasonable in this thread, and avoid flame (and language) wars. Let's try and keep it that way.Your comment was of course overly caricatural. My point was mainly to express 1/ what *I* do and why (which was the OP's question) and 2/ just correct the frequent misconception (especially for people exclusively using "higher-level" languages) that C code necessarily has to be a poorly structured mess of functions, global variables and loose data structures, and that you necessarily have to use some higher-level language to write "cleaner" code.And of course, if you read my post, your comment is a bit off: I just pointed out cases where using a reasonable OO paradigm in C would NOT necessarily be much more clunky than in C++ or other. Surely "clunky" is a somewhat subjective appreciation, so not everyone can agree on what it exactly means for them.You won't do that without a generous amount of experience anyway, so your second sentence holds, but I vaguely feel like it was meant to defeat my point. It doesn't. If anything, using C++ because you're convinced it's way better than C for OO programming in general could fall into the category of "vague bias based on minimal experience."Corollary of all this is, sure "the right tool for the job" - a common and general quote, but not always as clear cut as it looks. Whatever is right for a given task depends on a number of factors including the engineer's experience. Someone's right tool maye be someone else's worst nightmare - for the exact same project.

author: IDEngineer
author_rank: Super Contributor
timestamp: May 06, 2020, 05:27:04 pm
content: Quote from: profdc9 on May 06, 2020, 04:26:01 pmOverloading is my most hated aspect of C++ (or any language that employs it). Honestly, it feels like it is intentionally designed to cause errors. Sure I get the theoretical convenience of it, but ultimately code has to be 1) written, 2) debugged, 3) tested, and 4) work in real life. Overloading "feels" like it helps with #1 but it makes #2 and #3 much less deterministic which risks the reliability of #4. That's a Faustian Bargain.The danger of overloading was proven to me most forcefully when I was debugging a function that was one of an overloaded family. As I stepped through the code, nothing made sense. Variables weren't changing the way they should, the debugger would skip lines of code when I single stepped, etc. I finally dropped into the disassembly listing and, looking at the program counter, realized thedebugger was displaying the wrong source code... it matched the name (of course) but was the wrong overloaded function! It's bad enough that overloading can fool a human, but when thenative debuggercan be tricked - nope, no thank you. Once again you're working too hard to accommodate your choice of tool. Tools (whether T&M equipment or software) are supposed to make the job easier, not get in the way.

author: nctnico
author_rank: Super Contributor
timestamp: May 06, 2020, 06:58:43 pm
content: Quote from: SiliconWizard on May 06, 2020, 05:02:01 pmWell, there is also something like the 'right person for the job' who can handle the right tool for the job. Personally I'm not a fan of doing OO in plain C. C++ makes life a lot easier by hiding all the nasty stuff which results in much easier to read code. The Linux kernel is a particular poor example of doing OO in C. It is a huge convoluted mess.

author: Wolfgang
author_rank: Super Contributor
timestamp: May 06, 2020, 07:11:37 pm
content: Its generally not smart to mingle OO and real time. Reason: OO resource management is somehow unpredictable and might add uncalculatable runtime when you cant afford it.No usable OS kernel I know is written in an OO language. Not even Windows

author: nctnico
author_rank: Super Contributor
timestamp: May 06, 2020, 07:25:32 pm
content: Quote from: Wolfgang on May 06, 2020, 07:11:37 pmBut that is more due to religion than due to common sense. Also a lot of OSses stem from before C++ was commonly used.If you look at the Linux kernel for example I'm 100% sure it will run faster when it is written in C++ because the compiler can optimise much more compared to regular C. For example: A regular C compiler can't inline functions which are pointed to by a function pointer. In C++ the compiler can do that if that function pointer never changes.

author: Wolfgang
author_rank: Super Contributor
timestamp: May 06, 2020, 07:32:31 pm
content: the const attribute is available in plain C too nowadays, IIRC.Its just a matter of safety; In C you can almost guess what assembly will come out of it. In OO code with overloaded functions,multiple inheritance, ... its hard to optimize, not very safe and transparent. I would not trust that in mission critical cores, IMHO.

author: Picuino
author_rank: Super Contributor
timestamp: May 06, 2020, 07:37:49 pm
content: I think the ideal is to combine the best of each world. C to make quick and efficient code libraries combined with a scripting language likePython, Lua or TCL to develop the application at a high level. Many software packages do so today.

author: nctnico
author_rank: Super Contributor
timestamp: May 06, 2020, 07:40:15 pm
content: Quote from: Wolfgang on May 06, 2020, 07:32:31 pmIt is only hard to optimise if an object is linked in runtime (runtime polymorfism for exampe) but other than that relations are 100% known during compile time.

author: bd139
author_rank: Super Contributor
timestamp: May 06, 2020, 08:14:57 pm
content: Quote from: Picuino on May 06, 2020, 07:37:49 pmSpot on. Exactly that.Also glad to see TCL mentioned in 2020

author: coppice
author_rank: Super Contributor
timestamp: May 06, 2020, 08:18:12 pm
content: Quote from: Picuino on May 06, 2020, 07:37:49 pmIts a long time since I saw anything but legacy code in TCL. It (or more specifically TCL/TK) used to be extremely popular for some pretty complex applications.

author: Picuino
author_rank: Super Contributor
timestamp: May 06, 2020, 08:27:34 pm
content: Tcl was just an example of scripting language. I know it from Tcl / Tk in Python.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 06, 2020, 08:29:18 pm
content: Quote from: nctnico on May 06, 2020, 06:58:43 pmIt works well enough and has been maintained for a long time, for something that is a huge convoluted mess. But code style is such a personal matter.Anyway. You'll use more basic OO approaches with plain C, but if done right, it structures things well, and contrary to C++ (which granted has a lot more features and sugar coating), it's still perfectly predictable, so it's often a benefit especially for embedded stuff.Now it may depend on what exactly YOU call OO.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 06, 2020, 08:43:45 pm
content: I'm kinda surprised in an engineering forum nobody is talking about C#. For general engineering stuff like simulations and setting up UI's and graphs and data acquisition stuff it is, for me at least, incredibly fast and efficient to get stuff up and running. Just drag-n-drop some UI components (windows, buttons, graphs, etc.), grab a free math library like MathNet, write your code and you're all set. And personally, like I say, if you're simulating real world equipment the OO design makes things so intuitive.Is it because many folks here are more involved with hardware/embedded systems?And also no mention of the ever popular graphics/gaming stuff that pretty much relies on C++ for the API's (DirectX, OpenGL, etc.). I've been doing raytracing stuff in OpenGL/C++ and it seems like most of the docs and sample code and tutorials are geared toward C++.

author: Wolfgang
author_rank: Super Contributor
timestamp: May 06, 2020, 08:52:16 pm
content: IMHO, the reason for the preference of Python is because:- cross-platform- much more scientific/engineering libs than other languages- free, and open source.Hard to beat, I would say. When you look at TIOBE what is happening to MATLAB at the moment that tells something.Python is on the way to a firm number one in scientific computing, also for AI, ...

author: radioactive
author_rank: Regular Contributor
timestamp: May 06, 2020, 08:55:37 pm
content: QuoteI feel as though you are referring to Python here. Either that, or possibly my personal nightmares. I guess the former makes more sense.

author: nctnico
author_rank: Super Contributor
timestamp: May 06, 2020, 08:59:55 pm
content: Quote from: SiliconWizard on May 06, 2020, 08:29:18 pmI don't know your knowledge level with the Linux kernel but I'm intimately familiar with it. Making meaningful modifications to it has a steep learning curve and there is a of lot stuff loosely coupled using void pointers. From a C point of view defendable but from a coding perspective it doesn't help.

author: nctnico
author_rank: Super Contributor
timestamp: May 06, 2020, 09:03:29 pm
content: Quote from: engrguy42 on May 06, 2020, 08:43:45 pmC# is MS only. People seem to use Python for that kind of applications nowadays. Personally I don't know anyone who is writing software using C#.

author: Wolfgang
author_rank: Super Contributor
timestamp: May 06, 2020, 09:08:24 pm
content: Quote from: nctnico on May 06, 2020, 08:59:55 pmmy Linux kernel area is years gone. The problem is rather that it has never been *really* cleaned up and rewritten. Its like all successful software: it can be incrementally improved until it finally breaks down. 20 years leave their trace in any kind of software.The problem we had that we wrote software that our customers did not want to renovate after 20 years or more. None of our developers was keen to work inside the code, even it was very clean (in the beginning). Same with Linux or any other "old" OS.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 06, 2020, 09:08:40 pm
content: Quote from: Wolfgang on May 06, 2020, 08:52:16 pmHey, wait a minute...what's happening to MATLAB???Am I gonna have to learn Python??

author: IanB
author_rank: Super Contributor
timestamp: May 06, 2020, 09:10:32 pm
content: Quote from: nctnico on May 06, 2020, 09:03:29 pmC# is gaining cross-platform support and much of it is now open.As for writing software in C# -- over here! ::waves hand::

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 06, 2020, 09:10:51 pm
content: Quote from: nctnico on May 06, 2020, 09:03:29 pmNo offense, but one guy not knowing a C# user doesn't say much. I just checked and it's said there are over 6 million users.Maybe you need to get out more

author: bd139
author_rank: Super Contributor
timestamp: May 06, 2020, 09:11:02 pm
content: Quote from: engrguy42 on May 06, 2020, 08:43:45 pmI have written a fair bit of C# over the years. In fact there are a few programs attached to my posts on here. You're right for rapid development purposes it's good. It also scales really well vertically and across teams. The main products I worked on over the last 15 years or so were C#.But that's where the love ends I'm afraid. The language is fine but the mismanagement by microsoft of all the frameworks over the years has put a hell of a lot of us off. On top of that we have the shit show which is .Net Core that appeared on the scene. Really the issue stems from the closed nature of the ecosystem initially where you'd get pulled through microsoft "patterns and practices" which gave you terrible architectural advice and frameworks and then left you high and dry when their direction changed. Then along came the SOA era where they kicked out stuff like WCF, WWF and AppFabric. Within 3 years they pulled most of that and migrated to the whole Web API ecosystem, abandoning swathes of enterprise customers. Then there was the Silverlight debacle and the Windows Phone "throw everything away and start again" transition between WP7 and WP8. People were starting to get pissed. Then the Compact Framework and Windows Embedded were abandoned which left hoardes of mid-tier enterprises up shit creek. As if that wasn't enough of a kick in the teeth, about that time the ecosystem license costs got cranked up and other platforms started getting a lot of interest. Their result was to recycle the original Rotor CLR as .Net core and make it cross platform, an easy enough job apart from all the shitty bits of cruft that were win32 specific. Some effort was made at compatibility (.Net standard) but it means a rewrite for a lot of people. Even large components like NHibernate have non-portable forward changes. In the background all the open source projects were being abandoned out of disinterest because the ecosystem is relatively small compared to others. Literally by the time everyone had ported to .Net Core 2.0, the world was on .Net core 3.1 and there was more heavy lifting and cost to throw at the problem. At the same time there was massive API consolidation and growth leading to a simpleish console application with logging pulling in a metric shit ton of dependencies. The last desperate breath is "we're going to get it right with .Net 5 and oh by the way can you bend over some more because your legacy SQL cluster is going to be buggered for a cool £1 million this year". Deep breath and look at the universe...The C guys are raising one eyebrow because nothing changed in the last 15 years.The Go guys are raising one eyebrow because the last major version upgrades they did in the last 10 years were trivial and automated.The Python guys waited until all their libraries were ported, ran 2to3 and carried on in the last 10 years.The postgres guys are sitting there laughing at this.Everyone in the .Net ecosystem saw the guys above and said they want some of that. All the remains is a few scarred corpses like myself propping up what is left and whining on github and being silenced every time we even try and deal with MSFT who are really shitting out the marketing hard and shutting down negative sentiment and anything which questions their totalitarian control of the "open source" projects they run. Which is why C# is dying on it's arse at the moment. Even the company I work for which is a stallwart MS partner for many years is a Linux shop now. The legacy shit runs on .Net Core. The new stuff is going out in python and Go on Linux on AWS. It's dying. Run away quick.Microsoft's development ecosystem is shiny as fuck but it's not something I would consider building a business on at this time. It's expanding out of desparation, nothing more. What exists past trivial stuff is a money sink.

author: radioactive
author_rank: Regular Contributor
timestamp: May 06, 2020, 09:12:49 pm
content: Quote from: engrguy42 on May 06, 2020, 09:08:40 pmNo, it is just another C library that someone created bindings to in Python. Don't worry.

author: Wolfgang
author_rank: Super Contributor
timestamp: May 06, 2020, 09:30:24 pm
content: Quote from: engrguy42 on May 06, 2020, 09:08:40 pmyeah, maybe not the worst idea. The point is that in Python most of engineering and math you need works similarly or sometimes even better than MATLAB, and Python is free. MATLAB not at all.TIOBE shows that MATLAB use is declining steeply, Python is growing at record speed.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 06, 2020, 09:41:24 pm
content: Quote from: Wolfgang on May 06, 2020, 09:30:24 pmOh really? MATLAB declining? Maybe because every time you need to do something you learn "oh, that's in this OTHER set of tools, and it will cost you another $50".But the good thing is they have some pretty nice pre-made models you can start with. Well, as long as you buy that OTHER set of Simulink/Simscape/whatever tools and spend another freakin' $250.Damn. I guess "learn Python" goes on my to-do list....Oh, BTW, does Visual Studio do Python? I love Visual Studio.

author: Picuino
author_rank: Super Contributor
timestamp: May 06, 2020, 09:46:56 pm
content: https://code.visualstudio.com/docs/languages/pythonYou should know Python at least as a complement to Matlab. Learning curve is very easy and fun.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 06, 2020, 09:53:03 pm
content: Quote from: Picuino on May 06, 2020, 09:46:56 pmOh wait, VS tells me I already have Python installed.But the downside is my tons of code and libraries I've already made in C# & C++ won't work anymoreIs there a magic converter thingy?

author: bd139
author_rank: Super Contributor
timestamp: May 06, 2020, 09:58:57 pm
content: Check pypi first. Most of the shit I've written over the years someone else has already put together something better for.

author: radioactive
author_rank: Regular Contributor
timestamp: May 06, 2020, 10:03:12 pm
content: Quote from: engrguy42 on May 06, 2020, 09:41:24 pmI feel your pain. I spent more than that on some "home" version to learn the *real* matlab instead of octave. I thought it might give me some insight when I was first learning FPGA after putting it off for decades. After downloading and playing around with it, I realized that not only could I *not* do anything FPGA related with it, but the only thing it was slightly better at (at the time) was creating coefficients for FIR filters. I wrote my own code for that since then. Last time I tried to run Matlab (that I paid $500 or so for from memory), it segfaulted. I think the Octave project is the future of Matlab from what I can tell. Also, Python uses lib-octave libraries from what I can tell (not that interesting to me). I really can't stand even looking at Python code. Maybe there is also some kind of commercial effort from the Matlab guys? Not sure about that.related sidenote: Also learned VHDL and Verilog since then. Both well worth learning. I came away from it preferring Verilog by far.

author: Wolfgang
author_rank: Super Contributor
timestamp: May 06, 2020, 10:06:12 pm
content: Quote from: engrguy42 on May 06, 2020, 09:41:24 pmPython in VS? Not that I know. And I agree, VS as a development environemnt is a lot classier than IDLE.But with MS you never know. When they see that Python is making it - they will incorporate it in VS. MS has becomecompletely pragmatic now about platforms and languages.And for the MATLAB added price list strategy - Yes, its a nuisance, and it drives people away. Its not free, its not open,and many times the Python scientific stuff is even more advanced, and you can adapt and expand it.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 06, 2020, 10:09:46 pm
content: Wow...Now I can be with the cool guysSounds like NumPy is good for math stuff like arrays and complex numbers?

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 06, 2020, 10:15:52 pm
content: My first python program. I just guessed and it worked

author: Picuino
author_rank: Super Contributor
timestamp: May 06, 2020, 10:38:30 pm
content: Be careful, Python is a language that you fall in love with.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 06, 2020, 10:41:57 pm
content: Does it do the drag-n-drop UI stuff in VS? Windows and buttons and stuff?

author: Picuino
author_rank: Super Contributor
timestamp: May 06, 2020, 10:51:50 pm
content: Learn about PyQt 5 and Qt Designer

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 06, 2020, 10:53:49 pm
content: OOoooooo...Yummy sine wave

author: radioactive
author_rank: Regular Contributor
timestamp: May 06, 2020, 10:55:56 pm
content: Just thought of a question that might be relevant and interesting to this thread. What languages can you think of that don't rely on any other languages to be useful? I think this may just be the question to ask. Why C? C is the language of the people who create stuff with software these days. Early on it used to be that assembler was the way to go. Since then, 'C' has been the default for a good reason. It is where you start if you want to create something efficient, new, experimental. Sure, maybe something will replace it eventually. I just can't see anything that looks better from my perspective in the here and now for embedded software development, OS development, and alternate language development. Scripting languages are fads that come and go in my opinion. Some are better than others.

author: emece67
author_rank: Frequent Contributor
timestamp: May 06, 2020, 11:41:16 pm
content: .

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 07, 2020, 12:26:44 am
content: ARRRRGGGGHHHH....I've installed every freakin' PyQt5 related package I can find, including PyQt5Designer into Visual Studio, and for the life of me I can't figure out how to run Designer. There's a new tab in VS called "Qt VS Tools", and has an item "Launch Qt Designer", but when I select it it says "No default Qt version found", and wants me to fix my Tools settings. But I can't find any "Qt" anything on my machine. But in the Python Environments it shows PyQt5Designer (5.14.1) as an installed package, along with a ton of other packages.This is what I hate about this stuff. There's so many freakin' versions of stuff that you can't find any tutorials or videos on this stuff. Oh, this one's for C++. And this one's not for VS. And NONE of them are for Qt Designer.That's one thing I like about VS and C#/C++, it's all native stuff that works. Here you have to go futzing around with Qt whatever.EDIT:Oh wait, I searched and found pyqt5designer.exe in ProgramFiles(x86)/Microsoft Visual Studio/Shared/Python36_64/ScriptsWTF???

author: maginnovision
author_rank: Super Contributor
timestamp: May 07, 2020, 05:38:50 am
content: For C++ gui stuff I usually run fltk and opengl. Typically good cross platform code even though you need to manually scale for dpi. I really don't want my code attached to a library and it's difficult to disconnect running QT.

author: nfmax
author_rank: Super Contributor
timestamp: May 07, 2020, 07:44:34 am
content: Quote from: dmills on May 04, 2020, 09:47:18 amC++ is a language that tries to do too much, and succeeds

author: bd139
author_rank: Super Contributor
timestamp: May 07, 2020, 07:54:04 am
content: Only because there’s a language feature and chapter on redefining success in Stroustrop’s book.

author: 0db
author_rank: Frequent Contributor
timestamp: May 07, 2020, 08:19:34 am
content: Quote from: nctnico on May 06, 2020, 06:58:43 pmAgree, and it's also context-dependent.

author: 0db
author_rank: Frequent Contributor
timestamp: May 07, 2020, 08:24:18 am
content: Quote from: maginnovision on May 07, 2020, 05:38:50 amEven deep machine Learning is usually C++ stuff. A good choice, in both cases.

author: ace1903
author_rank: Regular Contributor
timestamp: May 07, 2020, 10:14:31 am
content: Maybe a clarification is needed.I do program in C for monthly salary all day long.When I need to do some data processing, to interpret measurement results, test algorithm for signal processing I do use MATLAB, Python, Qt and C++.Rarely Perl, TCL/TK, Java, Assembler ...Somehow whole thread went in a direction to show how one can do something with few lines of code.That is not coding, it is fun.How many of you earn a salary by coding in Python(except web development), Matlab ,Octave...?How many of you worked on code in Matlab Python larger than 1000 lines and potentially saleable?

author: Berni
author_rank: Super Contributor
timestamp: May 07, 2020, 10:56:27 am
content: Both C++ and Python are great languages but with entirely different purposes.Id say people that earn a living programing in Python mostly use it as a way to process data or create quick small tools to get there actual job done. You wouldn't create a python application and sell it as PC software. Its a slow clumsy language that is not suited for large projects at all. But for when you want to write an app for example "takes in a folder full of images, rescales them and adds text in the corner according to data from a database" then you will have your app working from scratch in half an hour with Python. Its designed to let you do whatever you want without being a language nazzi and yelling at you "You can't put a string in there, this is a int array" it always tries to do whatever you tell it to do. As a result there is a lot of dirty tricks and bad programing habits in it, and big projects like to become a mess. Yet damn is it quick to throw something together in Python.For developing GUI PC apps id recommend C#. It just works from VisualStudio and the language has a lot of object oriented creature comforts while maintaining very high performance. Lots of commercial apps are written using it.Regular C on PCs tho...no, just don't. There are so many better languages now. The C language is mostly a way more readable and useful version of assembler. Its fast and lets you do low level things. So its great for running on MCUs where you might only have a few KB of RAM, or when writing Windows/Linux drivers where you need the low level capabilities. Game engines still use quite a bit of C++ tho, since it can squeeze last remaining bits of performance out of a CPU when a good programmer does it.

author: coppice
author_rank: Super Contributor
timestamp: May 07, 2020, 11:01:33 am
content: Quote from: IanB on May 06, 2020, 09:10:32 pmIs it really? Mono has been around for years, but if it is seeing significant use it must be in places I never see.

author: bd139
author_rank: Super Contributor
timestamp: May 07, 2020, 11:04:25 am
content: Microsoft is telling everyone it is growing constantly and rolling out the marketing hard. It's shrinking almost everywhere in reality.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 07, 2020, 11:06:27 am
content: At this point I tend to agree with Berni. You start up VS, start a C# app, the toolbox with all the GUI stuff appears, you drag-n-drop, and you're off. The code is automatically generated, as are the event handlers.Trying to shoehorn Python/Qt/Qt Designer into VS is looking like a pain, especially when GUI's are involved. Apparently you need to run QtDesigner separately to generate the .ui file, then use command line crap to convert to .py, and merge your code into that.For those who have gone thru the hassle and it's become second nature, then yeah, it's easy. For those who have no interest in going thru the hassle, it's a freakin' pain. And at the end of the day, is there really much benefit over C#? Or is it just because it's popular? I couldn't care less what others are using, and whether it's "popular".From what I've seen so far it's a "loose" version of C#.In any case, does anyone know of a tutorial on setting up PyQt5 and QtDesigner, for Python, in Visual Studio, that's more recent than 6 years ago?

author: Berni
author_rank: Super Contributor
timestamp: May 07, 2020, 11:10:52 am
content: Quote from: coppice on May 07, 2020, 11:01:33 amWell alone the game Fortnight generated about 2 billion USD of profit in 2019 and is running on the UnrealEngine where most of the actual game code is C# running in Mono for multiplatform. And this is just one example. Lots of games are made with UnrealEngine or Unity and both use Mono to run C# code on Windows, Linux, Mac, Android, iPhone...Id say that is a pretty damn big use of Mono.

author: Kosmic
author_rank: Super Contributor
timestamp: May 07, 2020, 12:46:57 pm
content: Quote from: Berni on May 07, 2020, 11:10:52 amFYI this is not true. UnrealEngine 4 is mostly C++ (100% of the runtime engine and a good chuck of the tools). Nobody remotely serious use C# and mono in a video game.If you don't believe me just d/l the source code of UE4...

author: Berni
author_rank: Super Contributor
timestamp: May 07, 2020, 01:16:16 pm
content: Quote from: Kosmic on May 07, 2020, 12:46:57 pmWell yes the engines themselves are are written in C++, but C# is one of the popular languages that is ran on top for actual game code. Okay yes UnrealEngine does favor C++ for game code too, but you can use any language that can compile itself into a dynamic library. Unity is just as big of a player in the game engine scene and it heavily pushes C# due to tightly it is integrated with it (So yes large parts of Unity are also written in C# to facilitate that, but the core parts of the engine are not).These non compiled languages are attractive for the reason that they run on any platform out of the box and they offer a lot of rich debugging functionality regardless of platform. A lot of the time these modern game engines even allow for modification of code as its running live (even when running on a remote system like an Xbox or PS4). So it makes sense to use things like C# for game code in order to speed up development. Later on this also becomes usefull for any moding API pr plugins as they can tap into the code on a high level rather than essentially acting like a virus to tap into functions and memory.Yes you would not write an entire game in C#, but quite a lot games released in the last 10 years are running the high level game logic inside Mono due to the benefits that JIT compiled languages offer.

author: Kosmic
author_rank: Super Contributor
timestamp: May 07, 2020, 01:31:45 pm
content: Quote from: Berni on May 07, 2020, 01:16:16 pmSo for UE4, again no this is not true. A C# .dll is really different than a C++ .dll. You can't really plug a c# .dll in a c++ application (the reverse is possible though). You need a CLR to run c# code. UE4 do not contain a CLR and run exclusively C++ code.Also about .dll, on consoles (xbox, playstation) .dll are possible but are still not immensely popular. A huge monolithic executable is still preferred by the 1st party (Microsoft and Sony).Quote from: Berni on May 07, 2020, 01:16:16 pmThis is also not true. C# is a compiled language and it's not interpreted like python. Like Java it's compiled to an intermediary language that most of the time really look like x86 assembly. The IL then run in a runtime environment adapted to the targeted platform. So the idea is that your business code in IL stay agnostic of the platform.Quote from: Berni on May 07, 2020, 01:16:16 pmLike I said Mono and even Microsoft CLR are far too slow to run a game. Even in Unity, which use C#, they created a C# IL code converter (IL2CPP) to be able to convert your C# code in C++. The C++ code is then compiled natively to suit the targeted platform. I think the only exception is Windows PC where some game are kept C# over Mono or MS CLR. All other platforms (Phones, Xbox, Playstation) run native code.Overall C# in a game is a really bad idea. The trend right now is to create a Visual Scripting language like Blueprint in UE4. The Visual Scripting language run on top of C++ and performance can be managed.

author: Berni
author_rank: Super Contributor
timestamp: May 07, 2020, 04:16:31 pm
content: Yes i know there are differences between a machine code DLL and a CLR DLL. But UE4 will handle it with a simple plugin.And yes C# is indeed not interpreted directly like Python. Its crunched into the .Net IL and this is then JIT compiled to platform specific machine code on the fly. This is the reason why C# is actually really fast, it only needs to be compiled once, then the code is essentially machine code. Sure it might not be the C level of performance, but its not that far behind. Hence why it does end up used in games so often. Most of the complex gameplay related game code is not being executed all the time so it does not matter if the code runs half as fast as it could in C++, it won't run often enough to visibly degrade performance, yet the creature comforts of the C# language make its development and troubleshooting significantly faster (this game logic is often a lot more complex in terms of many more variations in behavior, more variables etc). Games are huge and have long load times so recompiling a game for each test run is not desirable. For this reason a lot of games in the last 30 years have some sort of non precompiled language inside it(Lua used to be popular for this), it makes game development easier, since the non programmer person plonking down game NPCs can just quickly edit a file in notepad while the game is running. The only difference with C# is that its the first such popular language that is performant enough to be used for a lot more than just simple NPC behavior scripts that run once every few seconds. Go have a look at some C++ vs C# benchmarks and see how close to C++ performance it actually is.I have looked at my Steam install directory and out of the 40 games installed 19 of those games had a folder named "mono" full of windows mono dll files. So it is safe to say a significant part of games make use of of it. Tho by now core.Net is replacing mono by doing the same job.Still yes you would not write the entire game engine in C#. You do want all the performance you can get out of the low level loading and rendering functions, you want native calling of other native DLLs etc. But for high level game logic the small performance penalty is really not a big deal as its so small that the other benefits make up for it. Besides the big AAA publishers that do make there own C++ engines end up slapping ever larger DRM methods (decrypting the machine code as its running) and this results in very significant drops in performance of 10 to 50% in tests (People got there hands on a DRM free version of the same game to compare the DRM impact)My point is that non C++ languages are used a lot in game development because they have advantages that outweigh the performance cost. They are still not a replacement for C++. But for the usual one man band engineer writing software to run on a PC with GUI the whole C++ thing is usually not a good fit. The slight performance gain is not justified by the extra time, effort and expertise required. If raw performance was the main metric then everyone would still be doing assembler.

author: Kosmic
author_rank: Super Contributor
timestamp: May 07, 2020, 04:56:07 pm
content: Quote from: Berni on May 07, 2020, 04:16:31 pmWell it's not because you can hack a CLR inside UE4 via their plugin system that's it's a good idea. It's clearly not officially supported. To go back the game you were talking about, Fortnight , I can guarantee that you will find 0 line of C# in there.Quote from: Berni on May 07, 2020, 04:16:31 pmI'm well aware of the difference between C++ and C# and even if C# is better than Python, it's a lot worst than C++. Also, speed is not the only problem with C#, memory management and the garbage collector is a huge pain. Almost impossible to solve. Integrating scripting language in professional game engine was done mostly between 2000 and 2010. Like I said before, these days visual scripting is a lot more popular and is normally powered by C++ like the rest of the code.Quote from: Berni on May 07, 2020, 04:16:31 pmSmall indie games made with Unity or with some other small game engine ship on PC with mono yes. Never the case for AAA games.Quote from: Berni on May 07, 2020, 04:16:31 pmI don't have a lot of visibility on the indie/small game scene, but on the AAA space those languages are not used anymore for multiple years now. Everybody moved to visual scripting and the rest of the engine and code is C++.Small developers working on small games do what they can and it doesn't mean it's a good idea. For exemple, integrating C# in UE4 for me is an aberration. You should use the engine the way it was designed and put your logic in the visual scripting language (blueprint) and not C#.

author: Kosmic
author_rank: Super Contributor
timestamp: May 07, 2020, 05:06:37 pm
content: Another bit of information, C# performance are so dreadful that Unity started working on their own compiler (called Burst) where they compile C# code directly to platform assembly code, skipping the CLR entirely. Only problem is to do so, they had to cut the 3/4 of the language featureslike IL2CPP, their own custom C# compiler is probably not a good idea. Personally I think that for games, C# should be avoided.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 07, 2020, 05:07:23 pm
content: Why is there always a battle to prove who's "right", when there's no "right" answer??All languages have pros and cons. There is no perfect language. Coming up with these somewhat irrelevant pseudo facts doesn't prove anything. Yeah, some users somewhere might not like a feature/characteristic, but others elsewhere couldn't care less.There's always this ridiculous battle to prove who's right.Just accept it guys. All languages have pros and cons. Just because YOU might not like some aspect of a language doesn't make that relevant to the rest of the world.BTW, replace the word "language" in what I just posted with any technical thing: meters, scopes, power supplies, etc., and you've pretty much defined many of the discussions here

author: Kosmic
author_rank: Super Contributor
timestamp: May 07, 2020, 05:10:38 pm
content: Not a matter of right or wrong, I'm stating some facts and communicating my humble opinion.It's probably not clear but I love working in C#. It's the language I use for my personal projects. It's just not a good idea to use it for everything.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 07, 2020, 06:08:32 pm
content: Quote from: Berni on May 07, 2020, 04:16:31 pmI always find this kind of reasoning a bit exxagerated - there's a whole world between an high-level, running on a VM language, and assembly.Raw performance may or may not be your main metric depending on the project, but even if it's not, you still have a handful of reasonable solutions to choose from.And that said, for the fun fact, some people are still writing complex stuff in assembly:http://menuetos.net/Not saying this makes a lot of sense, but it's fun.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 07, 2020, 06:52:59 pm
content: For what it's worth, for those who might be considering trying Python...And this is for those who are like me:- Using Windows (not Linux or Mac)- Using Visual Studio 2017 (NOT Code), and not interested in picking up a different IDE- Want to make some GUI-based apps, and are used to the ease of natively drag-n-dropping GUI elements in C#- Are familiar with C++ and C# in VS, and have a lot of pre-made code you've already developedNow I'm sure for those who like and have used Python it's wonderful. However, I've spent a day and a half trying to get everything working. I watched a 4+ hour tutorial on Python. I've downloaded and installed every freakin' Python/QT - related thing I can find. I've searched and searched youtube and other websites for tutorials on how to set it all up. And I've learned about PIP and all the libraries you can install.But at the end of the day, I've pretty much given up. From what I've seen, it's pretty much a much less stringent version of C#. It has classes (which I love), pretty much the same basic functionality as any programming language. But for me, the cost outweighs the benefit. And I'm still not clear what the benefit actually is.I can't even figure how to run the GUI-making software (QtDesigner) from within VS. There's no tutorials. They're either addressing Qt and C++, or VS Code, or some other IDE, or some old versions, or Mac, or Linux, or some other Python version thingy (Anaconda, etc, whatever the F they are). And it seems all you're doing is running a separate app that makes some UI code that you have to convert to python code via command line. And it's a freakin' science project to understand and find where stuff is located on your drive. And it seems there's also other options for GUI stuff. Which means a more extensive science project trying to figure out what to use and how to use it.The best resource I found was docs.microsoft.com/visual studio/python or whatever for basic VS/Python, but still it doesn't answer everything. Or anything about Qt. And for that you need to go to the Qt website.And the Python implementation in VS is different. But not in a good way. For example, I spent 1/2 an hour just trying to duplicate what is a simple procedure in VS C#/C++: select and comment a bunch of lines. I still have no clue. The devil is certainly in the annoying details.Now I'm sure there are fixes for much or all of this, and I'm sure I'll hear an unending stream of them. And I'm sure some of them involve jumping thru a bunch of annoying hoops. But for me it just isn't worth the hassle.Anyway, I may decide to pick it up again, but for now I'll just let it sit until I find some real benefit to having Python. I tried.

author: Berni
author_rank: Super Contributor
timestamp: May 07, 2020, 07:04:00 pm
content: Yeah i do admit that small game studios tend to go this route while big AAA developers tend to build there own engines from the ground up. The smaller studios have limited resources so less people needed to code the game the better. Big studios already have >200 artists working on 3d modes, textures, animations, maps..., so who cares if 50 programmers are needed to put together an engine.But i don't really see the performance gap from C# to C++ being all that big. But i do have to admit that one has to be a lot more careful with programing in C# to actually get that performance. There are some small sneaky details that can cause a piece of code to suddenly run much slower or generate a pile of junk for the garbage collector. Its just a matter of using the profiling tools to identify these choking points and fix them.A good example of C# in a game is Cities Skylines (Widely regarded as the worlds best city builder game for the last 5 years, having stolen this crown from SimCity). Its still done by a small developer ~20 people but it did sell a lot of copies. Made in Unity with C#, it is simulating 10s of thousands of people individually walking and pathfinding around the city during gameplay while obeying traffic rules (Every single pedestrian,car,train,plane,boat), also simulating water flow over terain and wind constantly. Featuring a official modding api that links in preparsed C# code on the fly without a restart. All of this running nicely performant on a typical PC and will properly utilize larger numbers of CPU cores (if needed for unusually large cities). Its a particularly good example of very computationally intensive game logic being ran in .net.Not saying that C# is perfect, but there is a time and place for it. Same for C++. I love C/C++ for running bare metal on MCUs, there are many cases when you would want to use C++ on a PC. But just like C#, its not for everything. Still C# is a very good alternative to other similar languages that offer similar features like Java(ie Android apps) while not being a replacement of any kind for what C++ does well. Most of the popular languages exist for a good reason.

author: nctnico
author_rank: Super Contributor
timestamp: May 07, 2020, 07:12:22 pm
content: Quote from: engrguy42 on May 07, 2020, 06:52:59 pmYour problem seems to be being stuck to VS (which is not the best tool to work on code; it is pretty clumsy).When I need to work on a VS project I load the same project in Eclipse CDT and use VS only to compile.

author: Picuino
author_rank: Super Contributor
timestamp: May 07, 2020, 07:14:56 pm
content: Quote from: engrguy42 on May 07, 2020, 06:52:59 pmGUIs can be made with Python but that is not its strong point.You can use Python for tasks closer to the command line.For example I use Python to render my static web page with the sphinx tool.It has also served me occasionally to summarize large amounts of data in text format.In fact, it is how I met Python, in a start-up in which hundreds of thousands of messages had to be summarized daily from an entire installation with more than 1000 PLCs. The guys who taught me Python managed to quickly summarize them in a simple excel sheet.From there I used Python to do a software bug search program in PLC programs.All of these tasks are alike in that they handle large amounts of text and data flexibly and easily. That is the biggest Python niche.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 07, 2020, 07:28:34 pm
content: Quote from: Picuino on May 07, 2020, 07:14:56 pmAh, okay, thanks. For me I guess that comes down to balancing Matlab vs. Python, since I tend to run to Matlab for data acquisition and analysis and simulation stuff on large amounts of data.BTW, what is this "command line" to which you refer?I didn't know that's still a thingI'm kinda allergic to command lines.

author: Picuino
author_rank: Super Contributor
timestamp: May 07, 2020, 07:38:17 pm
content: I usually use Python as scripts from the command line together with the make tool.For example a small utility that I sometimes use is a small script that automatically generates header files from c files. It collects all the definitions of the functions and with them generates a header. It is not very flexible, but it saves me work.Another small Python macro from the command line allowed me to generate KiCad library files for integrated circuits (they are written in plain text).Those are examples of another way to use Python. Once you know Python, you can think of many ways to apply it to small daily tasks.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 07, 2020, 07:44:03 pm
content: Quote from: nctnico on May 07, 2020, 07:12:22 pmFunny, I was recently watching a video of a guy who teaches C++, and he's been working for years with one of the biggest game companies (Electronic Arts) and he writes game engines for them. And it sounds like he and his company use only Visual Studio.

author: Siwastaja
author_rank: Super Contributor
timestamp: May 07, 2020, 08:12:39 pm
content: engrguy42, you fail to see the point of Python.Python is like Arduino.In Arduino, you solve a commonplace electronic problem by buying a completely engineered finished product - called a "shield", which comes with a complete software, and just write a few lines of codes to instantiate, orconfigureit. thing.run(); Works great, whenever such already finished product exists. Strong point: you can quicklycombinethings, use them like building blocks, and the configuration isn't fully fixed, you can make small adjustments on it. And it stilllookslike it's made by you.Same is true for Python. You need to solve somecommonsoftware problem, which has been already solved. You load up a Python library: the problem is solved in C, by the library writer. Youinstantiateit, write your input data. Strong point: you can easily combine such blocks, to solve larger problems. But just like with Arduino, you are pretty much limited to existing algorithms. Everything is so easy as long as you do series of one-liners to process data. When you start actually looping through data and do your own things from-scratch, not only the performance totally sucks, you may realize the language itself is lacking for such work after all.This explains the very strange claims you hear, like "Python is the language of AI algorithms, so it is very powerful", while in reality all that this means is that Python is used toloadup a complete AI program (which is likely written in C, plus things like OpenCL and similar to utilize GPUs), and just to define the configuration and data structures. For this, the syntax of Python is quite handy. And for such simple use, youdon'twant strong typing.I have found zero use for Arduino, and similarly, I have found absolutely no use for Python. But, I mostly do system-level or embedded work.Please take this comment as a humble opinion, not a scientifically sound exact fact.

author: nctnico
author_rank: Super Contributor
timestamp: May 07, 2020, 08:13:35 pm
content: Quote from: engrguy42 on May 07, 2020, 07:44:03 pmThat doesn't mean it is a good idea. But if you don't know any better then every screw looks like a nail. Last year I had to make some modifications to the Unreal engine and VS was just not up to the job to take on such a large project and work at a comfortable speed (on a machine with 18GB of memory!). Eclipse to the rescue!

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 07, 2020, 08:19:26 pm
content: Quote from: Siwastaja on May 07, 2020, 08:12:39 pmSiwastaja, thanks. It sounds like what you're describing is, like I say, quite a bit like what Matlab does. Lots of premade scientific/engineering/AI/math functionality that you just grab and go.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 07, 2020, 08:22:01 pm
content: Quote from: nctnico on May 07, 2020, 08:13:35 pmNo, I'm sure you're right. You just might want to warn EA that Visual Studio isn't up to the task. They have lots of $$$ riding on it.

author: JPortici
author_rank: Super Contributor
timestamp: May 07, 2020, 08:23:40 pm
content: Quote from: engrguy42 on May 07, 2020, 11:06:27 amsome months ago i decided to really start with Qt (also because i was planning to do a project using a beaglebone and there weren't many alternatives for UI)it took me a full work day, with both some tutorial websites and more importantly the examples on the BBB book by derek molloy and i finally cracked it!Now almost all my applications have custom widget i generate on the IDE. layout is done mostly in code, and the event system is way more flexible to me and the drawing performance is much better.The only thing i miss from Visual C# is the grid system (and sometimes to know how a QT widget will expand require a sacrifice of a certain amount of goats)but everything else is a burden

author: Kosmic
author_rank: Super Contributor
timestamp: May 07, 2020, 08:56:36 pm
content: Quote from: engrguy42 on May 07, 2020, 07:44:03 pmI can confirm (I worked for EA, Bioware, Ubisoft ... ), Most AAA company use Visual Studio in conjunction with, most of the time, Visual Assist. When you have project with more than 10000 files, the only IDE surviving is VS.

author: bd139
author_rank: Super Contributor
timestamp: May 07, 2020, 08:59:18 pm
content: 10k files in VS is a pain in the fucking arse. We're at 30k on one project and it barely works. We have guys using vim and command line tools because it shits the bed (as it's still a damn 32-bit process)As for the debugger. Yeah try opening a 30gb minidump, if windows will even create one without barfing. Oh and then there's the 20 minute wait for it to cache all the sodding symbols so you can get a stack trace from a thread.There must be a better way. I think a lot of VS users suffer stockholm syndrome.

author: Kosmic
author_rank: Super Contributor
timestamp: May 07, 2020, 09:06:10 pm
content: Quote from: bd139 on May 07, 2020, 08:59:18 pmC# or C/C++ ? for our tools coded in C# someone had the great idea to put everything (all the tools) in the same solution. It just kill the IDE. I think it's doing a lot less in C++ because it was never a problem even if the file count is higher.Quote from: bd139 on May 07, 2020, 08:59:18 pm30gb well yeah it's a lot never seen that.

author: Kosmic
author_rank: Super Contributor
timestamp: May 07, 2020, 09:10:47 pm
content: Quote from: nctnico on May 07, 2020, 08:13:35 pmSomething was definitely wrong there. Used Unreal and Visual Studio for years and it works perfectly.Edit: intellisense was probably running in background. Normally when I set up my workstation it's the first thing I disableIt's the reason why we use Visual Assist most of the time.

author: IanB
author_rank: Super Contributor
timestamp: May 07, 2020, 09:12:57 pm
content: Quote from: engrguy42 on May 07, 2020, 06:52:59 pmI just tried it and Ctrl-K, Ctrl-C works for me. Ctrl-K, Ctrl-U to uncomment.

author: IanB
author_rank: Super Contributor
timestamp: May 07, 2020, 09:15:07 pm
content: Quote from: bd139 on May 07, 2020, 08:59:18 pmI think that is not a "mini-dump", it is a "maxi-dump"

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 07, 2020, 09:16:09 pm
content: Quote from: IanB on May 07, 2020, 09:12:57 pmHey, you're right !!! How come you never told me??I was trying to set up a menu item to do comments. Never tried the shortcuts

author: Kosmic
author_rank: Super Contributor
timestamp: May 07, 2020, 09:25:00 pm
content: Quote from: bd139 on May 07, 2020, 08:59:18 pmJust double checked our project and just the C++ code is around 53K files. It's more than I thought.

author: nctnico
author_rank: Super Contributor
timestamp: May 07, 2020, 09:27:25 pm
content: Quote from: Kosmic on May 07, 2020, 09:10:47 pmProbably but Eclipse CDT can do the things Intellisense does with the Unreal engine codebase just fine (after setting the memory limits higher) without needing an extra plugin. 'Whole tomato' which makes 'Visual Assist' does ring a bell from the time I used VS almost daily at one my previous employers.

author: bd139
author_rank: Super Contributor
timestamp: May 07, 2020, 09:28:09 pm
content: Quote from: Kosmic on May 07, 2020, 09:06:10 pmWas C#. Look down...Quote from: IanB on May 07, 2020, 09:15:07 pmIt is a minidump based on the host machine...Two socket machine. Maxxed out. NOT a hypervisorMost people don't get to wrestle shit like this. I wouldn't recommend it

author: maginnovision
author_rank: Super Contributor
timestamp: May 07, 2020, 09:47:16 pm
content: For me... Between VS, eclipse, netbeans I definitely rank them in that order. I only use eclipse because it's a requirement for some projects but I'm used to it so it's not bad but I definitely prefer VS. It's all a matter of opinion though based on individual experiences so it's really not worth arguing about. Supposed to be arguing about C anyway, haha.

author: Kosmic
author_rank: Super Contributor
timestamp: May 07, 2020, 09:52:26 pm
content: Quote from: bd139 on May 07, 2020, 09:28:09 pmhmmm the whole database is in RAM ?

author: bd139
author_rank: Super Contributor
timestamp: May 07, 2020, 09:58:07 pm
content: Yes sort of. However this particular scenario was caused by a memory leak and spinlock deadlock (ReaderWriterLockSlim in C# is BUGGY AS HELL which makes a mockery of their "concurrent" data structures). Usually doesn't run that hot. Working set is around 800gb and 30% CPU load.

author: Kosmic
author_rank: Super Contributor
timestamp: May 07, 2020, 10:03:27 pm
content: Quote from: maginnovision on May 07, 2020, 09:47:16 pmBack On topic,I would say that I used C when the project was smaller and when resource efficiency was important. The problem with C (and even more with assembly) is the fact that they don't scale very well. It's possible to create a huge application with C but it's really hard and tricky to keep the control as the application is growing.On the other side OOP and C++ give you some tools to scale your application but you end up being a bit less performant and efficient.So for me, it's all about using the right tool for the right job. Personally, I tend to use C on MCU, C++ for big application that need performance and C# when I don’t really care about performance and I just want to do something quick (90% of what I’m doing at home)

author: dietert1
author_rank: Super Contributor
timestamp: May 07, 2020, 10:45:23 pm
content: As far as i understand, object oriented development is good for libraries and APIs (abstraction).When i have to produce firmware for an embedded project, i rarely arrive at writing a library (e.g. operating system). But i may be using one. So in general it will be C++ nowadays. Though cpp files and a C++ compiler don't mean object oriented development.Regards, Dieter

author: coppice
author_rank: Super Contributor
timestamp: May 07, 2020, 11:51:27 pm
content: Quote from: dietert1 on May 07, 2020, 10:45:23 pmC++ is terrible for libraries. If you write a library in C it is trivial to make it callable from pretty much anything. If you write a library in C++ you need to be constrain yourself more or less to writing in C if you want to make it callable from a wide variety of other languages.

author: IanB
author_rank: Super Contributor
timestamp: May 08, 2020, 02:01:42 am
content: Quote from: Kosmic on May 07, 2020, 10:03:27 pmThere have been many comments in this thread about bloat and inefficiency, and why C++ is not suitable for low level hardware. It would take me a while to search back and find them all.One comment by (I don't remember who) mentioned about non-deterministic behavior, and you don't know when things are going to happen (?), which is absolutely not a property of the C++ language. It doesn't have managed memory like Java or C#, there are no garbage collectors, and you do know exactly when memory will be allocated and de-allocated according to the standard. You have complete control over resources.I just watched a very interesting presentation about coding for low level hardware in C++, about as close to the metal as you can get. It is worth a watch, as food for thought if nothing else.

author: dietert1
author_rank: Super Contributor
timestamp: May 08, 2020, 05:46:55 am
content: Quote from: coppice on May 07, 2020, 11:51:27 pmI know there are other languages than C and C++. As i wrote before i rarely arrive at writing libraries, but i often use some. I guess that probably applies to most of the contributors here. Using C++ with STL is something very nice in comparison to old fashioned C style. But some won't ever understand.Regards, Dieter

author: nuclearcat
author_rank: Unknown
timestamp: May 09, 2020, 02:42:24 am
content: Here is big article, unfortunately in russian (not sure if google translate can do it's job)https://habr.com/ru/post/347980/It can be condensed to fact, that they did cooperative efforts to write most efficient code to do some simple task (button and letds) , and they got much more readable C++ with OOP 400 bytes in flash and 72 bytes in stack, VS pure C much less flexible and readable 396 byte in flash and 72 bytes in stack.Assembly is near identical (no performance difference).Yes, C++ have many sweet features that is better to avoid on MCU (for example even silly vectors), but if you just use it for OOP and some "safe" features - it is not less efficient than C.

author: 0db
author_rank: Frequent Contributor
timestamp: May 09, 2020, 12:22:37 pm
content: Linus Torvalds "Nothing better than C"

author: maginnovision
author_rank: Super Contributor
timestamp: May 09, 2020, 04:17:56 pm
content: I'm going to take linus' opinion about as seriously as Stroustrups. They're both too invested in their languages of choice.

author: coppice
author_rank: Super Contributor
timestamp: May 09, 2020, 04:36:24 pm
content: Quote from: maginnovision on May 09, 2020, 04:17:56 pmNote that Linus didn't say there was nothing as good as C. He said there was nothing better. When C appeared there were languages like Coral (rather UK centric), BCPL, some variants of Algol, some variants of PL/1, and so on, targeting the same kind of "working close to the metal" style that is so necessary for systems software, and low level embedded software. There were a few proprietary ones from people like DEC, too. They all did a pretty good job. One or two had some very useful things C lacked, such as nested versions of structures, but nothing that made any of them truly stand out. C is the one we are left with in 2020.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 09, 2020, 04:43:33 pm
content: And while all the fanboys are one-upping each other over the finer points of their chosen language, the C# guy is gettin' shit DONE

author: bd139
author_rank: Super Contributor
timestamp: May 09, 2020, 05:06:41 pm
content: Actually no we just used iPython and scipy.fftpack about 2 days ago and are now slacking on here until our fixed term contract is up while getting the stink eye from the permanent employees writing shit in C# laboriously(and there’s LabJackPython for ref)

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 09, 2020, 05:08:10 pm
content: Oh, and a simple raytracer I wrote last year in C++. Can't do that shit in C#.The best tool for the job...BTW, who gives a F*** what Linus Torvalds thinks?

author: bd139
author_rank: Super Contributor
timestamp: May 09, 2020, 05:15:50 pm
content: https://github.com/lukehoban/LINQ-raytracer/blob/master/LINQRayTracer.cs?

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 09, 2020, 05:18:35 pm
content: Quote from: bd139 on May 09, 2020, 05:15:50 pmAnd your point is.....

author: bd139
author_rank: Super Contributor
timestamp: May 09, 2020, 05:19:04 pm
content: Quote from: engrguy42 on May 09, 2020, 05:08:10 pm?

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 09, 2020, 05:22:02 pm
content: Quote from: bd139 on May 09, 2020, 05:19:04 pmWow. You got me on that one.

author: intmpe
author_rank: Contributor
timestamp: May 09, 2020, 05:26:00 pm
content: C is typical for small microcontrollers like the PIC and even the ARM.Having said that most "good" c compiler vendors will provide libraries to perform functions that would otherwise require a lot of coding - i.e. fractional mathematics and a bunch of other stuff that the microcrontroller does not natively support. They provide libraries to bit bang pins, software rs232, lcd code ... the list goes on and on.So even if you do buy a C compiler its not a complete pain in the ass like it was in the old days (I personally used to hate the language), but with the libraries I am satisfied enough. I am still pissed that the pricks who wrote if thought it was a good idea to put a ; a the end of every line. The syntax sucks ass and is unnecessary. Even pascal had better syntax but the purists would never accept that. Delpi though has gone open source - it still has a following. There is a guy in Adelaide with an Oberon based compiler and mikroelectronica sell their compilers in C, Basic and Pascal so the environement and choice is still rich. Pascal is still alive and kicking from several sources.On the other hand if you program using Visual Studio on the PC desktop, you have the choice of C# and VB. Now I have used both and was once also a Quickbasic programmer. Quickbasic was structured basic. VB.net is only notionally related to basic. Sure some of the syntax is there but Visual Studio forces you to write code in an object orientated way so if you were transported from 1985 using the dos basic compiler to todays vb.net you would be completely lost and it would only be vaguely related to basic.On the other hand it is relatively simple to convert C#.net to VB.net and back again. The syntax is slightly different but Visual Studio forces the same code structure so I have done that many times - either one is usable and I don't consider them to be much different. VB.net used to be the most widely used desktop language in the world but Microsoft stopped publishing the download numbers (probably when they integrated them all together - you can mix vb.net and c# code blocks in a single project) - besides it was probably embarrassing - I mean look what happened to J# .. they had to kill it off. C++ proper is in Visual studio but I would say it is no where near as popular as the other two as it was developed earlier and lacks the same code structure as the .net languages. Of course if you are on linux or the desktop you can use c++ in VS or g++ as a front end to gcc. Basically if you have a favourite language for a chip there is probably a compiler for it.Ironically for the first time in 20 odd years I have had to recently write code for the PIC using assember for speed.

author: Berni
author_rank: Super Contributor
timestamp: May 09, 2020, 05:27:51 pm
content: No raytracing in C#? Here is one then done completely in C# then:https://github.com/mellinoe/veldrid-raytracerAs a bonus it also translates the C# code into shader scripts to execute on the GPU. But go ahead and compare even the CPU only version for speed.Yes we know C# is typically not quite as fast as C++, but with some care to optimize things it gets the same sort of ballpark performance. You can't really objectively say if C++ or C# is better. They are good at different things, but they are both powerful languages that can do a lot.Its the programmer behind the keyboard that determines the performance of the code, the language just gives him the tools to do it.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 09, 2020, 05:30:57 pm
content: Quote from: engrguy42 on May 09, 2020, 05:18:35 pmWhat exactly was yours? Guess he just posted that to show it was possible (and of course it is - as long as you have reasonable FP support, I don't see how you could not write a raytracer in almost any language. Heck, I guess you could even write one with pure fixed point too, although that would require some serious thinking.)"Can't do that shit in C#."With that formulation, we actually don't know whether this was meant as a general statement (which then is obviously wrong), or simply that YOU can't write a raytracer in C#. Which is completely possible and even a fair point, but then I guess you should maybe express things in a bit clearer way so we know your intent is to talk about what YOU use and why (which is on-topic indeed), rather than make it pass as a general fact.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 09, 2020, 05:33:29 pm
content: I humbly apologize for making an inaccurate comment. Humbly. It was a terrible mistake. I'm duly ashamed. I now realize that even slightly inaccurate comments have no place on this forum.Yes, you can use C# for raytracing. I was merely basing it on my experience whereby CUDA (NIVDIA's GPU API) is pretty much reliant on C/C++, and that's what I was using.But yes, there are exceptions.My bad. I'm a very very very bad boy.

author: bd139
author_rank: Super Contributor
timestamp: May 09, 2020, 05:41:26 pm
content: https://documen.tician.de/pycuda/

author: nctnico
author_rank: Super Contributor
timestamp: May 09, 2020, 05:45:22 pm
content: Quote from: bd139 on May 09, 2020, 05:41:26 pmYou kind of beat me to it...Ray tracer in Python:https://excamera.com/sphinx/article-ray.html

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 09, 2020, 05:46:33 pm
content: Quote from: bd139 on May 09, 2020, 05:41:26 pmHmmm...if I didn't know better I'd think that maybe the only goal of some folks here is to prove me wrong, and they'll go Google crazy to find exceptions to what I say....Nah, can't be.BTW, at the time I was starting to get into raytracing I was using C#, and wanted to stick with it for the GUI aspects. I wanted to do a raytracer, but have user control (buttons, windows, user controls, etc.).Unfortunately, integrating the CUDA-related stuff for my NVIDIA GPU's was, as far as I could tell, a HUGE PITA. So I relented and did it in C++. When I saw all the support stuff available if I did it in C++ (including NIVIDA resources), it seemed clear that C++ was the way to go. For me.Now I'm sure others were willing to use other languages, but I wasn't. Again, I apologize for not going the extra mile.Bad boy.

author: Karel
author_rank: Super Contributor
timestamp: May 09, 2020, 05:53:41 pm
content: Quote from: engrguy42 on May 09, 2020, 05:08:10 pmI do. I learned a lot from Linus and the Linux kernel development in general.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 09, 2020, 05:54:54 pm
content: You can obviously write raytracers without using CUDA, and that's probably what most people were thinking about here when you made that first statement.But if I were using CUDA, I would personally indeed NOT bother (although it's certainly possible) using any other language than C or C++.

author: Berni
author_rank: Super Contributor
timestamp: May 09, 2020, 06:02:31 pm
content: Quote from: engrguy42 on May 09, 2020, 05:33:29 pmNot a problem. C# will import regular machine code DLL files made with C++ in a similar way it imports its own native .net CLR DLLs. Its just not quite as streamlined.VisualStudio even lets you create split projects that combine C# and C++ code. The C++ part compiles into a DLL and the C# app imports it. Tho its not really all that great of an experience since some boilerplate code is involved to explain to .net exactly how it should use the functions inside the DLL. But it does work fine.Most modern languages support these because it is required due to how prevalent these compiled machine code libraries are. Tho i will admit that doing something like raytracing in software using python would likely be ridiculously slow (But this is not what python is made for). Yet even things like JavaScript are rather performant these days (JIT compining and such) and run under the hood of a lot of things. Can't say i particularly like JS personally but it can do some impressive things regardless.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 09, 2020, 06:02:40 pm
content: Quote from: SiliconWizard on May 09, 2020, 05:54:54 pmI suspect that those who have much experience with ACTUALLY writing raytracers would probably say "yeah, you can use other languages, but since NIVDIA rules the GPU world and they have so freakin' many C/C++ resources for CUDA, etc., it's more of a hobby/science project to use other languages".And they probably wouldn't turn purple searching Google for exceptions as fast as they could.Out of curiosity, has anyone here written a raytracer? Perhaps you can show some of your results?

author: bd139
author_rank: Super Contributor
timestamp: May 09, 2020, 06:03:54 pm
content: Quote from: engrguy42 on May 09, 2020, 05:46:33 pmActually wasn't Google. I did some experiments with that and eventually settled on cuDF for what I was working on. However shite old rules engine based on 1988 tech written in C# won on price vs matching performance vs staff availability to maintain itGPUs have other uses...The point is mostly making broad assumptions is not a good idea.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 09, 2020, 06:07:20 pm
content: Quote from: bd139 on May 09, 2020, 06:03:54 pmHuh? Are you new here? This place is all about broad assumptions and generalizations and unsupported opinion

author: bd139
author_rank: Super Contributor
timestamp: May 09, 2020, 06:10:05 pm
content: I think the average standards are higher than yours personally.

author: intmpe
author_rank: Contributor
timestamp: May 09, 2020, 06:12:50 pm
content: Quote from: engrguy42 on May 03, 2020, 05:45:28 pmYes, there is a Linux compiler for it and a couple of commercial ones. It is still the preferred language in much of naval architecture (or was) due to the availability of libraries like lapack (IIRC). A lot of finite element stuff was written in it as well for structural engineers. A few years back I was asked to work on some old military code using Fortran 66 - they needed to extend the code as it modeled a particular process. The military usually works on the principal if it works dont mess with it. I hadn't done Fortran 66 but had done Fortran 77. It's a hard language to port due to the spaghetti code nature of it - so its probably going to last a while. It's a lot easier to extend existing code than to port it to C etc.

author: IDEngineer
author_rank: Super Contributor
timestamp: May 09, 2020, 06:59:54 pm
content: Quote from: intmpe on May 09, 2020, 06:12:50 pmThis is exactly why there's still a lot of COBOL code running government infrastructure too. Nobody dares to be the politician or bureaucrat who bets their job/career on "updating" some long-working COBOL application to a more modern language. Let's be honest, more votes can be bought for less money doing other things.

author: IDEngineer
author_rank: Super Contributor
timestamp: May 09, 2020, 08:13:18 pm
content: Since folks like to quote it: "TIOBE Index for May 2020: C passes Java and becomes number 1 programming language".https://jaxenter.com/c-programming-may-2020-171598.html

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 09, 2020, 08:41:01 pm
content: For a bit more C# perspective, and how it can help with workbench stuff, I'm pretty much done with my data acquisition app. For now. Maybe 75% of it I wrote today, and that's after not touching C# for a while. Nice and quick to get user interface stuff done.Basically it reads a data acquisition device (Labjack) via USB. I'm also using an excellent C# math library called Mathnet. You can do FFT, for example, in just a single line or so.You first connect to the Labjack data acquisition device, and it has 8 analog inputs (plus some digitals and other I/O stuff). So I've set it up to let the user enter how many seconds to scan, and it plots that on the top chart. You can then do an FFT on the waveform.Or you can log data from 4 other inputs, and you can also select via checkbox to do realtime graphing of any of those. The FFT and logging charts are on top of each other, so whatever you select will be enabled and displayed. And you can stop the plotting whenever you want.In the screenshot below I've grabbed 0.5 seconds of a 60Hz triangle wave, and simultaneously done realtime plots of a couple analog inputs (I varied some power supply dials). I've hard-coded it to sample the bottom inputs every 0.5 seconds, and the chart automatically updates and re-scales the X and Y times and magnitudes. Very slick. And this is just default behavior of Windows forms.Yes, you can do something like this in 12 other languages. No question. Though I'm sure I'll be corrected that "it's not 12, it's 13".I'm just giving one example of something that can be done real quick, with drag-n-drop charts and buttons and a few hundred lines of code, in case anyone might be interested in setting up something for their workbench.

author: nctnico
author_rank: Super Contributor
timestamp: May 09, 2020, 08:56:51 pm
content: Quote from: IDEngineer on May 09, 2020, 08:13:18 pmInteresting. That just made one of my eyebrows move upwards. I did not expect that. Also the decline of C# is impressive. About a decade ago people where convinced C# would kill Java. Some actually called C# 'A Java which works'.

author: bd139
author_rank: Super Contributor
timestamp: May 09, 2020, 10:56:48 pm
content: See my earlier rant. It’s dying on its arse. Even the stalwart C# guys are disenchanted. Not because of the platform but the complete mismanagement of it for 20 years. Honestly wish I hadn’t wasted a chunk of my brain on it.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 09, 2020, 11:12:29 pm
content: Interesting. Looks like that survey of most popular is based on search engine results. C is the most searched for.I don't suppose it's because the other languages are easier and more intuitive and don't require a lot of "WTF IS THIS C STUFF??" searches.

author: floobydust
author_rank: Super Contributor
timestamp: May 09, 2020, 11:23:33 pm
content: Computing Science has failed to make a decent programming language.Every language is intellectually orgasmic and the academics circle jerk off to them, but all fizzle out after many years, and then yet another language is born and the cycle repeats.C is just a high-level assembly language, extremely dangerous because it really checks for nothing. Think of the all PC Trojans, viruses exe'd due to buffer overflows.My CompSci Uni prof spent two weeks in class pissing around with pointers in C, seeing what would happen with "funky" de-referencing. It's worse than the Wild West.Unfortunately C has made it to cars, airplances and other safety-critical applications for embedded systems. It's just too dangerous IMHO.Just the other day I stumbled onto this:Code:boolean myFlag;myFlag = 2;myFlag = "A";myFlag = 3.14159;All of which of course compiles and runs in C.Absolute GARBAGEI hate dealing with this language, it needs to have some fixes that don't go all nutbar into C++ polymorphism, operator overloading etc. but people have given up and now it's Python as the latest fad language. Sigh.

author: coppice
author_rank: Super Contributor
timestamp: May 09, 2020, 11:26:24 pm
content: Quote from: bd139 on May 09, 2020, 10:56:48 pmI haven't touched C# for some time. It wouldn't surprise me to find its being mismanaged. It was mostly created for political purposes, so its continued funding would depend on the success of that political ploy. What kind of mismanagement has there been? Poor compiler? Poor libraries?

author: bd139
author_rank: Super Contributor
timestamp: May 09, 2020, 11:39:47 pm
content: Quote from: coppice on May 09, 2020, 11:26:24 pmBest bet is hit my previous rant on ithttps://www.eevblog.com/forum/chat/how-many-people-code-in-c-these-days-and-if-so-why/msg3053124/#msg3053124

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 09, 2020, 11:41:23 pm
content: For some reason people are compelled to label stuff either GOOD or BAD. And it's never the case.C is wonderful, it's served millions well for many years. It has pro's, and it has con's.C++ is wonderful, it's served millions well for many years. It has pro's, and it has con's.Python is wonderful, it's served millions well for many years. It has pro's, it has con's.C# is wonderful, it's served millions well for many years. It has pro's, it has con's.And so on.Nothing in this universe has ever been perfect.And the fact that every tool you've ever used has pro's and con's means that anyone can always point to a con if they want to discredit the tool. But for those who have used the tool successfully for many years, those cons are likely irrelevant.

author: coppice
author_rank: Super Contributor
timestamp: May 09, 2020, 11:52:23 pm
content: Quote from: bd139 on May 09, 2020, 11:39:47 pmSo your main issues are with .net? That has been a disaster for everyone using MS products, not just C# developers. The original versions were a complete joke.

author: maginnovision
author_rank: Super Contributor
timestamp: May 10, 2020, 12:05:09 am
content: My first experience with .net was porting a game written in visual basic 6.0 over to C#. They had a tool to sort of auto port the thing. After it did that it only took 8 hours to fix everything that was broken and double the size of the executable. I haven't really touched it since but I know devs who have and don't have any problems with it. It's all about what you're used to.

author: IDEngineer
author_rank: Super Contributor
timestamp: May 10, 2020, 12:28:39 am
content: Quote from: floobydust on May 09, 2020, 11:23:33 pm...which is both its strength and its weakness, like all good and powerful tools. An idiot can do stupid things and hurt themselves with any tool, and the "less safe" the tool the more likely this becomes. But in the hands of someone competent, few language tools are more powerful or flexible and truly competent craftsmen do not want a bunch of protective features getting in the way.The better the craftsman, the fewer restrictions he wants (and needs) on his tools. A screwdriver with PlastiDip on its tip may seem "safer", but its usefulness is severely hampered. A soldering iron that "doesn't get too hot" might seem "safer" but might also have very few applications. Both of these might be suitable for neophytes, but not for most people on this site.Before someone says "But look at all the bugs in [your favorite example] from [your least favorite large software company]" as a supposed example of how C can have bugs even when written by "the best", remember that sheer company size does not guarantee that they hire only competent software people. I've met some surprisingly ignorant software folk who sported business cards with names like "Microsoft" and "Adobe".As noted herein by others, this is another example of "The right tool for the job". To which I would add, "...while also considering the person DOING the job". C is an excellent choice when the author is competent. The less competent the user, the more hand-holding and safety nets and babysitting they need. Thankfully, there are languages which provide such things when the author is someone who needs such protection.

author: rsjsouza
author_rank: Super Contributor
timestamp: May 10, 2020, 12:35:30 am
content: Another one that does almost exclusively assembly and C due to small memory footprint on the platforms I work. A tiny fraction is done with what I call an alkost naked C++. Right tool for the job.I do a lot of batch and shell scripting, as well as javascript and some python on the bigger systems.

author: Cerebus
author_rank: Super Contributor
timestamp: May 10, 2020, 12:38:34 am
content: Quote from: floobydust on May 09, 2020, 11:23:33 pmExcept of course it doesn't compile and, indeed, isn't C.Code:void FLoobiesAssertionIsThatThisWillCompileInC (){boolean myFlag;myFlag = 2;myFlag = "A";myFlag = 3.14159;}Which, if compiled, will yield this:Code:cerebus@shu:~/Desktop$ gcc-9 flooby.cflooby.c: In function 'FLoobiesAssertionIsThatThisWillCompileInC':flooby.c:3:5: error: unknown type name 'boolean'3 | boolean myFlag;| ^~~~~~~flooby.c:6:12: warning: assignment to 'int' from 'char *' makes integer from pointer without a cast [-Wint-conversion]6 | myFlag = "A";| ^cerebus@shu:~/Desktop$C does not have a boolean type. A C compiler will definitely complain if you try to assign a string (char *) to a non-string type. Many languages will silently cast a floating point type to an integer and vice versa, so that's a odd thing to pick on. And the rant against academic languages is a bit odd given that C does not have its origins in academe, but in Bell Labs.If you're going to rant about a language a prerequisite is to know the language well enough to know whether you're ranting about the language or ranting about what you imagine the language is.

author: Wolfgang
author_rank: Super Contributor
timestamp: May 10, 2020, 12:44:00 am
content: Quote from: Cerebus on May 10, 2020, 12:38:34 amC is for users who know what they are doing and who can write code in a safe and defensive way.There is very little "shoot yourself in the foot" protection, agreed. The dirty minds should therefore play with something else ...

author: intmpe
author_rank: Contributor
timestamp: May 10, 2020, 12:50:29 am
content: Quote from: engrguy42 on May 09, 2020, 06:07:20 pm+1 thats because we are really talking about programming and as I was taught in school many years ago its as much an Art as it is a Science. It is not engineering, despite the fact that everyone who reads a book at barns and noble for that .net job gets called a software engineer. Its like your local HR getting renamed a Human Factors Engineer. For the majority of programmers it was just as hard in 1985 trying to extract every clock cycle out of a commodore 64 via assembler - probably harder because there was just a lot less access to information - and many of those who did it were kids. I wouldn't be surprised if the best python programmers out there today are kids via things like the PI.

author: IanB
author_rank: Super Contributor
timestamp: May 10, 2020, 01:00:32 am
content: Quote from: Cerebus on May 10, 2020, 12:38:34 amWhy do you say this? Which C standard are you considering?QuoteIt will?I just compiled this using my friendly local C compiler, and there were no warnings:Code:#include <stdio.h>int main(void){_Bool flag;flag = 2;flag = "A";flag = 3.14159;printf("flag = %d", flag);return 0;}When I run it, it produces the output "flag = 1": the C language defines any non-zero value as true, and true is represented as 1. So the non-zero double is down-cast to a _Bool type and becomes 1.

author: coppice
author_rank: Super Contributor
timestamp: May 10, 2020, 01:05:55 am
content: Quote from: IanB on May 10, 2020, 01:00:32 amC has a boolean type, but the keyword for it is not "boolean" like the example code being referred to.

author: IanB
author_rank: Super Contributor
timestamp: May 10, 2020, 01:14:05 am
content: For interest.Exhibit 1:Code:#include <stdio.h>int main(void){if ("not empty"){printf("The string is not empty\n");}if (""){printf("The string is empty\n");}return 0;}Exhibit 2:Code:#include <stdio.h>int main(void){_Bool empty1 = "not empty";_Bool empty2 = "";if (empty1){printf("The string is not empty\n");}if (empty2){printf("The string is empty\n");}return 0;}Both produce the same output:Code:The string is not emptyThe string is emptyThis is canonical C, and is how the language is designed to be used, keeping it brief without unnecessary operations or verbosity.

author: Cerebus
author_rank: Super Contributor
timestamp: May 10, 2020, 01:16:02 am
content: Quote from: coppice on May 10, 2020, 01:05:55 amPresactly.

author: IanB
author_rank: Super Contributor
timestamp: May 10, 2020, 01:20:48 am
content: Quote from: Cerebus on May 10, 2020, 01:16:02 amFrankly, this is at the level of a playground argument: "You didn't use proper grammar, so you're wrong! So there!"I thought we were meant to be adults here?

author: intmpe
author_rank: Contributor
timestamp: May 10, 2020, 01:25:51 am
content: Quote from: Cerebus on May 10, 2020, 12:38:34 amBe careful with that though because back then these large US corporations with operations like Bell used to run like college campuses where a big part of your job was to publish or patent. I worked at Bell labs in NJ 10 years ago. It was half deserted and they were preparing the coffin for it out the front. When K&R wrote C in the late 70's was like the end of that whole era - so it was coming to an end then. You could say the same thing about a lot of US engineering companies. I earlier worked at GE research labs and it was a gloomy place just waiting for someone to drop and axe and write a requiem. They had gotten out of electronics 20 years earlier and had announced internally they would never ever under any circumstance re-enter the field. Profits were dead - they had gone to Japan/HK/TW by the late 70's. Now its China - its been china since the 90's. I was in Japan 20 years ago and could hardly find an appliance made in Japan. It was all coming out of China even then. And now its leaving China slowly even as they have been gearing up - although I suspect they are slowing that spending spree - they already have all the tech they need. At Motorola they used to call that part of the company Motorola University internally and it was a basic research arm. All of it died about 20 years ago - Motorola being one of the last. GE kept the campus open but the allowable work was shit and depressing. Short story is that time period is over, dead and buried. Even at Universities today you would be hard up to do what K&R did because you need to publish fast. Long term projects don't cut it anymore so you get a constant stream of published garbage. Both Universities and Industry are in trouble. Like I said - I did a US masters just for fun - it was complete shit - not even Masters level IMO. Good school. Mostly taught by adjuncts or even professors who could not give a shit about feedback. Even before this virus thing the only time they ever had was to throw your marks on a web page. Usually with no explanation. So its the worst degree I ever did. What was really hilarious was my colleague did a chip at one of the best public unis in the US using the same tool and the same fab company and process that I did 25 years ago as a 3rd year undergraduate. The difference? I actually had it fabed and went in to put it under the microscope when part of it had a problem. What did he get? Nada - they went through the process of the chip design and layout to the point of preparing the package for fab but the school did not actually spend the money to have it fabed. So that's my experience of US universities.You want to work in a university like research environment in industry now? - I don't know of any US companies but Toyota Research Labs was pretty good and I was getting called by the basic sciences group at Huawei a few months back. It's always where the money, brains and leadership is, and no US company that I know has that. It's all run by private equity and wall street so their view is only a few years at most ahead.K&R were lucky - they just made the end of the University like heyday at Bell. Assuming the building still stands if you walk into the lobby at Bell the walls are covered with patents from the 50's and 60's. The walls are 50's paneled walnut straight out of an episode of perry mason.

author: Cerebus
author_rank: Super Contributor
timestamp: May 10, 2020, 01:32:58 am
content: Quote from: IanB on May 10, 2020, 01:20:48 amThere was rather more flawed in the argument put forth than just the spelling of a type name.

author: Cerebus
author_rank: Super Contributor
timestamp: May 10, 2020, 01:46:46 am
content: Quote from: intmpe on May 10, 2020, 01:25:51 amThere is a huge difference between a commercial R&D facility, even ones as freewheeling as Bell Labs or PARC, and academia. The ongoing development of C & UNIX had to be justified at some point by a commercial aim, specifically the pretext used was to to produce a text processing system for the Bell Labs patent processing office. They might be ideas factories, but they are ideas factories that are expected to produce something that works at the end of the day driven by very different forces than academe.

author: IanB
author_rank: Super Contributor
timestamp: May 10, 2020, 02:12:01 am
content: Quote from: Cerebus on May 10, 2020, 01:32:58 amYes, but so far you have not presented any of those flaws. So your objections are not supported by evidence.

author: intmpe
author_rank: Contributor
timestamp: May 10, 2020, 03:48:15 am
content: Quote from: Cerebus on May 10, 2020, 01:46:46 amThere is actually not. Universities are businesses. They say at business school that engineers make the worst business people. This response proves it. Basic, Pascal, Minix, Linux, GNU, Netscape all came out of non-commercial activities. Even the Win3.1 TCP/IP stack that got everyone on the internet was non commercial.If one were to be more correct then its the old addage necessity is the mother of invention. Managers and hence companies are by their nature non innovative and non-creative. If you want to find the most non-creative person in a company - go to the c-suite. When I was in GE research labs we had one of the luminaries come back in. He effectively lectured the managers that while they may want something NEVER pre-define the research outcome because if you do you will get nothing. And so it was. Good researchers will deliver output - I have never not delivered - but its not always what they want. What they want is not always possible. i.e. cost.

author: Siwastaja
author_rank: Super Contributor
timestamp: May 10, 2020, 07:17:23 am
content: Quote from: IanB on May 10, 2020, 01:20:48 amNo, it just showed that the person who made that argument has actually used C very little, not even in the sense of reading other's code. For anyone working with C (hence being able to make an informed statement about its suitability) that piece of code would immediately strike as "not C".It's an important distinction when someone "proves" C is shit by using a very short example of just a few lines, whichobviouslyisn't C, claiming it "of course" goes through a compiler, which itobviouslydoesn't:Code:hrst@jorma ~ $ gcc test.ctest.c: In function ‘main’:test.c:6:5: error: unknown type name ‘boolean’boolean myFlag;^test.c:9:12: warning: assignment makes integer from pointer without a cast [-Wint-conversion]myFlag = "A";If they had thought this over, the example would make the point. Now it's a piece of code which is neither C, nor showing any meaningful point even if corrected to be C. If anything, it demonstrates type safety on any compiler I tried (different clang and gcc versions; no extra flags necessary) by issuing warnings about the strange type conversions performed by the programmer (and hence, suggesting more explicit proof, in form of explicit cast, that the assignment is intentional.) Many modern languages would accept the equivalent series of statements, not only without any warnings, but performing "something probably useful", and worst, this would not be an example hownotto do it, but an examplehow to do it.All in all, even if adjusted to go through compiler, the example showing the implicit type conversions of the boolean type is funny in this context, because compared to most modern contenders (such as Python), C ismore stronglytyped, and from this viewpoint,more safe. If they wanted to show an example of C being unsafe, out-of-bounds indexing, or missing a zero termination on a string, would be classics, or using one of the many dangerous classic C standard library functions (such as sprintf) people still use out of convention.The general direction seems to be: implement less and less type enforcement, and do more and more silent type conversion,for convenience, for beginners. Which, obviously, isdangerouseven if it is convenient. Operations don't make sense when you don't know what the operands represent, and when the representation suddenly changes between adjacent operations.But it's always trendy - have been for dedaces - to circle jerk around C's extreme level of dangerousness, and claim that modern alternatives are magically much more safer. This is naturally not the complete picture. C indeed lacks many "safety features", and has some dangerous design choices, but strict(er) typing (compared to most trending languages, that is), which is optionally bypassable with clear and explicit syntax, seems quite a good mix between safety and performance. It could be better, even in C you have implicit type conversions happening when you least expect it, allowing for a footgun of a sort, but it's still a lot better than having no type enforcement at all. (It always strikes me funny how people who show C isn't type-safe enough, offer the solution of removing type-safety completely.)C has never been academically trendy because it isn't pure, all sides of it lack something. Yet it seems to be "good enough", and the contenders come and go, struggling, often trying to be too pedantic and losing the big picture.Python's typing ishandy, just type some letters from the keyboard without thinking, and itguessesthe intent, and does fairly good job on it: when you test the code, itlikelydoes what you wanted. For safety, relying on such luck element is an utter catastrophe (especially when the runtime can change its decision with a different version). The fact that atypeis not only dependent on the code, but also the runtime data content (I remember struggling with this with PHP in 2002), is a safety disaster and it's very hard to get 100% test coverage.That's why Python isn't used for mission-critical embedded work, but C is, despite its undeniable shortcomings, even regarding safety.

author: Cerebus
author_rank: Super Contributor
timestamp: May 10, 2020, 08:13:14 am
content: Quote from: IanB on May 10, 2020, 02:12:01 amLook, if you're going to carp at someone at least read what they wrote before you carp on about it.Quote from: Cerebus on May 10, 2020, 12:38:34 amJust to make it easier for you, let me re-present the points you missed as a numbered list:Except of course it doesn't compile - refers to "All of which of course compiles and runs ".C does not have a boolean type. - refers to "boolean myFlag;". Yes, I could have been clearer and used quote marks here - my bad.A C compiler will definitely complain if you try to assign a string (char *) to a non-string type. Refers to "myFlag = "A";"Many languages will silently cast a floating point type to an integer and vice versa, so that's a odd thing to pick on. Refers to ""myFlag = 3.14159;And the rant against academic languages is a bit odd given that C does not have its origins in academe, but in Bell Labs. If you can't work out what bit this refers to without hand-holding, god help you.If you want to cast aspersions about "playground level" arguments, I think "I disagree with what you said, but I couldn't be bothered to actually read it." definitely qualifies for tarring with that brush.

author: Cerebus
author_rank: Super Contributor
timestamp: May 10, 2020, 08:28:39 am
content: Quote from: Siwastaja on May 10, 2020, 07:17:23 amIf you delete "embedded" from that sentence it is wrong. I spent most of last year fighting with a mission critical system written in Python thatvery definitelyhad the capability of bringing the internal and public facing network of a certain FTSE 100 company to its knees if it didn't work properly. Not a great choice of implementation language for the task it was performing, IMHO. Still, I got paid stupid money to fix it, so who am I to complain?

author: Siwastaja
author_rank: Super Contributor
timestamp: May 10, 2020, 08:33:29 am
content: Quote from: IanB on May 10, 2020, 01:14:05 am(insignificant lines truncated by me)Are you really, likeseriously, claiming that this usage pattern would be a source of bugs or unsafe behavior?All I see is a demonstration of a trap for very young players, total noobs coming "backwards" to C from Python or similar, when they are learning for the first day or so, assuming they have a high-level string datatype available.No one is claiming that C is an easy, learn-in-a-day scripting language. It obviously requires learning and understanding, like most things in engineering,especially safety-critical.But this is exactly the point of using C, being closer to the hardware. If such operations would be automatically converted to string comparison operations, string length calculations, ascii/unicode-to-boolean operations (are you expecting strings "true", "false", or what??) or whatever, you1) would have absolutely no idea what's happeningexactly, and what the exact result will be,2) would have absolutely no idea about the consequences in runtime or memory usage, all of which is relevant not only on microcontrollers, but on higher-level system design as well.Having all this specified formally would result in a massive standard no one could ever read let alone remember key parts of - even the C standard is quite daunting. This is a no-go for robust engineering. Hence, more "advanced" languages are based on hope, luck, and testing, which is great for productivity in "quick demonstrations", but do not produce robust and safe software, even if the languages would prevent overindexing.It's quite revealing that you haven't even tried to specify what you wouldexpectas a result from these code patterns, and why. Do you really think that "" should just silently equal to false, and "not empty" should silently equal to true, and why in the world is that? Is there a language with this kind of assumption, tell me because I really don't know? Or do you expect the compiler to pull in an AI module, trying to figure out the meaning of the human-language strings, like "Trump is an idiot" equaling true, and "Trump is great" equaling false?

author: Cerebus
author_rank: Super Contributor
timestamp: May 10, 2020, 08:50:50 am
content: Quote from: intmpe on May 10, 2020, 03:48:15 amWell, the first business that I was one of the 3 on the senior management team in the 90s went from zero to a profitable turnover of £6 million in its first year, so yeah, engineers clearly make terrible business people - I'm living proof!Before you launch off making sweeping and somewhatad homiemremarks on here, it's wise to consider that there's a lot of folks on here who've been around the block more than once or twice. What next, telling Win that he knows nothing about writing textbooks? Also, using "business school" as support for an argument is likely to draw hollow laughs out of anyone here who has encountered the output of "business schools" in real life.Hint: Most of them need assistance tying their own shoelaces.Moreover, the idea that Universities are (or ought to be) businesses is more telling of a certain mindset than it is an accurate description of Universities. They are supposed to be institutes of learning and research.QuoteI'm not the one that contends that academe has not produced a good programming language.

author: IanB
author_rank: Super Contributor
timestamp: May 10, 2020, 09:01:08 am
content: Quote from: Cerebus on May 10, 2020, 08:13:14 amI did read what you wrote. Maybe you could do me the honour of also reading what I wrote?QuoteI didn't miss your points. I just declined to get into an argument about them.But since you press the issue, let me respond to your list:You said it doesn't compile--it does.You said it isn't C--it is.You said C doesn't have a boolean type--it does.You said C will definitely complain if you assign a string to a non-string type--it doesn't here.I demonstrated all of these truths above in post #204.I do not accept the conclusion that this means C is garbage, however. The language has good reasons for behaving the way it does.But nevertheless the only mistake made by floobydust was failing to use the correct type specifier for a boolean. Like I said, a simple grammatical error.

author: IanB
author_rank: Super Contributor
timestamp: May 10, 2020, 09:07:52 am
content: Quote from: Siwastaja on May 10, 2020, 08:33:29 amNo, I am simply demonstrating facts about the C language, after Cerebus stated a bunch of incorrect facts.QuoteWhy would I need to specify such? It's part of how C works. A non-zero value evaluates to true in a conditional (boolean) sense, and a zero value evaluates to false.This applies to all values, be they integers, doubles, pointers, chars, whatever. Therefore if you assign a value to a boolean variable, it will evaluate to true or false according to this rule. There is no reason for the compiler to barf or issue a warning about it.As I said in the post you quoted:Quote from: IanB on May 10, 2020, 01:14:05 am

author: Picuino
author_rank: Super Contributor
timestamp: May 10, 2020, 09:15:08 am
content: Quote from: floobydust on May 09, 2020, 11:23:33 pmThat's the reason why I thought in the 90s that Pascal would become a more used language than C.But in the end, C has remained a first-rate language, while Pascal or ADA hardly has a niche.

author: Cerebus
author_rank: Super Contributor
timestamp: May 10, 2020, 09:18:14 am
content: Quote from: IanB on May 10, 2020, 09:07:52 amTo me it just looks like you're just out looking for an argument, not the first time recently that I've noticed that in your posts. Time to hit "ignore thread", at least for me.

author: bd139
author_rank: Super Contributor
timestamp: May 10, 2020, 09:24:17 am
content: Have to side with Cerebus here. The argument was void (excuse the pun).

author: IanB
author_rank: Super Contributor
timestamp: May 10, 2020, 09:28:35 am
content: Quote from: Cerebus on May 10, 2020, 09:18:14 amI told you I was disinclined to argue and you accused me of not reading your posts. You ask me to address your points, and when I do you simply ignore what I present and accuse me of looking for an argument.

author: IanB
author_rank: Super Contributor
timestamp: May 10, 2020, 09:31:32 am
content: Quote from: bd139 on May 10, 2020, 09:24:17 amI showed in post #204 that the example program is perfectly valid C that compiles and runs without warning, entirely in contradiction to what Cerebus said.It received no response whatsoever.Apparently facts are unpalatable when they are contrary to people's emotional beliefs.

author: bd139
author_rank: Super Contributor
timestamp: May 10, 2020, 09:41:18 am
content: Compiler and flags please?Edit: irrelevant. Actually I just grepped about 3 megs of C code and can't find a single assignment to _Bool like that. I'm nto sure why you'd do it. Also works in python:a = Truea = "hahahaa fuck the rules"Play stupid games, win stupid prizes. No one is stupid enough to play that game in our code. Just yours.

author: Siwastaja
author_rank: Super Contributor
timestamp: May 10, 2020, 09:45:10 am
content: Yes, I don't disagree with the fact that your if("string") example is valid C (equivalent code is valid in many other languages, as well; and equally not making any sense), as is your modified code in post #204, which nobody has commented about, I was just looking for thepointyou are trying to make with your messages, but now that you have admitted you have none, and didn't even intend to, it explains many things, and it is unnecessary to discuss any further.I wouldrecommendyouthinkbefore posting, so that you have actually something to say (not just some true/false/true/false claims without any point or reason behind them), in the future, to avoid driving threads into this kind of bullshit argumentation, for the argumentation's sake. This is because whileyoumay be OK by justing for no reason, it's only natural thatothersexpect there to be a reason, even apoint, and are trying to find it, and fail. In other words, we are all trying to give you a chance, but you fail to deliver - assuming the deliverable of an internet forum is an "interesting discussion" or "increasing one's understanding"; not just fighting about whether claim X is true or false. What a waste of time, especially when coupled with classical goal shifting and outright lying.So please just stop doing this, and start being honest with us. Thanks for your consideration.This was inevitable, though. These kind of threads attract trolls. It stayed civil surprisingly long.

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 10, 2020, 10:15:27 am
content: What's in a tool?I've written a raytracer – or, to be precise, a mixed method raycaster – for rendering ball and ball-and-stick atomic models containing anything from just a few atoms, to hundreds of millions of atoms, for producing quality animation for events in simulated molecular systems. You know, the kind of size and complexity that gets your Nvidia card apoplexy. Because of the algorithmic complexity, I had to goback to the underlying math, ten years ago, to get things to work reliably. As I was using an old desktop machine with just a couple of gigs of RAM at the time, I even had to use memory-mapped files for accessing the data (if you know whatMAP_NORESERVEdoes, you'll probably understand how). (That entire tale, from combining different rasterization methods to reduce the number of objects tested for each ray, to consideration of information density in visualization and weirdnesses in human perception and exploiting them for conveying information, and to producing publication-quality graphics via low-resolution pixel images underneath raycast-solved vector outlines, is a funky tale in an of itself: I learneda lotthere. Then again, I actually worked it all out, instead of using existing toolkits and padding myself on the back for how good a "programmer" I am. I didn't do it because I knew how to do it, I did it to learn how to do it.)I do that kind of low-level code-mongery all the time, and for that, C seems most suitable. Raytracing has long since passed from the pure mathematics of descriptive geometry to emphasizing the features of human perception (and exploiting its limitations), so reproducing early simple examples by applying extremely powerful existing libraries is a good exercise, but nothing impressive.Back to topic at hand. Why C?The reason you do not want to use C++ for low-level cross-language libraries, is the risk of incompatible dependencies between different versions of the C++ runtime. In theory, the dynamic linkers should handle it without issies, but reality is imperfect. The nasty situation occurs when application A written in some other language than C++ needs libraries B and C, both of which depend on C++, but are compiled against different versions of the C++ runtime.A lot of microcontroller development now uses some subset of C++ (or even G++, the GNU C++ variant provided by GCC). While standard C has explicitly defined the freestanding environment (used in kernels and microcontrollers, when the standard C library and associated services are not available), the subset of C++ used varies, and is rarely if ever documented explicitly. They usually do not support exceptions, but otherverbotenC++ features vary a lot.Is it still C++ if one is supposed to keep to a strictly undocumented subset of its features? Not just avoiding the standard library, but core features of the language like exceptions? At least for C it (the freestanding environment) is well documented; for C++, almost all of it isimplementation defined, and varies from implementation to implementation. Can you still call it C++, if you need to test for support of each feature separately at build time?To me, it only matters when this kind of discussion raises its head. Whenever you see someone ridiculing others for using a tool they themselves cannot wield efficiently, there is stupidity afoot.Consider this:You are on a walk along a rocky river during one summer, when you come across a guy, obviously not an outdoorsman, with pasty skin not seen enough sunlight, now slightly burning, banging flint with a rock, obviously trying to recreate the way stone-age humans made their flint axes thousands if not tens of thousands of years ago.You smirk to yourself, and walk past without saying a word.What you do not know, is that that guy is a double PHD, expert in atomic force microscopy and nanorheometry, and is spending their summer day in getting some real-world practice in knapping flint. Working at the scale of individual atoms, those materials science devices need sharp-tipped probes, preferably single atoms wide at their tip, that can withstand the vibration and movement close to the materials being investigated; and even today, knapping flint -- robotically, of course, nowadays -- is the best, most repeatable way we have of producing such minuscule tips.What to you was an idiot banging rocks together, was actually somebody who understands reality fundamentally better than you.Why didn't you know this? Because Dunning-Kruger; and because tools are tools, and there are some that bridge a stone age human and a leading materials scientist of 2020s.While C really isn't that good of a language, we don't have anything better in its niche – low-level libraries with bindings to multiple languages, and so on. Anything that has a significant runtime or significant standard library won't cut it. It's just a tool most suitable for its particular kinds of nails.So, the simple answer is"because there are still problems for which C is the best tool".For right now, I like doing math crunchy stuff in C (i.e., low-level code), and the user interface in Python. I like the idea of end-users being able to modify the user interface if needed.I don't touch Perl due to old battle scars. Not really Perl's fault, I just had to work with a code base that was full of copy-paste-modify-slightly almost duplicates, critical to my users... You know the type: instead of fixing existing bugs, the functions are copied, the copy fixed, and only (some) future users using the fixed version, some the older version. (This was two decades ago now, and Perl has evolved a lot since then, so I really should take a look again. It's just that those scars itch easily.)For quite a few years, I wrote lots and lots of PHP code. Usually, the most critical part was to ensure none of the admins with access to the servers enabled "magic quotes" or other PHP misfeatures that gave it its reputation.. You can write quite secure code even in PHP.Fortran is still common in HPC, especially physics and chemistry simulations. While newer tools tend to be written in C or C++, if you want to duplicate old published results, you need to use that same code, too. Sometimes that is very important, if you want to know exactly why your results differ from previously published similar-but-not-exactly-the-same results: you add your new model details to old code, and use the old code to compare the results for both cases.The thing that annoys me most about some programmers, is that so many of them write code in the first language they learned, in every language they purport to know.This is nothing new. There was a saying already decades ago, "one can write FORTRAN code in any programming language", that describes this well.In my opinion, that's not "knowing" anything, it is just mechanical translation. It is like claiming you understand something, because you can recite a mathematical formula that in some situations describes its behaviour.You could even say that some of the above examples of C code fall into this category, because they show code that would cause anybody who is familiar with existing C codebases to raise their eyebrows. It is like saying that English is a horribly bad language, because in it "Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo." is a well-formed valid sentence.Every programming language has some core beauty, some idea, some paradigm, that makes it efficient and useful (according to some metric -- it is easier to just call it beauty) for some tasks. It is not important or useful to be able to mechanically translate code from one language to others; the important and useful part is understanding that beauty, and integrating it into your toolkit. And then, being able to choose the appropriate tool from your toolkit to whatever problem you have at hand.

author: jfiresto
author_rank: Frequent Contributor
timestamp: May 10, 2020, 10:18:05 am
content: Quote from: Siwastaja on May 10, 2020, 07:17:23 amI have noticed many keep associating C with strong typing. They keep using those last two words, but I am not sure they mean what they think they mean. Python, especially Python 3 which dropped some risky implicit conversions, is much more strongly typed then C. If Python code tries to call a non-executable object, it will fail with an exceptionCode:>>> func_addr = 0x0>>> func_addr()Traceback (most recent call last):File "<stdin>", line 1, in <module>TypeError: 'int' object is not callablewhereas the C equivalent will happily call the null pointer. The above object has no __call__ method and if you try to call it, Python will let you know that. If you do not handle the TypeError, it will let you know it good and hard.I think the distinction, if I correctly understand the criticism, is that C and Python are statically and dynamically typed, respectively. With C, you discover the type issues that the language and compiler care about, very early in the product's life cycle – at compile time; with Python, you discover type issues later to possibly quite later – when you or the customer actually run the code.EDIT: changed second use of "the issues" to "type issues", since Python's issues do not match C's.

author: nctnico
author_rank: Super Contributor
timestamp: May 10, 2020, 10:24:42 am
content: Quote from: IDEngineer on May 10, 2020, 12:28:39 amThat is true up to some point. Even the most skilled masters make mistakes. I like to avoid using C if I can. At least C++ allows to circumvent the use of pointers and freeing of dynamically allocated memory can be concentrated in the destructor of a class. But languages like Lua and Python are much more solving-the-problem-at-hand centric and don't suffer from overflows leading to an oil-stain which can't be traced back to the source. In C / C++ I add range checking to each layer of the software. That is just tedious stuff which doesn't add anything to the function of the program.

author: nctnico
author_rank: Super Contributor
timestamp: May 10, 2020, 10:45:57 am
content: Quote from: IanB on May 10, 2020, 09:31:32 amThere was a clear error in the code though: boolean isn't a C type but bool is (since C99). It is possible that an older (?) compiler comes with headers which define boolean as a type but AFAIK that isn't the common standard.https://en.wikibooks.org/wiki/C_Programming/stdbool.hIt also seems the storage size of bool varies between compilers.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 10, 2020, 11:25:16 am
content: I'm right, you're WRONG !!No, I'M right, YOU'RE wrong !!!I'm smarter than you.No I'M smarter than YOU!!I know how to Google stuff real fast. I'm much smarter than you.You're an idiot because you spelled it wrong.No, I'm RIGHT. It depends on what the definition of "is" is.Hold on, I need to "thank" everyone who's agreeing with me.I like C, so anyone who disagrees is a poo-poo head.Lalalalalala....I'm ignoring you....

author: coppice
author_rank: Super Contributor
timestamp: May 10, 2020, 11:45:10 am
content: Quote from: nctnico on May 10, 2020, 10:45:57 amI've always found that weird. The generated code rarely seems to improve through the use of a bool where sizeof(bool) is bigger than 1.

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 10, 2020, 12:47:50 pm
content: typedef enum { true, false, FILE_NOT_FOUND } boolean;

author: chriva
author_rank: Regular Contributor
timestamp: May 10, 2020, 12:51:51 pm
content: A C junkie hereWhile I do code in other languages too, there's something with C (and C++) I just love.Very little abstraction. You can do wild (and equally as dangerous) stuff like derefing a pointer as a function and jump to it, jump to yourself, use goto (I don't care what you say, they're perfect for very specific tasks), _MACROS_, function attributes, etc etcAbout bool: It's also very much processor dependant. Some have true/false flags in hardware. Some have particular instructions that takes less size but only affect a portion of the used hardware register etc. 68k and several other processors has instructions like ST/Set true, clr where only a byte of the register is set and the opcode is particularly small compared to move and whatnot.

author: Picuino
author_rank: Super Contributor
timestamp: May 10, 2020, 01:35:20 pm
content: Many times there is no real option to choose the language to use.With microcontrollers and IOT world, C language is the only serious option to choose.In other areas there is no better solution neither than C.Therefore in many cases choosing the C language is a solution without many really good or serious alternatives.Of course this is not the case in the world of web creation, for making GUIs or many other examples.

author: bd139
author_rank: Super Contributor
timestamp: May 10, 2020, 01:41:56 pm
content: This just popped into my head. An old Unix koan from ESR. Noted for the C comment...A Unix zealot, having heard that Master Foo was wise in the Great Way, came to him for instruction. Master Foo said to him:“When the Patriarch Thompson invented Unix, he did not understand it. Then he gained in understanding, and no longer invented it.”“When the Patriarch McIlroy invented the pipe, he knew that it would transform software, but did not know that it would transform mind.”“When the Patriarch Ritchie invented C, he condemned programmers to a thousand hells of buffer overruns, heap corruption, and stale-pointer bugs.”“Truly, the Patriarchs were blind and foolish!”The zealot was greatly angered by the Master's words.“These enlightened ones,” he protested, “gave us the Great Way of Unix. Surely, if we mock them we will lose merit and be reborn as beasts or MCSEs.”“Is your code ever completely without stain and flaw?” demanded Master Foo.“No,” admitted the zealot, “no man's is.”“The wisdom of the Patriarchs” said Master Foo, “was that they knew they were fools.”Upon hearing this, the zealot was enlightened.

author: madires
author_rank: Super Contributor
timestamp: May 10, 2020, 02:07:49 pm
content: TIOBE Index for May 2020May Headline: Programming language C is back in the number one spothttps://www.tiobe.com/tiobe-index/My take on those silly programming language wars is that you should use what suits you best and what gets the job done. Of course, when you're working in a team or have to maintain some legacy software you don't have the luxury of choosing the language. I don't mind to learn another one. I've stopped counting a long time ago.

author: Karel
author_rank: Super Contributor
timestamp: May 10, 2020, 02:13:02 pm
content: http://harmful.cat-v.org/software/c++/linus

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 10, 2020, 02:18:27 pm
content: Quote from: Nominal Animal on May 10, 2020, 12:47:50 pmUh huh. As was discussed in other threads, C enums are just loose collections of integer constants, and the language doesn't have any provision for type-checking enums (beyond the values being integers).Just the way it is. Yes it sucks a little.And yes C99 added a true boolean type (_Bool, or bool if you include stdbool.h) which is guaranteed to hold only 1 or 0 (unless probably you mess with it using pointers and casts).I've never been really bothered with older C versions not having a true boolean type. All you had to know was that 0 was considered false as a condition, and anything else, true. That worked well enough. There was no point directly testing a "boolean" (I'd say rather a "condition") against a value anyway (something I have already seen from some developers - ugly!) This would make no sense. One way it could make sense would be if you used a bool value not as a condition but as an integer value in some calculation. Something I've seen, but I find this wrong in many ways, and obfuscating. It doesn't even make sense from a strict type point of view IMO.But likewise, I've once seen someone write stuff like: 'if (someboolean == true)'. Seriously buddy? How much more fucked up can it get? Not only would that lead to bugs in pure C (at least before C99 and/or not using the 'bool' type), but it was stupidly redundant anyway. A condition is just a condition. 'if (someboolean)' is correct and perfectly understandable. The above could get as recursive as possible while retaining the same absurdity: 'if ((someboolean == true) == true)'... What's the difference?Ahah. I guess you can never really get into someone else's tortuous mind anyway.OTOH, I make a strict distinction between the above (manipulating values that you consider as conditions, or booleans) and using any other kind of values as conditions. For instance, for testing pointers against NULL, I don't like 'if (pointer)' much, and will favor 'if (pointer != NULL)'. Some may not see a difference. There is. 'pointer' is just a pointer, it's not meant to hold a condition. In C, there is no difference language-wise, but from a coding style POV, I find this inconsistent. To elaborate with this example and link it to the above, if OTOH you used an intermediate variable as a "boolean" holding the same condition, that could be:pointernotnull = pointer != NULL;if (pointernotnull ) ...Hope I made my point clear.(That was just a slightly off-topic rant/precision.)

author: nctnico
author_rank: Super Contributor
timestamp: May 10, 2020, 02:25:20 pm
content: Quote from: SiliconWizard on May 10, 2020, 02:18:27 pmI strongly disagree on this. IMHO a comparison should always show what is being compared; it will make the code unambiguous to someone not well versed in a language. This is especially true for C because only 0 is false and anything else is true. For that reason my API functions always return -1 (failure) or 1 (success).

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 10, 2020, 02:44:44 pm
content: More importantly, even though C# and .NET are an f***'d up disaster, I somehow managed to add CSV file logging to my data acquisition app. Less than an hour. Got lucky I guess.

author: madires
author_rank: Super Contributor
timestamp: May 10, 2020, 02:47:37 pm
content: Quote from: coppice on May 10, 2020, 11:45:10 amThe developer of the compiler has chosen whatever the CPU processes with the least amount of clock cycles. If the CPU needs the same number of clock cycles for an 8 bit, 16 bit, 32 bit or 64 bit value then roll a dice or think about memory usage and management.

author: Siwastaja
author_rank: Super Contributor
timestamp: May 10, 2020, 02:49:03 pm
content: IMHO,if(dog_exists) // makes sense to a normal human beingif(dog_exists == true) // sounds like a tax bureacraut wrote thisif(dog_does_not_exist == false) // argh!If you find adding excess "== true" or "== false" tests for bools makes the code more readable, that's a sign that your variable naming sucks or the variable logic is upside-down.Or, that you are just stuck in this practice often seen by novices. Even experienced people have their blind spots.

author: nctnico
author_rank: Super Contributor
timestamp: May 10, 2020, 02:57:34 pm
content: Quote from: Siwastaja on May 10, 2020, 02:49:03 pmThe problem is that in C 'if' can be used with any type. So in order to fully understand what 'if(dog_exists)' does exactly you need to look up what type dog_exists is first. If you write 'if(dog_exists == true)' then it is clear that dog_exists is a boolean immediately. That makes reading & modifying the code a whole lot easier. The easier code is to read & understand the easier it is to hand over to someone else (including a novice). I'm not a fan of elitist code styles which basically say 'screw you novice, spend another year in kindergarten'. Then you are wasting people's salary because they are not as productive as they can be even though they may not grasp every tiny detail of the C syntax.

author: chriva
author_rank: Regular Contributor
timestamp: May 10, 2020, 03:04:44 pm
content: Finding new ways to abstract things that in effect are the same thing is making the code harder to read if anything.

author: madires
author_rank: Super Contributor
timestamp: May 10, 2020, 03:07:12 pm
content: Quote from: SiliconWizard on May 10, 2020, 02:18:27 pmThe C way of using an unsigned integer as boolean variable is very similar to the assembler CPU commands. From a software developer's point of view of a clean and perfect language it seems bad and ugly, but when you consider assembler it's actually beautiful. You can use it as a boolean flag and a counter as the same time. More efficient than using two variables, one boolean flag and a counter.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 10, 2020, 03:17:28 pm
content: Quote from: madires on May 10, 2020, 03:07:12 pmJust a detail - it doesn't need to be unsigned. It's again just 0 or not 0. And sure the idea was to make efficient use of underlying CPUs.But it's not particularly ugly. Some people may find it quirky, but that's largely questionable. In my eyes, "0" or "not 0" are 2 distinct states that are perfectly valid for holding a boolean value.People insisting on it needing to strictly have only two different values (like 0 or 1) are just biased seeing a boolean as a binary digit. 0 or 1 have no particular meaning per se. All a boolean needs to hold IMHO are two different and exclusive states. The rest is mind wanking IMO. YMMV.

author: nctnico
author_rank: Super Contributor
timestamp: May 10, 2020, 03:28:14 pm
content: Agreed. For all we know 'true' may be defined as 42

author: IDEngineer
author_rank: Super Contributor
timestamp: May 10, 2020, 03:43:30 pm
content: With respect to the use of booleans in C....I'm a huge proponent of the style "if (boolean)" or "if (!boolean)" for several reasons. First, IMHO it's concise and clearly conveys what is being evaluated. YMMV.Second, long ago I was analyzing the Assembly language output from a compiler and found that it generated different code depending upon how if statements were written. If I wrote "if (variable)" or "if (!variable)", it generated ultra-tight code by clearing the Z flag, pulling the variable into a register, OR'ing the register with itself which (might) set the Z flag, and then testing the state of the Z flag. But if I wrote "if (variable == true)" the compileractually performed a comparison with an immediate valueequal to "true" (or whatever value was specified), generating signficantly more Assembly instructions for the same net result.Having learned this, I also started testing non-boolean variables for zero with "if (!variable)" which yielded smaller, faster code as described above. This was especially nice (and low cost) when checking for null pointers.I lived in this blissful state for a very long time. THEN... my code started failing in weird ways on some project. So I dug into the Assembly generated by THAT compiler, and to my horror discovered that it did not generate proper Assembly unless a value was specified for the comparison! That is, "if (boolean)" and "if (!boolean)" generated BROKEN CODE but "if (boolean == true)" and "if (boolean == false)" did not. The != versions also generated proper code. The compiler simply demanded two explicit values to compare. I could not believe it, but I was trapped by the authors of that compiler. Once I rewrote my code to always provide a value against which to compare, it started working perfectly.This is a long winded way of saying that despite agreeing it looks terrible and should not be necessary, I now write "if (boolean == true)" even though strictly speaking it is not necessary. I do so because that source code will always work with every compiler I've ever encountered, whereas I know there's a team out there somewhere that wrote a compiler where that would silently (e.g. without reporting an error, nor even a warning) generate broken code without the immediate value. Supporting two values with a comparison operator between them is so fundamental to the language that we can safely presume it will always work, so for reliability I now write that way. And I urge the universe to inflict terrible harm on that compiler team every time I do so.

author: IDEngineer
author_rank: Super Contributor
timestamp: May 10, 2020, 03:53:19 pm
content: And despite how I typed my examples above (which I did for clarity), I actually always type conditionals which contain a fixed value like this:if (true == boolean)if (5.3 == fVar)Why? Because if I accidentally leave out one of the equal signs, the compiler will conveniently report it as an error. Typed the "traditional" way, the compiler will simply (and silently) execute the assignment and then resolve the conditional based on the zero vs. nonzero (false vs. true) numeric value of the assignment. This works in Java and other languages too. It "reads" a bit weird but is perfectly logical and lets the compiler check my work in an extra way for free.I teach others to type this way and (especially for newbies who haven't internalized the whole "double equal sign" thing) it catches a LOT of mistakes.

author: Siwastaja
author_rank: Super Contributor
timestamp: May 10, 2020, 04:53:38 pm
content: Quote from: nctnico on May 10, 2020, 02:57:34 pmIMHO, you should have a naming convention (explicit, or more subtle) so that youknowthe types, because the problem isn't limited to the if clause and comparisons.Once you fix that, you get rid of needing the comparisons to other values just to demonstrate the type!if(isDog) // any isSomething is boolprintf("%d", numDogs); // num anything isintor explicitly,if(b_dog_exists)printf("%d", i32_n_dogs);whatever your coding style or naming convention is, I don't think writing excess comparisons just to "demonstrate" the type is a good solution. This information should be available in some other way.

author: Siwastaja
author_rank: Super Contributor
timestamp: May 10, 2020, 04:58:05 pm
content: Quote from: SiliconWizard on May 10, 2020, 03:17:28 pmI agree, there's nothing ugly. We don't need to hidealllow-level details in near-neurotic way; only abstract things when there is a clear benefit and good reason. Just use a simple comment to document dual-use as a flag and counter (I do that all the time, not only for performance, but becauseit makes sense.)Similarly, I accept, and even prefer, to have my plumbing visible. It does not distract me, it has a purpose, it's needed, I use it, and when visible, I can see if it leaks. Some people prefer to hide plumbing inside concrete though because it's "ugly". Then replacing it is a huge project (it's known here as a personal tragedy, called "plumbing renovation", requiring evacuation for half a year and almost doubling the estate price.)

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 10, 2020, 05:00:59 pm
content: Quote from: IDEngineer on May 10, 2020, 03:53:19 pmYes, I don't like this style, but it's a pretty common one to avoid errors.Note that many decent/recent compilers will issue a warning if you write 'if (a = 5)' (and you shouldn't ignore warnings!), and otherwise static analyzers will also spot that. But if you don't use any, then yes I agree.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 10, 2020, 05:03:50 pm
content: Quote from: Siwastaja on May 10, 2020, 04:58:05 pmAgreed, but I don't quite agree with the low-level nature of this particular point.If anything, I consider the two states of original C "booleans", zero and non-zero, to be a little more abstract than just 0 and 1. Weirdly enough, many people seem to have a problem with that. Guess we're all different.

author: IanB
author_rank: Super Contributor
timestamp: May 10, 2020, 05:08:43 pm
content: Quote from: Siwastaja on May 10, 2020, 09:45:10 amApparently I failed in my communication somehow. I don't know why everyone found it so objectionable.I did have a point:Quote from: Cerebus on May 10, 2020, 12:38:34 amI was just checking this assertion, since later C standards did add a boolean type, and it doesn't in fact complain if you assign a string to it.Instead of saying "oh, that's interesting" everyone started beating up on me. So OK, it's not important, nobody is bothered and it's not worth arguing about.

author: Tomorokoshi
author_rank: Super Contributor
timestamp: May 10, 2020, 05:51:30 pm
content: For levity's sake this seems appropriate here:https://xkcd.com/386/Anyway, sure, C has its +'s, ++'s, -'s, and --'s. For practical reasons there are not a lot of alternatives for embedded work, a lot of code base is available, etc. I can't afford 100 MB to support "Hello World" with Java or other wanna-be bloat.Regarding the curiosity from the link a few pages pack regarding the apparent rise in popularity of C and Python along with the drop in popularity of Java, it makes perfect sense given the benefits and synergies pointed out by others of using C and Python together."Using the right tool for the right job" requires a set of value judgements that don't fall nicely into macroeconomic categories. Many of those are bypassed for non-technical reasons, having to do with the reality and practicality of project cost and scheduling. With a lot of code base and engineering talent invested in C, choosing some other language on technical merits alone will rarely make it through until a lot of off-budget investment is made, such as through independent projects or some game-changing set of tools.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 10, 2020, 06:11:49 pm
content: IanB, between you and me...word to the wise...Fanboys. This place is crawling with 'em. Meters, scopes, power supplies, you name it. And even software. Go no, right?? Yeah it's true. And who would'a thought there were even C fanboys??Anyway, it's a bit like going into a bar in Dallas while the Cowboys are playing in the Super Bowl, and shouting "Cowboys SUCK !!". They'll rip you a new one.So my recommendation: Just apologize, post shit like "C RULES !!!" and slowly back out and move on.And watch your back..........

author: bd139
author_rank: Super Contributor
timestamp: May 10, 2020, 06:16:36 pm
content: It was quite objective and interesting until a couple of members crawled in...

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 10, 2020, 06:30:45 pm
content: Quote from: bd139 on May 10, 2020, 06:16:36 pmI apologize. C RULES !!!!

author: bd139
author_rank: Super Contributor
timestamp: May 10, 2020, 06:32:37 pm
content: Common Lisp rules

author: Karel
author_rank: Super Contributor
timestamp: May 10, 2020, 06:40:08 pm
content: What about Borland Delphi?

author: janoc
author_rank: Super Contributor
timestamp: May 10, 2020, 06:44:27 pm
content: FYI:C is actually rising in popularity - mostly thanks to embedded development.https://www.tiobe.com/tiobe-index/Last month growth of C is almost 3% and it has landed back in the 1st spot, overtaking Java.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 10, 2020, 06:50:40 pm
content: @janoc: yes, I think this link has been posted a number of times already in this thread. As I said, to be taken with a pinch of salt.Otherwise, and especially for engrguy42: I don't know how surprising that would be that people mostly focus on talking about C in this thread. Overall, the posts looked pretty reasonable to me. And you can't really complain about people being on topic, since this is the very topic. It was not about "what programming language do you guys use these days?" (which is kind of a popular topic and has already been asked numerous times I think.)As Tomorokoshi posted, some people seem to prefer trying to prove others wrong than staying on topic. Oh well.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 10, 2020, 07:01:10 pm
content: Quote from: SiliconWizard on May 10, 2020, 06:50:40 pmOf course they do...

author: Wolfgang
author_rank: Super Contributor
timestamp: May 10, 2020, 07:21:56 pm
content: Quote from: engrguy42 on May 10, 2020, 07:01:10 pmIMHO, religious computer language discussions are a complete waste of time -better spent to solve a real world problem.

author: nctnico
author_rank: Super Contributor
timestamp: May 10, 2020, 07:32:59 pm
content: Quote from: Karel on May 10, 2020, 06:40:08 pmFor that we would need a vomit emoticon. I had the misfortune to inherit a larger project once. What a mess. Pascal with C-isms bolted on. I have used Borland Pascal for a while an dabbled in Delphi as well but quickly found out that Pascal is not really suitable for any real programming work where you need to restructure a program half way sometimes. Having 4 or 5 different string types also doesn't help. If you need to resort to C-isms anyway then better use the real deal (C or C++)... If you don't want to use C/C++ then look a C#, Java or Python.

author: coppice
author_rank: Super Contributor
timestamp: May 10, 2020, 09:56:24 pm
content: Quote from: bd139 on May 10, 2020, 06:32:37 pmRubbish. Snobol rules.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 10, 2020, 09:57:15 pm
content: PL/M rules.

author: Wolfgang
author_rank: Super Contributor
timestamp: May 10, 2020, 10:04:55 pm
content: Its endless. With all the time and effort wasted here in this forum you could have coded a graphics package in COBOL. Just as futile, but at least *something* works in the end

author: coppice
author_rank: Super Contributor
timestamp: May 10, 2020, 10:14:31 pm
content: Quote from: SiliconWizard on May 10, 2020, 09:57:15 pmPL/M, MPL, and a few other derivatives of PL/1 were created by microprocessors vendors in the mid to late 1970s, to support bare metal programming for their products. If C had more presence at that time these things would never have existed.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 10, 2020, 10:15:32 pm
content: Quote from: coppice on May 10, 2020, 10:14:31 pm

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 10, 2020, 11:00:19 pm
content: Quote from: Wolfgang on May 10, 2020, 10:04:55 pmYeah, no kidding...the horse died like 10 pages ago.Well I spent some time today buttoning up my data acquisition app by making a custom icon.Oh, and my app has some booleans, and in spite of the incredible complexity surrounding booleansthey worked fine. I mean, like, what's to discuss? They're, like, true...or...false."if (plotIt && !plotStop)"On second thought, I'm sure that will start even more boolean muscle flexing but anyway...

author: bd139
author_rank: Super Contributor
timestamp: May 10, 2020, 11:03:35 pm
content: Now write an installer in WIX and sign it with an EV code sign cert

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 10, 2020, 11:08:07 pm
content: Quote from: bd139 on May 10, 2020, 11:03:35 pmWhy?

author: olkipukki
author_rank: Frequent Contributor
timestamp: May 10, 2020, 11:20:57 pm
content: Nobody mentioned JavaScript yet?GUI in C#? Come on, grown up kids do everything in Electron and React Native these days

author: intmpe
author_rank: Contributor
timestamp: May 11, 2020, 12:45:58 am
content: Quote from: Cerebus on May 10, 2020, 08:50:50 amWell, don't make dumb shit remarks about R&D vis a vis Universities if you've never been in a both a real industrial research campus doing hardcore research and a University - because if you were around in 90's like I was then you know what you said was garbage. You aren't the only one who has been around the block. I'd go toe to toe with any of the wannabees I've seen on here so far. Looks like a hobbyist playground.BTW UKP 6M is piss money. 2 years ago I stood one up for UKP12M and it failed because the grand poo bah couldn't get his head out of his arse. Unless you are the one pulling the strings - being in the c-suite means you are probably just someone they know wont stuff up their end. But usually in every show I've been in - its been a one man show - and sunk by one man. Making it requires sustained success over a long period of time in order to extract profits - and a hundred other success factors play into it to make sure you don't go under 2 years later. There are few who can do it and any of the ones that I know who have done it aren't really true electronic businesses in the old sense - there is some other key factor. If it happened in the 90's they probably buried it long ago. Meanwhile the local McDonanlds franchise has pulled in 20 or 30MUKP in the meantime.I actually agree with you about business school but they do get a few things right. Generally they are useless as they all want their theories taken seriously in isolation of the real world. However this doesn't mean the long term studies of certain business environments does not have some merit. Druker for example hated electronics - thought it was over hyped and basically said more people made fortunes running laundromats than ever made it in electronics. By made it - it means standing up a company and then being able to lift it to a stable place where eventually you either continue running it or you exit with a boot full of cash i.e. the local McDonald franchisee. Druker's observation of electronics was - he said they startup and in a year or two they are gone. Being able to do that is not successful management - that's called luck. Conning money out of investors i.e. the 12M UKP example above is what its mostly about - as Rivkin used to say most businesses are set up to con the investor. But then most investors are cunts who deserve to be parted with their money. Sorry- some experience talking.Edit: Just to add to that - electronics is transient - its easy to get an idea up and funded. Well not easy but not impossible. But the market changes quickly, and for the most part businesses can't change. They flop around trying things until they wasted all the cash they had. So after years of this crap I have only come up with one conclusion - get the company up and running and when you see the rain clouds - liquidate it and take the money or if their is a willing buyer sell it - take the money and work on the new thing. Don't stick around - Ive never seen a business come back from a changing environment. Hell once you have the money buy a McDonalds franchise. Makes a lot more sense than attempting to compete with so low cost operation that starts on a dime somewhere and eats your lunch.

author: IDEngineer
author_rank: Super Contributor
timestamp: May 11, 2020, 03:02:31 am
content: Quote from: engrguy42 on May 10, 2020, 11:00:19 pmThe title asks two questions. My earlier post addressed the first ("How many people code in C these days?"), the answer is it has retaken first place in a popular poll.As to the second ("Why?"), there's been some postulating and pontificating herein with a few solid reasons scattered here and there.Most else in this thread has been the usual back-and-forth. But a few of us actually did attempt to address the original questions....

author: Berni
author_rank: Super Contributor
timestamp: May 11, 2020, 05:58:24 am
content: Quote from: olkipukki on May 10, 2020, 11:20:57 pmI did mention JavaScript when talking about how modern JIT in things like C# can make managed code run pretty much almost as fast as C++. Where JavaScript is no exception, thanks to the popularity of browsers it got some impressively quick JIT thrown at it.JS is not just for browsers anymore. For example the popular chat client Discord has its PC client app written in JS with a bunch of frameworks stacked on top as its usually the case for JS. Its sneakily under the hood of a lot of things. Personally im not a fan of JS and most of this web stuff, but i have to admit it is a rather powerful and performant language these days.I do have my share of gripes with C# too, but the convenience of "it just works" in VisualStudio makes it up for me. I don't want to muck about with setting up some fancy dev enviorment for the usual quick tool apps in throw together in it. It literally takes me less than a minute to start a new project, create a GUI app with a few buttons that does something simple and turn it into a self contained exe. I can even do this even after not touching C# for >1 year because i don't need to memorize any documentation. Its a few obvious clicks to create a project and plonk down buttons and once i get to writing code the VS intelisense autocomplete holds my hand all the time, if i do need more info what a function does i just hit F1 while the cursor is on it and bam browser pops up with documentation including a code example. There are plenty of ready to go libraries to read/write most popular file formats, graphics, communicate on the network, do OS stuff...etc I'm lazy and C# in VisualStudio caters to my laziness very well.For doing C i would either get the already setup branded Eclipse flavor for that MCU (Cause it again "just works") or use Sublime text as a editor and build it in a console.For Python i again go the lazy "it just works" route and install JetBrains PyCharm. Again few clicks and i have a running project with a decent code editor, compile/run, debug etc...

author: Karel
author_rank: Super Contributor
timestamp: May 11, 2020, 09:03:53 am
content: Quote from: IDEngineer on May 11, 2020, 03:02:31 amMy impression so far for the answer to "why?" is a combination of (in random order):- simplicity- availability- stability- portability- reliabilityIt just works and gets the job done without any bullshit.

author: 0db
author_rank: Frequent Contributor
timestamp: May 11, 2020, 09:35:55 am
content: Quote from: nctnico on May 10, 2020, 02:25:20 pm+1 -> true00 -> not boolean-1 -> falsenice trick!

author: madires
author_rank: Super Contributor
timestamp: May 11, 2020, 09:47:50 am
content: Quote from: Karel on May 11, 2020, 09:03:53 am- size of executable- speed of executable

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 11, 2020, 10:25:26 am
content: Quote from: intmpe on May 11, 2020, 12:45:58 amUh oh....they're going toe to toe...https://media.giphy.com/media/pIwSSY4FUvs0E/giphy.gifEDIT: Hey wait a minute...how come my gif doesn't show, only a link WTF? Anyway, we REALLY need a Tim Taylor/Home Improvement automatic grunt inserter gif thingy here.

author: Siwastaja
author_rank: Super Contributor
timestamp: May 11, 2020, 10:37:35 am
content: engrguy42, you are getting a bit boring. Repeating the joke gets old.I see you have a mental issue seeing people disagree with each other, but if you have nothing to contribute, you can also stop repeatedly trying to be "funny" which you are failing at. Let thekidsadultsfightdiscuss.If the awkwardness is getting at you, you are free to ignore the thread.Thank you.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 11, 2020, 10:40:37 am
content: Quote from: Siwastaja on May 11, 2020, 10:37:35 amI'm sorry you're bored. But, honestly, I couldn't care less.

author: Siwastaja
author_rank: Super Contributor
timestamp: May 11, 2020, 10:40:50 am
content: - good-enough-ness despite all the issues- lack of anything else that demonstrably and actually works better in the real world cases where C is still used. (Wherever C is not the right tool, it has largely been replaced already, so where it remains, there usually are good reasons.)

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 11, 2020, 11:21:31 am
content: Considering the various ways success/error results have been passed from the callee to the caller in C, there are some that are "standard" in the sense of so common to not surprise anyone:Integer return value: 0 = Success, -1 = Error, with error code in a thread-local global variableThis is the interface used by most standard library functions, usingerrnofor the error code.Pointer return value: non-NULL = Success, NULL = Error, with error code in a thread-local global variableThis is also used by standard library functions, witherrnofor the error code.Integer return value: 0 = Success, nonzero = Error codeThis is the interface used by most POSIX thread functions (pthreads).Pointer return value: Small range of addresses reserved for errorsThis is used internally by the Linux kernel, but requires intimate knowledge of the virtual memory available to userspace processes (see ERR_PTR(), PTR_ERR(), IS_ERR(), and IS_ERR_OR_NULL() macros in thelinux kernel sourcesfor details). A small range of addresses at the top of the virtual memory is used to make the check a simple comparison (IS_ERR_VALUE()macro).In POSIX C, themmap()function returns a pointer to the mapped region, orMAP_FAILEDif an error occurs.Unrelated return value, often none: Final function parameter points to an integer result status variableThis is common in C bindings to Fortran libraries, like BLAS and LAPACK (very common linear algebra libraries still in use).Typically, the result status variable is 0 for success, and an error code otherwise.Each of these have their upsides and their downsides.Even the standard C library has an exception to this pattern:strtol(),strtoul(),strtoll(),strtoull(), andstrtod(). See the code snippet at the end of theman strtolman page to see the correct procedure. I personally wrap these inside aparse_type(src, base, to)function.The first case has lead to many programmers to use(result < 0)instead of(result == -1)to determine if an error occurs, but that is wrong if the function can return valid negative values (other than -1); or, on LP64 architectures, when the return type islong, but is stored in anint, and a larger than 232value happens to be truncated to 32-bit negative value. This yields a set of common bugs when porting "bad" C from ILP32 to LP64.The second case tends to trip programmers whenever encountering functions of the fourth type, including POSIX Cmmap().The fifth case looks "odd" in C, especially if the function does not return any value. Some interfaces allow passing NULL for the pointer to the status variable, some do not, so it tends to be a bit cumbersome.I personally prefer the third case, because it yields the following code pattern,Code:result = some_function_call(parameters);if (result) {an_error_occurred();}In cases where the error reason is uninteresting, it shortens toif (some_function_call(parameters)) an_error_occurred();which does take a bit of getting used to, but unfortunately, it also allows the riskyif (result = some_function_call(parameters)) an_error_occurred()pattern, which can easily trip up humans ("shouldn't that be == instead?").Because of the variance in error/failure condition reporting methods, many C programmers develop an emotional distrust of the return values. (The example of comparing< 0instead of== -1is a typical one. Also, I am not excluding myself here; I'm no better than anybody else in this.) As I mentioned above, this has lead to bugs, so it is not a good thing; it is not a defensive strategy, but an emotional cause of further bugs. Paranoia is useful only up to a limit.In some cases, it is even better todeliberatelychoose an odd error/failure reporting method (one not listed above, or one differing from the rest of the API), to ensure human programmers notice it and use it correctly; docstring comments just before the function are extremely useful for this.Technically, it does not matter. It is true that there may be C compilers that generate incorrect code for one of the schemes, but I would throw such a buggy compiler to a bonfire, instead of letting it indoctrinate me into not trusting my tools at all. Compiler bugs are exceedingly rare compared to human bugs; whatever error/failure method you do use really does not (should not!) matter to the compiler. Some of them may map better to the underlying hardware architecture, but since C does not expose the ALU status flags basically all current processors and microcontrollers have, that is already kind of a moot point. (That is, most HWcouldhave an ABI where one of the status flags, say Carry, is used to indicate an error/failure at return time, but current C would need to use some kind of a pseudo-variable or function kludge to expose it. Yet, it would be extremely efficient at the machine code level, if properly exposed.)Some see this as versatility, some as a failure, of C. For example, the standard method of reporting error/failure in Python is raising an exception; it is simple and straightforward.Why, then, would C need that versatility, instead of having just one simple way to pass errors like Python does?That answer, and the answer to the question posed in the initial message in this thread, is that we just have situations where that kind of versatility is useful, and sometimes necessary.(To repeat: they are necessary when implementing language bindings to other programming languages, and vice versa; consider the Fortran example above. I would not want to have to write those bindings in assembly; I much prefer writing them in C.)Is this message, and my previous message, just singing praise for C?Fuck no. I have tons of grievances against it, and tons more against the current direction of the C standards committee, so much so that I actually prefer C99 over C11. I haven't even bothered to read the text of C18 yet, and have not read anything about C2x thus far. Now that Microsoft is becoming saner with respect to FOSS, there could be an improvement coming, but standards folks move slowly, so I'm not holding my breath just yet.C is just a tool.It has its use cases, like low-level systems programming and interfacing to other programming languages, where it is a better fit than anything else we currently have; one reason being its ubiquitous availability, and the size of the existing codebase. In my previous post in this thread, I listed the reasons why replacing C with C++ can be problematic in this niche.Does that mean I think C++ has no use cases, then? No, of course not. I personally prefer using Python for user interfaces, because I find the ability of end users to modify the UI without recompiling or setting up any kind of a development environment to be worth it. User interfaces by their very nature are event driven, and object-oriented languages are best suited for those; so, if I was writing a proprietary GUI application where UI in Python would be unacceptable, C++ would be my choice; and then even the low-level stuff would naturally be written in C++, not C, because using C would only increase the complexity and maintenance cost.(As far as I know, GTK+ is actually the only native C GUI toolkit currently in use. I do like it, but considering an entire software project with paid programmers and such, C++ and Qt or FLTK is just a better, more reasonable choice.)What about Go, Rust, Julia, et cetera? They have all been touted as being better at what C is used for. Leaving marketing-speak and buzzwords alone, I want to see actual low-level libraries (plural! Not just a special case chosen for its particular quirks!) implemented and performing better, done by people who know these languages better, than to try and switch myself just because of the toutedpotential. History shows these "new" languages tend to be domain-specific, and quite high-level, and not at all suited for the low-level systems programming tasks I and many others use C for.I really wonder how many of those who believe C++ does everything C does and better, are actually Windows-only developers? After all, Microsoft no longer has a C compiler at all, only a C++ compiler that supports compiling C too, and unless you have practical experience on other platforms, that sort of thing must affect ones experience and opinions. Nothing wrong in that perse (), but it is extrapolating assumptions from a small region to a larger whole, which rarely matches reality.

author: Karel
author_rank: Super Contributor
timestamp: May 11, 2020, 12:14:30 pm
content: Quote from: Nominal Animal on May 11, 2020, 11:21:31 amCan you give some examples of what you don't like about C11?

author: coppice
author_rank: Super Contributor
timestamp: May 11, 2020, 12:37:47 pm
content: Quote from: Nominal Animal on May 11, 2020, 11:21:31 amHistory shows that all computer languages have been domain specific, and that very often the developers were completely unaware of this. You only have to look at early stuff pushing C++. It touted the generality of its OOP features, yet always showed examples in one of the few areas where is really excels.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 11, 2020, 12:39:42 pm
content: Quote from: Karel on May 11, 2020, 12:14:30 pmAlso curious.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 11, 2020, 01:44:30 pm
content: Quote from: IDEngineer on May 10, 2020, 03:43:30 pmI have personally never run into such a compiler bug. That would look like a bug on a *very* basic C feature, and said compiler should probably have never been trusted for anything else. But I know sometimes you just don't have a choice. (One bug I do remember from an old C compiler - IIRC it was cc on some old Solaris system - was an operator precedence bug. Writing something like 'if (a == b && c == d)' would not yield the proper condition, and you had to use parentheses to make it correct: 'if ((a == b) && (c == d))'. And I did grow an habit of always putting parentheses like this, even to this day. I also find it more readable. So I can relate.)I still want to draw people's attention to the dangers of comparing C "booleans" with a constant.As I said already, C considers 0 to be false as a condition, and non-0 to be true.So 'if (boolean == false)' (assuming 'false' is defined as 0) is indeed guaranteed to always be correct and equivalent to 'if (! boolean)'.OTOH, 'if (boolean == true)' is a terrible potential mess, since a *true* condition in C is not guaranteed to have any specific value (at least before C99), so depending on how you manipulate your "booleans", that kind of test may utterly fail. And it's not just theoretical: I've seen this done in existing C code and it introduced a major bug.Sure if you always assign your "booleans" with constants and nothing else, that should be OK. (But still pretty clumsy IMHO.)But if you assign some of your booleans with conditions, such as: 'boolean = a != b' (which is perfectly valid, and works in most programming languages actually), then you have a problem. Before C99, such a condition was not guaranteed to have a 0 or 1 value exclusively. And I've SEEN that not being the case with real compilers. (One low-level explanation would be that such an assignment would simply be implemented as a subtract operation in assembly.)So, beyond the style question, I think you should be very careful with this.

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 11, 2020, 02:47:30 pm
content: Why I prefer C99 (pern1256.pdf) versus C11 (pern1570.pdf)?Instead of bringing portable, widely-implemented features likegetline(), the standards committee was stuffed with Microsoft stooges who instead of furthering the C programming language, furthered the schemes of Microsoft by introducing the entirely unneeded Annex K. In other words, instead of getline(), you now have the "safe" fgets_s() instead.None of the wide-character internationalization support got any enhancements, either. They are not needed, after all, because Microsoft does not actually support locales (without proprietary extensions) anyway.(I was really hoping forgetline()andgetwline()to get standardized, because those two alone, taught to newbies, would remove a whole slew of typical bugs and inane limitations made by new C programmers. As it is, almostnobodylocalizes their C programs anymore; the standards committee has made it clear who commands it, and what direction it will be dictated in. A big reason is that standard code thatis supposed to workeven on Windows, doesn't, when the Windows' user locale uses UTF-8. Simply put, even after stuffing the C standards committee with people on their payrolls, they couldn't tweak the standard enough so that their own limpy implementation actually follows the standard.)The immensely usefuliconv_open()/iconv()/iconv_close()interface from POSIX did not get standardized, because Microsoft didn't want to implement it. To use it in Windows, one can install thelibiconvlibrary to get the support; basically all other desktop and server operating systems already incorporate it into their C library. But because Microsoft doesn't, it won't get into the C standard.Instead of standardizing theatomic operationsimplemented by GCC, Intel Compiler Collection, and a host of other compilers (but apparently not Microsoft Visual C++, which is after all more important and equal than anything else) – noting that they were the second generation of such ops, the first being__sync built-ins, that AFAICR were originated in ICC, not GCC –, they went with their<stdatomic.h>approach, which may or may not provide some features (it is up to the implementation; although you can check it via the__STDC_NO_ATOMICS__preprocessor macro), because that is the easiest way to implement minimal atomics support for a C++ compiler.In C11, variable-length array support became optional, because one vendor's C++ compiler has issues with those.Instead of leveraging existing POSIX threads with decades of C use, the committee went with a new "standard thread" support<threads.h>, whose actual compiler and OS support is unknown and iffy at best.Instead of utilizing experience with POSIX clock_gettime() facilities, they farted out an timespec_get() whose support is, well, purely a guess. If you have ever written a benchmark or test program that uses both CLOCK_REALTIME and CLOCK_MONOTONIC clocks, you can immediately see why the timespec_get() interface really does not cut it.Really, if we look at C11, the really good things it provided was the_Generic()selection expression and the_Thread_localstorage class specifier!Up to C99, the C standards committee had taken already implemented things with user experience finding them useful, and standardized them.With C11, that changed. Microsoft had decided to use it for the same purpose it standardized OOXML: to eliminate the need of having to compete with actual C implementations, and to ensure their own single-architecture C++ compiler implementation would suffice. Simply put, they threw the C standard under the bus, because they had the money, and they thought it would help their business.Today, if one wants to write portable C code, Windows environment is right out. Even their locale support and terminal UTF-8 input/output won't work without using Microsoft-only proprietary extensions. You will need to usepredefined compiler macrosto write Windows-specific code selected via preprocessor directives at compile time, if you do anything more complicated than a "Hello, world!" program. I'm sure Windows-only developers find this perfectly acceptable, but me, I do not want to be slaved to a single vendor. If a tool tries to restrict the portability of my code (like ICC did and does at runtime to code running under AMD processors), that tool goes out the window.So, for portability and functionality, POSIX C (IEEE Std 1003.1-2008) and C99 is still the best bet. Not perfect by any means, but the best fit, for now. C11 and C18 could have continued the path that C99 started from C89, but instead, basically twisted the C standard into furthering the goals of a single vendor. As I understand it, C18 doesn't even add anything to C11 anymore, and is simply a collection of errata (because the day Microsoft gets something right the first time, is the day hell freezes over).Okay, why the vitriol against Microsoft? It's not, really; it just happens to be the vendor that did this to the C standards committee,which allowed it to happen. If it had been Intel or Pathscale that did it (AFAIK IBM don't have their own proprietary C compiler anymore), I'd be equally disgusted with them. I'm angry at the entity that did this to the C standard development process. Microsoft today is, I believe, quite different as a company, but standards development stuff moves slowly, and it may be impossible to undo the damage done. There may not be sufficient interest to even try.There is still hope that POSIX C continues to develop, although it remains to be seen. One can read IEEE Std 1003.1-2017 onlinehere, and the list of C functions and interfaces ishere.Please do realize that I am looking at this as someone who really appreciates good tools, and gets immensely disgusted when someone fucks up the future of an existing tool. I feel the same way when a physical tool manufacturer sells their brand to a low-cost manufacturer, who exploits the brand for increasing short term profits. This can happen even during the lifetime of a product – sadly common with computer electronics, actually, except that none of the manufacturers have a particularly good reputation anymore.I don't care if it is C, or something else; my attitude depends only on it as a tool for solving problems, or implementing other tools. If you feel that everything you do is already dependent on Microsoft – or some other single vendor, like IBM, who now own Red Hat and have immense (and not altogether positive, in my opinion) say in the direction desktop and server Linux operating systems (i.e., those running the Linux kernel) will take in the future – then good for you; my reasons here will be irrelevant to you, and you can safely ignore them. But, if you are someone who has been in the software business for three decades, give or take, and don't want to be dependent on a single vendor because they will eventually fuck you over, you'll understand why the direction change between C99 and C11 has reduced my expectations from the C standards committee to zero.I guess I should apologize for the rant, but I don't wanna. Every point above is something that I have seen bite someone else besides myself. The locale support and getline()/getwline() facilities are a particular sore point, because even MS actually implements them in their base "C" library; but as it is, they are practically forgotten in current C software projects. That angers me, because it leads to bugs (buffer overruns) and inefficiencies or artificial limitations, that would have been so easy to avoid otherwise.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 11, 2020, 03:01:08 pm
content: OK, I get some of your points.Do you have actual proof MS influenced C11 in such a way? You seem very convinced of this.As to threads, the support is optional in C11 AFAIR, and from the little I experimented with this, GCC implements it as a thin layer above PThreads actually. But I'm expecting support in other compilers to lag. A lot.And yes, _Generic() is interesting. That's about the only thing I've ever used from C11 so far.

author: chriva
author_rank: Regular Contributor
timestamp: May 11, 2020, 03:14:51 pm
content: If someone has the penguin as a profile picture you just know they'll hate ms in every way possible and even blame them for stuff they didn't do. The open source world have benefited A LOT from big corps too. Start looking for google and Microsoft mentions in the codebase of many free and mature projects.It took Microsoft two tries. Shall we start on how many small tries it took independent developers to get things straight in their stuff?

author: Karel
author_rank: Super Contributor
timestamp: May 11, 2020, 03:26:35 pm
content: <cough cough>https://en.wikipedia.org/wiki/SCO%E2%80%93Linux_disputes#Microsoft_funding_of_SCO_controversyhttps://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish#Examples

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 11, 2020, 03:43:39 pm
content: Somebody mentioned open source. And Microsoft.I HATE open source. I HATE IT !!! As a user it's a royal freakin' PITA.There, I said it.There are like 600 distros of Linux out there?? Are you freakin' serious?? How is that good for users?? Trying to get support is freakin' impossible. "Oh no, that's Cinammon, not Ubuntu...can't help ya' ".And you go to GitHub and download some open source code from some guy, and spend most of your time reverse engineering and adding comments so you can understand the un-documented code he freakin' threw together (face it, coders HATE documenting shit). And you basically end up re-writing and documenting most of it.And then a couple years later he's gone and his code just grows weeds.Nothing's standard. And how can you rely on some code written by unnamed people? At least when a company is behind it they try to make it reasonably uniform and supported. And if you have a question about Windows or VS or whatever there's like 326,543 resources and libraries you can use.Nothing's perfect, but at least with MS there's some unformity for users. And someone real to put their name behind it. Of course, there's tons of stuff about MS to dislike, but at least they have ONE product and 3.73 gazillion people all over the world using it.Although apparently some guys love to spend unending hours playing with ridiculous command-line code. Hence Linux.Ok, I'm outta here. My apologies. And C RULES!!!

author: bd139
author_rank: Super Contributor
timestamp: May 11, 2020, 03:53:42 pm
content: I don't disagree with a lot of that to be honest. Some of the open source code is quite frankly fucking shit or maintained by comic book guy from the simpsons. You really have to tread carefully. One reason I'm sitting here on a windows 10 desktop and probably always will be.But at the same time the state of the .net ecosystem isn't much better. For a company that throws ~ £6m into MSFT every year, we can get fuck all support from them on their open source projects or closed stuff. I even had to shitpost on twitter and DM Scott Guthrie to get something sorted and they still haven't fucking fixed it 4 years later. And lets not forget partner support and Connect which has been a shit show for nigh on 20 years.The only truth is here:https://www.stilldrinking.org/programming-sucks

author: coppice
author_rank: Super Contributor
timestamp: May 11, 2020, 04:20:35 pm
content: Quote from: Nominal Animal on May 11, 2020, 02:47:30 pmAh, 2011 was a wonderful year. It was just about the first time you could freely code to the then 12 year old C99 standard and not get a mass of complaints about limited portability. I wonder which year we will be able to code to the C11 spec.?

author: bd139
author_rank: Super Contributor
timestamp: May 11, 2020, 04:28:49 pm
content: It gets worse. Don't look at the later standards. We have attributes now as wellStandardisation by committee is a sure way to fuck a specification.

author: Picuino
author_rank: Super Contributor
timestamp: May 11, 2020, 04:55:02 pm
content: Quote from: engrguy42 on May 11, 2020, 03:43:39 pmYou have some misconceptions about open software.UNIX V6 was open source, selled by Bell Labs with license (it was not free software, only open software)Red Hat Enterprise Linux is Free and open software, with a lot of technical support that you have to pay to Red Hat (you pay for the support and program tools, not for the OS)They all are different concepts.

author: Picuino
author_rank: Super Contributor
timestamp: May 11, 2020, 04:59:47 pm
content: Red Hat support:https://www.redhat.com/en/store/red-hat-enterprise-linux-server#?sku=RH00003Ubuntu support:https://buy.ubuntu.com/?cmp_id=6517438474&adg_id=100664098696&kwd=&device=c&gclid=CjwKCAjw7-P1BRA2EiwAXoPWA23MXrtToW9Ke14KKKU_CLXBNS07Udqvoc7C91iEChX7clb3AAiN8BoCngsQAvD_BwE

author: bd139
author_rank: Super Contributor
timestamp: May 11, 2020, 05:24:59 pm
content: Don’t buy Ubuntu support though. That’s worse value for money than Mac Pro wheels.

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 11, 2020, 05:26:37 pm
content: Quote from: SiliconWizard on May 11, 2020, 03:01:08 pmThey did add quite a few new members to the SC22 working group. Just four years after the ratification, committee memberssuggested removing Annex K. I was not, and have never been, a member of SC22, but I have read their public documents, and they openly acknowledge that these features were pushed by Microsoft. Remember, at that point, Microsoft was long on record for attesting that MS C++ will never implement C99.Do you require me to set up a link page with references to those public documents, or can you consider the core of the points, and just ignore my ranty bits about MS' involvement? The points, regardless of who pushed them, stand on their merits – after all, the entire C standards committee did ratify it all.Quote from: chriva on May 11, 2020, 03:14:51 pmAnd Swedes traditionally hate all us Finns, and call us "finnjävlar", "finnish fucks". So, your opinion of me personally is meaningless, and honestly, the fact that you even offered it, is disgusting.How about you leave my person out, and instead comment on the points I made? Those are what matter, not who I am.Tux is a mascot. I like doing Linux work, so I adopted a version of it for myself. For the first batch of Linux-based student laptops at the local Uni, I even created a bootsplash with a version of Tux rolling its eyes as the boot progressed. The purpose was the same: branding. Zealotry is not in the picture. I do recall hoping for a larger SSD in the early units, specifically for running Windows and other OSes in VMs, too. (The first model only had a 120 G Samsung SSD, which is a bit tight, considering Matlab, Mathematica, Maple, and other useful Sci software were also installable on these machines.)I also do proprietary work. I do not have any reason to ask why someone else would use Windows just because I don't – because it is just a tool. Whatever works, works. It becomes meaningful only when you add context, and external measurements to use in the comparison of different tools. Somewhere on this board is an early post of mine about the various licenses I suggest for different type projects. (No, it is not just a list of GPL variants.)Quote from: chriva on May 11, 2020, 03:14:51 pmYes, and a few companies have hurt it more than most. The "past Microsoft" has done immense harm, intentionally, as part of itsEmbrace, extend, and extinguishstrategy. It is important to remember that this was what Microsoft internally described the strategy, not some crazy Linux conspiracy theorists stamped on it.The "current Microsoft" is doing a lot of positive work in the open source arena. They are definitely no longer an antagonist, but a participant and contributor, and that is good.If we look at say Linux kernel developers, most of them get a salary from small and large tech companies. I find nothing odd in that, having run an IT company for a decade myself, doing a lot of proprietary server-side stuff among other things. (In another thread, I've mentioned how that broke me, because I'm much more of a tool guy, a janitor/developer/inventor, than a business guy.) I would not find it suspicious or odd, even if some of the Linux devs were on MS payroll. (In fact, that would be a very positive thing, considering certain patents and licensing.)However, MS's business strategy still requires barriers from developers to shift away from the Microsoft platform. WSL2 and its "almost-linux" environment is a particularly good example of this. It will be compatible enough so that software is trivial to port to WSL2, but anyone learning to develop in WSL2 will find all other POSIXy systems "more difficult", and will prefer WSL2 instead. Business-wise this is a sound strategy, and not "evil", but for someone who strongly believes in having vendors compete and not build walled gardens, it is not a good thing.I would like to emphasize that none of this has anything to do with open source or closed source; this is about portability and the quality and future of the C language as a tool. I've already explained how C fills a niche at the low system level that is hard to replace with anything else, and how C++ in particular is not suited for that. None of the new languages have shown practical examples of filling anything in that niche efficiently. My point was that C99 and POSIX is the best toolkit for that niche, and that C11 (and C18, as it was basically just a collection of erratas to C11) included a couple of good things, and a bunch of optional things that benefit a single vendor and not the users of the C programming language in general.So, if you disagree with me, I'd like to know exactly why. I mean, I am not interested in how you see my person, do please do stick to the subject, and not my person. I do freely admit that I really shouldn't blame Microsoft, because it was the entire multi-vendor C standards committee and working group SC22 that ratified the standard. But, the way they first publicly stated for years that they refuse to implement C99, and then suddenly participated in the C standards committee to develop C11 with features previously implemented only by MS C++ compiler, was .. worth ranting about to me.Then again, it was the "past Microsoft", with a totally different leadership and strategies than the company today.And then again, international standards are not software, and are basically impossible to fork, so the errors made then may be impossible to correct.I wish I was better writer in English, so I could have twisted the ranty parts into snide humor; that would have worked much better. But me fail English often.

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 11, 2020, 05:42:40 pm
content: Quote from: bd139 on May 11, 2020, 04:28:49 pmMake thatdesignby committee, and I'll agree so hard I'll hurt my neck.Before C11, the C standards committee didn't tell compiler writers how their compilers should work, they simply ratified an existing agreement. Additional features weren't pushed from the top down, but by developer users requiring certain features pushing them through their compiler vendors.If it matters any, I do have similar trust issues with GCC developers, as in the past they were keener on following the standard than in actually producing sensible-in-the-real-world behaviour. I am told they purged a lot of the slow stones out, and the development cycle seems much faster now that they switched to C++ (and that is a very good thing; it used to takeyearsfor bug fixes to filter through), but I haven't personally had any need to interact with them for a couple of years now.I also have a lot to complain about various Linux distributions and inanities in the Linux kernel, if anyone is willing to listen. I just ain't a fanboy. (Except maybe of good arguments – the interesting kind, not the angry kind – and solving problems, and that sort of stuff.)

author: IDEngineer
author_rank: Super Contributor
timestamp: May 11, 2020, 05:56:57 pm
content: Quote from: SiliconWizard on May 11, 2020, 01:44:30 pmI totally agree. And I am very careful. For example, I use only the boolean constants defined by the compiler, which reduces (but does not eliminate!) the risk.To be clear, I wasn't necessarily encouraging this style. It was just a response to the whole "boolean" subthread, which triggered this memory for me.Speaking of weird bugs: Years ago when I wrote device drivers and applications for Win32 on Windows, the holy and worshipful Visual Studio {grin} and its C/C++ compiler had a bug where #include statements in the very first line of a source file were ignored. I kid you not. It was 100% repeatable. I still leave line 1 of my source files blank as a result of THAT bug in my past. I bet I have more little subconscious quirks like that and the boolean== thing that I've acquired over the years and just don't think about, because I got burned at some point.

author: floobydust
author_rank: Super Contributor
timestamp: May 11, 2020, 08:00:09 pm
content: Reading Ritchie'sThe Development of the C Languagepaper (fromGNU C readings) helped me realize again - the language goes back to the early 1970's and is flawed and cannot fix things due to the legacy code out there it's always had to support. Live on PDP-7. I guess this is why you instead just come up with a new programming language.I've always hated the C language's lack of type-checking, which is intentional as the academics likepolymorphismwhich is a shit storm for embedded systems.I've always hated the language's lack of range-checking, where you index outside an array's bounds - this has countless bugs and punches to memory locations, enabled countless buffer-overrun virus invasions, to this day. I understand it's too much overhead to check during run-time like other languages, but it's a huge danger.Why compile:Code:char myArray;int myTrollLife;myArray = '?';myTrollLife = 1241248798798798719986720;I wish the C compilers worked a little harder and caught obvious noob mistakes, instead of catering to legacy or whatever it is that commands ignoring the obvious.I've always hated the language's silly freedom i.e.Code:if (flaps = true) {Boeing737Max(); // goodby all passengers and thanks for compiling.}Why allow assignments within a conditional expression? Just crazy.I'm not trying to be perfect here in my examples or my rant- but it's hilarious how dangerous the C language is, and it doesn't need to be.All the fanboys expect a perfect programmer but these three issues are huge, in my view and been around for decades as I remember.

author: bd139
author_rank: Super Contributor
timestamp: May 11, 2020, 08:15:08 pm
content: I tend to write conditionals "yoda style" as I have indeed shafted myself with that.if (true = flaps)...error: lvalue required as left operand of assignmentBut you know, testing is important too. So is static analysis (coverity). So is runtime analysis (valgrind etc). So is fuzzer (afl). And obviously unit and integration level testing otherwise how the hell do you know what you've written actually even works correctly from a semantic perspective.

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 11, 2020, 08:19:59 pm
content: Quote from: floobydust on May 11, 2020, 08:00:09 pmFWIW, I do agree. C really isn't that good, which is why I feel so strongly about its standardization committee; they're the ones that could help make it better.. but don't.It's just that there are some use cases where we don't have anything better than C yet.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: May 11, 2020, 08:22:23 pm
content: Quote from: Kjelt on May 03, 2020, 05:55:57 pmNot anything approaching 300Mlocs of code, but I did run into a similar situation at my last job. We had a series of products that used a C code base that was ~15 years old. This was embedded code running on 16-bit and 32-bit microcontrollers with limited FLASH and RAM and consisted of perhaps 125Klocs of C. The code was mature, and while by no means bug free, bugs reported by customers were rare. This code was written by senior engineers who were primarily EE types rather than CS types and they all had been at the company for >20 years.A few years ago the company was growing and hired a few more software people, mostly guys right out of university, but a few senior ones as well. These new guys collectively took one look at the existing code and promptly declared it broken, purely because it wasn't written in C++. They mounted a campaign to start moving everything to C++ while the old timers dug in their heels and resisted these efforts. I left the company right around the time the C++ crowd was starting to win some minor battles and the old timers were starting to get weary of the infighting and just letting the newcomers have their way.So what would the C++ advocates gain by rewriting this code base in C++? Very little. The existing code was working, was well-understood, had few real bugs, and had made the company hundreds of millions of dollars over the years. Rewriting it in C++ would have taken perhaps 10-20 man-years of effort and would have resulted in a code base with hundreds of bugs, many of which had been exterminated in the C code base years and years ago. It would have been harder to understand by many of the people who had to interact with it and maintain it (primarily customers and application engineers, who were typically not CS types and who were comfortable with C but not with C++).The industry is littered with the burned-out wrecks of companies who thought rewriting their bread and butter products in a newer, shinier language was a good idea.

author: bd139
author_rank: Super Contributor
timestamp: May 11, 2020, 08:26:22 pm
content: Quote from: Sal Ammoniac on May 11, 2020, 08:22:23 pmHey, my house was paid for by the hopes and dreams of those companies

author: madires
author_rank: Super Contributor
timestamp: May 11, 2020, 08:42:56 pm
content: With C you have to check things yourself and can't rely on a smart compiler doing everything for you. That means more work for you, but at the same time it allows you to do some things a protective language doesn't support. If you like to play safe there are mitigations like libraries with secure functions and other measures to protect against typical security issues like buffer overflows. But the security doesn't come for free, neither with a protective language nor with libs. Executables will be larger and slower. And you can't assume that a secure language won't have or create any security issues. For example, Web 2.0 is a security nightmare.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 11, 2020, 08:58:51 pm
content: I have a question for the professional coder dudes...I always assumed that in the commercial software world that the guys writing code would, maybe 80% of the time, be reaching into ready-to-go functions and libraries the company had built up over the years, and only 20% writing new stuff. "Hey, I need to do some I2C stuff...oh wait, we did that bunch of functions last year, I'll just copy it", or something like that. And I assumed that modular OO stuff and functions would be highly prized, to make libraries of often-used modules that had been used and tested to death.Is that not how it's done? Or is there a lot of re-inventing the wheel? I guess I assumed that companies would be all over the modular/OO design approach so they could have clean, reliable libraries they could copy from, and save gobs of development time.

author: nctnico
author_rank: Super Contributor
timestamp: May 11, 2020, 09:06:33 pm
content: Quote from: engrguy42 on May 11, 2020, 08:58:51 pmRe-using existing code happens everywhere. Some code I use in every microcontroller project dates back from over 2 decades ago. How much project specific code needs to be added depends on the project and whether or not there is existing code which does almost the same.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 11, 2020, 09:42:28 pm
content: Quote from: nctnico on May 11, 2020, 09:06:33 pmThanks. I guess I was focused a bit more on the OO aspects. Personally, I do a lot of engineering-type simulations of real world equipment, like equipment with control/feedback systems. And from that perspective, for me at least, having the concept of objects is wonderful.So for example, let's say you're modelling a solar inverter system with feedback controls. Or an automobile. Or an industrial motor. You can set up classes for the different components, then an overall class, and for example make a Model 463 solar generator system object. Then next month if you need to model a Model 823, you just use the same classes, but tweak the parameters. Same interfaces, same internals, different parameters. And you have these software modules simulating each component, so you can mix-n-match.I'm guessing that most of the folks here are more in the lower level, embedded hardware systems, so maybe that higher level approach isn't needed?

author: nctnico
author_rank: Super Contributor
timestamp: May 11, 2020, 09:54:43 pm
content: I have C++ classes which I re-use too. Usually a bit of tweaking or overloading of functions is needed to accomodate an existing class to a new project. Some of these classes also date back to over a decade ago.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 11, 2020, 09:58:47 pm
content: Quote from: nctnico on May 11, 2020, 09:54:43 pmAre you talking about the practices of a sizeable commercial software developer, or you personally? I'm mostly curious about how commercial developers view the whole OO approach, and if they're as excited about it as I assumed they are.

author: Picuino
author_rank: Super Contributor
timestamp: May 11, 2020, 09:59:22 pm
content: An interesting article about C++ in microcontrollers.Modern C++ in embedded systems – Part 1: Myth and Reality.https://www.embedded.com/modern-c-in-embedded-systems-part-1-myth-and-reality/

author: intmpe
author_rank: Contributor
timestamp: May 11, 2020, 09:59:48 pm
content: Quote from: bd139 on May 11, 2020, 08:26:22 pmMine is too. That is funny as shit but so true.There used to be a website called fuckedcompany.com but they had to take it down because of the legal threats and battles. Now all you have is glassdoor and stuff but my understanding is if you are a company you can actually "pay" to have a better ranking. I've been in companies so fucked up you felt like you needed a rectal exam each day but in glassdoor they look rosy. So you ask yourself how is that possible when everyone you know hates the place. Well .. they buy their ranking.

author: nctnico
author_rank: Super Contributor
timestamp: May 11, 2020, 10:03:31 pm
content: Quote from: engrguy42 on May 11, 2020, 09:58:47 pmPersonally but still a commercial software developer

author: IDEngineer
author_rank: Super Contributor
timestamp: May 11, 2020, 10:16:35 pm
content: Quote from: floobydust on May 11, 2020, 08:00:09 pmThink of C as a "more portable Assembly language" and it makes much more sense. That's how I came to C - nearly everything professional I'd done up to that point was in pure Assembly for whatever platform. But then I joined a team whose project was based in C. Originally I was tasked with writing the hyper-critical sections in Assembly for maximum performance, but you can't do that very long while remaining ignorant of the language to which you're interfacing.So I taught myself C, and it was easy. And fast. And logical. Because I came at it from a "lower level language" (Assembly), I was already accustomed to a programming environment where you have limitless flexibilityand the responsibility that goes with it. I didn't expect the language to bounds-check my pointers, that's MY job. I didn't expect the language to type-check my variables, that's MY responsibility and sometimes you want/need the flexibility to access things in weird ways. Ultimately, it's all just bytes in memory anyway and youshouldbe able to access the 2nd byte of a DWORD directly in memory if you want/need to. Do I need to be careful? Of course, but that's what I'm being paid to do: Be a professional who pays attention to details.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 11, 2020, 10:17:11 pm
content: Thanks. I'm curious in the major commercial software world the bosses are always running around saying "I WANT RE-USABLE LIBRARIES PEOPLE !!! I WANT OBJECTS AND CLASSES AND FUNCTIONS WE CAN RE-USE ON THE NEXT JOB!!"Maybe special awards for the guy who produces the most re-usable classes/objects/functions each month.Hell, if it was me I'd be all over that. Why write spaghetti code when you can make a nice clean re-usable module?

author: coppice
author_rank: Super Contributor
timestamp: May 11, 2020, 10:17:22 pm
content: Quote from: bd139 on May 11, 2020, 08:26:22 pmProjects off the rails are the most secure source of employment in the software industry.

author: IDEngineer
author_rank: Super Contributor
timestamp: May 11, 2020, 10:26:52 pm
content: That, and legacy COBOL code running government agencies....

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 11, 2020, 11:31:35 pm
content: Quote from: coppice on May 11, 2020, 10:17:22 pmAhah, true. I even wonder how many jobs all failed software projects have created. Probably a lot.

author: coppice
author_rank: Super Contributor
timestamp: May 12, 2020, 12:47:41 am
content: Quote from: IDEngineer on May 11, 2020, 10:26:52 pmA real beauty of COBOL projects is it takes years to put together a replacement. So, even if the end approaches, it approaches so slowly you have plenty of time to react.

author: Berni
author_rank: Super Contributor
timestamp: May 12, 2020, 06:34:07 am
content: Just because its OO and C++ does not necessarily mean its more reusable and modular. Its still perfectly possible to create a tangled mess that ties all of it into a monolithic blob that won't compile anymore as soon as you attempt to separate something from it.Yes sure you can get some nice clean code when care is taken to follow this OO thing and implement things trough these interfaces, hide all of its state inside privates etc. If done properly it can make for quite little overhead. Every object is its own self contained module that you can plonk down in to any project and have it run etc... Why wouldn't you want to program like this? Its perfect. But then theory meets practice and half way trough a project you find that actually this object needs to do something to this other object somewhere completely else and make a link to it, binding it to be dependent on that object, this happens a few more times along the way, gradually bonding things together. Then a wild manager appears and not only bumps the goal post over but also turns it 180 degrees, so suddenly a lot of core functionality must change a bit so things are moved around and more of a mess is made. Then the deadline starts coming up and the thing MUST go out the door this friday or they miss some sort of important marketing window. Suddenly nobody has time to think about anything modular, people taking a sledgehammer to that OO wall and exposing some variables public so they can quickly tweak it and fix a bug so they can move on to the other 100 bugs that need to be fixed by the end of the week.So just because you got OO in C++ doesn't mean its automatically more modular, clean and reusable. Its the guy behind the keyboard that determines how reusable code is, even if he is only using oldschool C with a few structs here and there to pretend being little OO when needed (not as pretty but it works)

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 12, 2020, 01:29:59 pm
content: Quote from: Berni on May 12, 2020, 06:34:07 amYes of course.Badly used inheritance can lead to code that is basically impossible to reuse outside of its intended initial use (or would require convoluted ugly interfaces...)IMO modularity per se is best expressed with modules. You can still take a similar module approach with languages that don't inherently support modules. It just takes a lot of discipline.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 12, 2020, 02:40:32 pm
content: Quote from: Berni on May 12, 2020, 06:34:07 amOf course, but the exception does not define the rule. You can screw up anything. People love to raise specific issues (like inheritance) and say that since inheritance sucks the entire OO design idea is useless. Of course that's nonsense. If you don't like inheritance (I personally hate it and therefore never use it), then don't use it.But as an engineer/user, as I said, I LOVE the incredibly intuitive concepts and designs associated with it.So is it that most folks here don't deal with those higher level languages and design concepts because they're more about the lower level hardware systems?

author: madires
author_rank: Super Contributor
timestamp: May 12, 2020, 03:07:17 pm
content: Arduino is C++, just saying.

author: chriva
author_rank: Regular Contributor
timestamp: May 12, 2020, 03:18:01 pm
content: Arduino is still junk no matter which language you use tho

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 12, 2020, 03:19:12 pm
content: Quote from: engrguy42 on May 12, 2020, 02:40:32 pmI think so.When I did custom stuff for a living, I specialized in server-side stuff, where hw is cheap, but security easy to fuck up (and that's what I'm good at). Most of my code was either custom glue and security filtering between/in front of systems, or new to me too.One 'library' that I failed with – in the sense of ending up rewriting it about half a dozen times in as many years – was form and file upload handling around the turn of the century. Part of it was my inexperience (I didn't know what kind of API would work for most use cases and be maintainable in the long term), and part was that then, browsers were really, really shitty about following the standards (they didn't). So you had user agent checks and workarounds galore. I cursed the people who decided to use MIME instead of a chunked or escaped transfer encoding many a time to the deepest hells.. And a part was that I was also battling with other browser inanities, getting non-ASCII characters from various Windows and Mac systems to transfer correctly. Not many people then cared, but I did.Quote from: madires on May 12, 2020, 03:07:17 pmEver tried to use an exception in Arduino? No? That's what I thought.Arduino is not C++, but an unspecified subset of it. You could call it freestanding C++, I guess, as opposed to normal hosted C++, because C++ leaves just about everything 'implementation defined' in freestanding environments.That was one of my questions earlier, BTW. Can you call it C++ if you are only allowed to use a small subset of the features of C++? Especially when that subset is not described exactly anywhere? I feel like saying it is C++ is misleading to newcomers/programmers, and will lead to frustration.

author: coppice
author_rank: Super Contributor
timestamp: May 12, 2020, 03:37:47 pm
content: Quote from: Nominal Animal on May 12, 2020, 03:19:12 pmNames are chosen to obscure, not illuminate. Hence they chose the name C++, that appears to be an incremental change from C, for a language that is a radical departure. If you strip C++ back to the point where it genuinely is an incremental change the name C++ would become meaningful, and that wouldn't do at all.

author: Wolfgang
author_rank: Super Contributor
timestamp: May 12, 2020, 04:05:49 pm
content: Quote from: madires on May 12, 2020, 03:07:17 pmSome thoughts to C++ on microcontrollers with limited memory:IMHO, a really silly idea. Dynamic memory needs a memory manager, an this needs to take care offragmentation, free space recovery, garbage collection... Causing nondeterministic execution times, out of memory errorswhen enough memory *should* be there, but not in 1 chunk as you need it and so on.My strong advice: dynamic memory (malloc), OO string classes, ... forget it if you want a reliable app.Arduino only works well if you never try something risky. Realtime/Interrupt stuff combined ith OO ? A nightmare.Keep stack small, always know where your vars are, use C as an interface to machine language (L.Torvalds idea).That should work on small platforms.

author: nctnico
author_rank: Super Contributor
timestamp: May 12, 2020, 05:18:14 pm
content: Quote from: Wolfgang on May 12, 2020, 04:05:49 pmThat is a myth and thus completely wrong. For starters: C++ doesn't even has a garbage collectorQuote from: Nominal Animal on May 12, 2020, 03:19:12 pmBut the same is true for C. There is a lot from the standard library you can't use. File I/O for example. Malloc & free are also troublesome to say the least.

author: Wolfgang
author_rank: Super Contributor
timestamp: May 12, 2020, 05:47:46 pm
content: Quote from: nctnico on May 12, 2020, 05:18:14 pmNo language standard specifies how memory that is no longer needed is handled. Thats specific to a runtime component.And believe me, a lot of intelligent algorithms have been written to handle this. Problem. Efficient / Fast / Deterministic. Choose any two.

author: coppice
author_rank: Super Contributor
timestamp: May 12, 2020, 05:51:01 pm
content: Quote from: Wolfgang on May 12, 2020, 05:47:46 pmMany languages are specified with their run time environment, and are not really separable from it. Java assumes a garbage collecting environment, for example.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 12, 2020, 05:54:35 pm
content: Quote from: nctnico on May 12, 2020, 05:18:14 pmSome of you are quick to shoot, aren't you?The "garbage collection" argument he made was wrong indeed - C++ doesn't inherently have a garbage collector indeed. SO yes, remove that silly point.The rest still applies - dynamic memory allocation, even without garbage collectors, CAN cause nondeterministic execution times - unless you use very specific allocators that are certainly not the ones that ship with the compiler. And of course that requires properly checking for successful allocation one way or another, which can be messy (or untractable - sometimes developers just don't know how to gracefully handle an out of memory condition.)That's why dynamic allocation is frowned upon, or even forbidden if you follow rules from some safety-critical guidelines. If you have to follow this rule, properly using C++ is not impossible, but much harder than it looks.Quote from: nctnico on May 12, 2020, 05:18:14 pmYes, but that's not exactly at the same level. What he mentioned for C++ is at the language level itself, which is a lot more problematic - basically there are settings where you can't use some language features, which is confusing for programmers. OTOH, libraries are a slightly different matter: I don't think any of what you mentioned is a mandatory part of the C standard. File I/O and memory allocation are all optional, if I'm not mistaken. OTOH, a lot of advanced C++ features that could be problematic on small embedded targets are NOT optional as per the standard.The point is: the right subset to use is hard to define, is usually NOT defined clearly and largely depends on each developer. Not an ideal situation.

author: Picuino
author_rank: Super Contributor
timestamp: May 12, 2020, 06:04:00 pm
content: Arduino has 2k of ram. It is near impossible to do a good memory management with such a minimal amount of resources.Normally, libraries work only with static memory, with the variables defined by default with each class.Printf isn't even used because of the large amount of memory it consumes.

author: madires
author_rank: Super Contributor
timestamp: May 12, 2020, 06:06:41 pm
content: Quote from: Nominal Animal on May 12, 2020, 03:19:12 pmIs there only one true machine language or one real BASIC? No! There are many flavours of each language. But there are also standards defining some specific variant of a language, like C++17 (ISO/IEC 14882:2017) or C18 (ISO/IEC 9899:2018).

author: Picuino
author_rank: Super Contributor
timestamp: May 12, 2020, 06:23:16 pm
content: There have also been attempts to define subsets of C++ for embedded systems, but without much success.https://en.wikipedia.org/wiki/Embedded_C%2B%2B

author: maginnovision
author_rank: Super Contributor
timestamp: May 12, 2020, 06:51:15 pm
content: Quote from: Picuino on May 12, 2020, 06:04:00 pmThey teensy 4.1 can have over 8Mb of ram, arduino is not an mcu it's just a lousy ide and a set of libraries to use.

author: Wolfgang
author_rank: Super Contributor
timestamp: May 12, 2020, 07:03:46 pm
content: Quote from: coppice on May 12, 2020, 05:51:01 pmNot true, IMHO. Some specify (Java) that GC is done, but not *when* its done and *how* its done. A ton of problems emerged from the fact that on a large machine Java never ran out of memory so no GC was done. The obliterated objects did contain some OS resources, however (e.g. handles) and some ugly day the app crashed because handles were out of stock. In Java, you may call GC(), *but there is no guarantee that something will happen*. On small hardware - this is deadly.

author: IanB
author_rank: Super Contributor
timestamp: May 12, 2020, 07:08:43 pm
content: Quote from: Wolfgang on May 12, 2020, 05:47:46 pmIn C++ you have complete control over when each resource will allocated and when it will be freed. If you don't want to rely on heap allocation for memory you can make 100% use of stack allocation. You don't have to use dynamic allocation in C++ any more than you have to use malloc() in C.C++ is actually very good at compiling for embedded systems because the compiler can allow for more expressive code (reducing bugs and improving maintainability) while producing binaries as small and fast as a C compiler.Why do you say pick any two from efficient, fast or deterministic? Why can an efficient and fast program not be deterministic at the same time? I would suggest that most code written for small embedded systems is all of these.

author: IanB
author_rank: Super Contributor
timestamp: May 12, 2020, 07:10:16 pm
content: Quote from: Picuino on May 12, 2020, 06:23:16 pmThis is a human problem, not a technical problem. Just because there is a supermarket full of food, does that mean you have to buy and eat everything that is on the shelves? Most people are selective, they buy what they need, leave what they don't.

author: Picuino
author_rank: Super Contributor
timestamp: May 12, 2020, 07:15:37 pm
content: Quote from: maginnovision on May 12, 2020, 06:51:15 pmArduino is not an IDE nor a development board. Arduino is a commercial trademark of Arduino LLC (the company). Many of its hardware and software products carry the Arduino brand in their name.Teensy is not an Arduino LLC project. It just has a compatibility pack with the Arduino IDE, like other external projects.When I spoke of Arduino I was referring to the development boards based on the Atmega328P, the most widespread.

author: Picuino
author_rank: Super Contributor
timestamp: May 12, 2020, 07:42:00 pm
content: We are debating about the tools C or C++. But in programming there are two elements involved, the programming language and the programmers. Since the first time I had to program in a company (in my case with ladder language of the PLC) the simplest task was to learn the language.The most difficult task was learning the method of representing the algorithms (Grafcet) and all the company standards that had to be followed in order for the software to be homogeneous and easily maintainable from the projects office to the workshop technicians.In other languages ​​the same thing happens, the development environment (the company and the team you work with and its rules) are more important than the language itself.

author: Picuino
author_rank: Super Contributor
timestamp: May 12, 2020, 07:46:40 pm
content: I think you can make good C++ software for microcontrollers, but that is very much related to being able to follow strict development rules and that programmers follow them efficiently.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 12, 2020, 08:16:47 pm
content: Okay, I'm not gonna rub it in anymore. I promise.Well, maybe just this one last timeYou guys need to get out more. Deep, never ending discussions of booleans and unrelated C stuff. Memory worries, garbage collection...And me, I whipped together a wonderful app in C# in no time, and son of a gun it's already being used for important stuff.In the other forum I posted on a USB battery I have that needed a circuit to apply brief pulses of load to keep it on, otherwise the internal circuit would shut it off. So I kludged together a 555 circuit with some yummy PWM output, and now my battery stays on with 5 second pulses of load current every 15 seconds.And to log its behavior I used my C# data acquisition app (see below). Took me, on and off, a couple days to build that app and put the finishing touches.Now honestly, I know you guys just LOVE your C and all that embedded stuff, but come on. You can't do that in C. No way. Not possible. GUI stuff? Logging to CSV file? Making realtime charts/graphs that auto-update scaling factors as data comes in? Hell, that would take weeks to do that in C. Maybe months. Or years.Anyway, I apologize. Just messin' with ya. C RULES!!!

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 12, 2020, 08:20:06 pm
content: Quote from: nctnico on May 12, 2020, 05:18:14 pmNo, "freestanding C" is very well defined compared to "freestanding C++". If you compare the standards, you'll find that C++ leaves it basically up to the implementation, which means that "freestanding C++" is implementation defined – it doesn't mean anything unless you specify the implementation.For freestanding C,noneof the standard library is available. Facilities provided by <float.h>, <limits.h>, <stdarg.h>, <stddef.h>, <stdbool.h>, and <stdint.h> should be available. Complex number support is optional, and using any floating-point variables or operations can require special consideration (for example, on hardware that does not support FP), but otherwise the core language features are available. This is well defined, with few surprises.For freestanding C++, some of thecore language features, like exceptions, may or may not be available; you don't know, unless you know the implementation. And Arduino folks don't say; they don't really even call the code C++, just "Arduino sketches".It is true that the distinction between "freestanding" and "hosted" is crucial for C, but is often ignored because people think it is "obvious" from the context. I think that is equally misleading to new programmers.Quote from: madires on May 12, 2020, 06:06:41 pmExactly. And my point was that while "Freestanding C" is well defined in the standards with fuzzy edges around complex and floating-point support only, "Freestanding C++" is almost completely implementation-defined,including core language features like exceptions.There must be a limit to how many core language features you can remove, and still call it the same language. With C, you get mostly right if you say "the standard C library is not available", but with C++, all bets are off; and therefore a more descriptive label that much more important.In the other direction, I've mentioned "POSIX C99", which means a hosted C99 (ISO/IEC 9899:1999) environment that provides IEEE Std 1003.1™-2017System Interfaces.(FWIW, I personally do point out to learners that"Arduino uses a subset of C++ features, not the full C++ language"with additional descriptions of those features depending on their knowledge level. I do that because it is thus far it seems to foster the most reasonable expectations and helps with the intuitive grasp the environment. Those expecting their hosted C++ to be directly applicable are usually sorely disappointed by the limitations.)

author: Berni
author_rank: Super Contributor
timestamp: May 13, 2020, 05:49:38 am
content: Quote from: engrguy42 on May 12, 2020, 08:16:47 pmWell there is a lot of truth to that actually.Technically being able to easily barf out a json/XML file or make a GUI with a few lines is irrelevant of the languages features. It just means having a library that does that thing for you with a few magical function calls. But in practice C/C++ does not provide any more than the most basic functionality from the standard set of libraries that you get with it.The difference with C# is that the standard set of libraries includes pretty much everything under the sun, from reading and saving jpeg/png images to making HTTPS requests to accessing a database to graphics rendering to sound input/output to asking the OS to not go to sleep mode...etc Okay sure not all of those libraries are really that well made but most of them work really well. So instead of looking for C++ libraries that do the thing, git cloneing them, figuring out how to make them work etc... all you do is stick a "using Windows.Media.Audio;" at the top of your code and you got your library. If the built in libraries don't cut it for the specific thing you want to do you can still go find a C# library online and stick it in.Not saying that C should also have this, just that this is most of the reason C# is so nice for quickly throwing an app together. The C# language it self is nothing that special, its just Microsofts take on a more performant Java clone. They could have used pretty much any other sensible language and the result would be similar once its packed in with those libraries and a IDE that "just works". That's why VB.net exists, its pretty much C# with Basic flavored lipstick so that the syntax looks familiar to people coming from VB6. Only reason for the C letter in C# is to look familiar to the large userbase of existing C programmers even tho the only thing it really shares with C is the semicolon flavored lipstick. Might be silly but it worked.

author: nctnico
author_rank: Super Contributor
timestamp: May 13, 2020, 06:11:47 am
content: Quote from: engrguy42 on May 12, 2020, 08:16:47 pmNot really. There is a whole flurry of libraries for that. Qt is probably among the most advanced ones.

author: Karel
author_rank: Super Contributor
timestamp: May 13, 2020, 07:36:45 am
content: Quote from: nctnico on May 13, 2020, 06:11:47 amI was about to say that as wellAnd with Qt you are not stuck with windows which is a big plus as well.

author: hans
author_rank: Super Contributor
timestamp: May 13, 2020, 07:59:50 am
content: Quote from: Wolfgang on May 12, 2020, 04:05:49 pmI agree that dynamic memory is a mess for embedded. But if you can avoid that, then my experience with C++ is the exact opposite. It's a bliss compared to plain C.Case in point with the Linux source code: creating structs with function pointers to define several driver implementations according to a particular model, is much like object oriented programming. You can force it in C using that way, or switch to a C++ compiler and use classes.Even more so, in C++ you get the option of compile-time inheritance and metaprogramming, which are very powerful tools for embedded devices in which we try to minimize run-time computations. These alone can drastically reduce the memory complexity and footprint of a program, while still offering flexibility in switching between hardware and simulation models of your BSP.In C++ you can perform assertions using actual code, instead of using the rather convoluted preprecessor which quickly becomes a mess, and limits descriptions to pre-compile-time only (whereas in C++ you can use static_asserts with any constexpr function that's already available in the code base)Keeping track of variables is a good thing indeed, so never use globals. If you can efficiently describe & manage data, it is also trivial to implement unit tests for them with side-effect free setup and teardown code. Unit tests have saved me a ton of time and debugging, in fact.. I hardly do any debugging on embedded devices except for BSP-related code.

author: olkipukki
author_rank: Frequent Contributor
timestamp: May 13, 2020, 08:30:13 am
content: Quote from: engrguy42 on May 12, 2020, 08:16:47 pmWhy you (or somebody else) need to do this one-off stuff in C?Quote from: engrguy42 on May 12, 2020, 08:16:47 pmAlso, you probably do not need spend 2 days on that app...(aka Python & Co)

author: chriva
author_rank: Regular Contributor
timestamp: May 13, 2020, 08:47:54 am
content: Quote from: olkipukki on May 13, 2020, 08:30:13 amPython is nice for certain things but you're a special kind of stupid if you run it on embedded stuff (aka micropython).It's like sticking a moped engine in a car and expect it to move at a reasonable speed

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 13, 2020, 09:40:41 am
content: Quote from: chriva on May 13, 2020, 08:47:54 amYou're special kind of stupid if you run C# on embedded stuff. It's like sticking a car engine on a moped and expect it to be easy and safe to ride.

author: chriva
author_rank: Regular Contributor
timestamp: May 13, 2020, 09:46:11 am
content: C# is like that embarrassing, drunk uncle at the family reunion that no one wants to talk to

author: Berni
author_rank: Super Contributor
timestamp: May 13, 2020, 10:54:19 am
content: Okay yeah i did forget about Qt.I never used Qt and had the impression that its mostly just a multiplatform GUI library with an editor, but yeah i see it does indeed also have libraries for everything else too.For me its mostly a case that i never got all that deep into C++ because it covers a middle ground that i rarely had the need for. For low level things i found plain C to be all i need. For small PC apps i didn't really care about memory usage or speed all that much (PCs are so ridiculously fast anyway). So i wanted to make use of the available abstraction and just ignore the hardware to make life easier in something like C#. Since i came from VB6 i was used to the VisualStudio IDE and WinForms, so it all felt familiar and it just all worked out of the box. Since all of this ran at near C++ speeds it gave me little reason to go back again.Sure C++ makes lots of sense for big projects where you have a team working on a actual sold software product. But for the small apps that people make alone on the side, then the benefits of C++ are not that significant. Especially on a forum like the EEVblog where most people who do programming are just various kinds of engineers that happen to also write software just to get stuff done (like me) rather than programing all day as a job. This is the same reason why VisualBasic rose to such popularity 20 years ago, its a easy to use and comes in a friendly IDE that just works out of the box while requiring very little knowledge to use. Python caters to the similar crowd. Its about getting things done quickly without being a major in computer science.Its the same reason why Windows shows up in engineering so much. Its quick and easy to just buy a piece of software, install it and move on. Going for open source solutions just adds unnecessary extra steps that the engineer doesn't have time for since he is not there to do IT stuff or software development.Just like race cars are not for everyone. Sure they are fast and perform better than all the other cars, but not everyone knows how to properly drive one, nor do they need to because a regular passenger car does the job just fine for them.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 13, 2020, 11:35:19 am
content: Okay, so let's get honest here...I hear a lot of talk of C and embedded systems. And I originally assumed that you guys were working in some large companies that designed microcontroller systems for, say, automobiles or other real world stuff.But I'm starting to think that this strong bias in favor of C and embedded systems is actually a bunch of hobbyists working on Arduinos, who really have no experience in developing software in other languages for real world stuff?Just asking...Because it's hard to understand a "holier than thou", "drunk uncle" nonsensical bias against any tool that helps you to quickly get stuff done. I mean, it the real world, it's all about the best tool to get your problem solved as quickly and efficiently as possible.

author: chriva
author_rank: Regular Contributor
timestamp: May 13, 2020, 11:50:55 am
content: Car manufacturers are usually using C++ if that answers your question.Depending on system obv. I refer to the stuff doing the low level crap. No idea about cameras and infotainment systems

author: coppice
author_rank: Super Contributor
timestamp: May 13, 2020, 11:53:42 am
content: Quote from: chriva on May 13, 2020, 11:50:55 amThey may be using C++ for the big processors in the infotainment system, but they aren't using it for the 100 or so MCUs spread around the car. MISRA C is the norm there.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 13, 2020, 11:56:51 am
content: Quote from: chriva on May 13, 2020, 11:50:55 amThanks, but you're not answering the question I asked.

author: coppice
author_rank: Super Contributor
timestamp: May 13, 2020, 12:00:44 pm
content: Quote from: engrguy42 on May 13, 2020, 11:35:19 amArduino isn't a C environment. Its a sort of twisted C++.Try looking at the tools available for MCUs. You'll always find a usable C compiler, and, of course, there will be an assembler. You may find a C++ compiler, because its using the same back end as its accompanying C compiler, so it comes for free. However, if you try it you'll find its useless for anything but the largest memory MCUs. You are unlikely to find compilers for any other languages. That should tell you what professional developers use for MCUs. For larger embedded devices the languages are more diverse, but in the MCU world its assembly language, C, or something really niche.

author: chriva
author_rank: Regular Contributor
timestamp: May 13, 2020, 12:04:44 pm
content: Quote from: coppice on May 13, 2020, 11:53:42 amI was thinking PCM/ECU or other stuff that is safety related. And yes, lots of certifications and other shenanigans going on. Aaand yes. C / C++ for those. Don't think there are any other languages that have these certifications. Almost getting silly these days, you have processors watching over other processors to make sure things are not getting out of hand. It started with throttle body processors around 98 and has gotten progressively more overkill.

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 13, 2020, 12:16:28 pm
content: Quote from: engrguy42 on May 13, 2020, 11:35:19 amHave you ever used any other operating system besides Windows?I actually used to maintain a dozen or so Windows machines in a Uni/office environment, before the turn of the century. Had a couple of dozen Macs (pre-X), and a couple of Linux servers as well. I donothave experience with current Windows (7-10), nor have I developed embedded apps for true realtime OSes. I've been paid to develop software in about a dozen different programming languages. More recently, I've split my efforts into helping others learn on one hand, and to scientific simulators and sensors and hardware interfaces to sensors; not exactly commercial stuff at all. Yet, even with that wide a field of experience, I am very aware that it really is limited. I ain't a Guru. You see that if you read my posts: I do not claim to know the truth, I just claim to havesomeexperience – hopefully not just my own (because emotional bias makes that unreliable IMO), but those I've seen others struggle with, repeatedly –, and am drawing mycurrentopinions from those.To be honest, your output sounds like a classicDunning-Kruger casein the early part of their career and knowledge, where everything seems simple and straightforward and obvious, and those who discuss details and problems you've never encountered seem to be niggling about completely irrelevant stuff. Simply put, the guy with his first hammer, shaking it and laughing at people discussing screws, bolts, adhesives, joinery, structural design, and tensegrity.Maybe that's a misconception, who knows.I am just saying that that is how your output looks to me.

author: Berni
author_rank: Super Contributor
timestamp: May 13, 2020, 12:21:18 pm
content: Well the ~20 people software team here mostly makes use of a mix of both C and C++ for both embedded MCUs and under linux. But they also all use C# to build any PC apps (Stuff for configuration, user customization utilities, programing, communication, production tests etc). Here i see C++ on MCUs mostly used to organize code better using classes, namespaces etc.... So in the end it like C with some C++ syntax sugar sprinkled on top (But yeah even if you are not using 90% of C++ features its still C++).But it's not just my personal liking for .Net CLR. I noticed that almost all job interviews i had back then had brought up C# at some point even tho the position i came for was a hardware engineer. Heck this place even handed me a programing test to solve at the interview where the first half was C and the other C# despite again hardware engineer. People i talked to at other companies also used C# a lot So at least here in Slovenia C# is apparently very popular among engineering companies.If you go look at software development companies the picture is likely different, but i never even looked at those, since while i do find programing fun i would never want a job where that's all i do every day.

author: coppice
author_rank: Super Contributor
timestamp: May 13, 2020, 12:27:41 pm
content: Quote from: Berni on May 13, 2020, 12:21:18 pmThere was a time when interviews loved testing embedding people on their Pascal ability, yet nobody ever took Pascal seriously for embedded work. People used to have the knowledge to pass these interviews because colleges were teaching Pascal in those days, even though few forms of Pascal ever achieved much commercial success (Delphi being a big exception).

author: ace1903
author_rank: Regular Contributor
timestamp: May 13, 2020, 12:39:24 pm
content: Worked on mobile phone development, from the processor on development board up to phone ready for the marked.Modern phone, Android based is 30% C code, maybe 5% cpp and rest java.The whole TEE is C code, all security libraries are C based. Even user space android uses C libraries.Try to make communication over a network without using#pragma packPython is nice if you do stuff for fun.Once I needed to repack data from big-endian to little-endian. Time needed python to do repacking was equal to all processing in C++ (filters ffts....)

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 13, 2020, 01:17:54 pm
content: Nominal Animal, with regards to any Dunning-Kruger I may be (or probably am) suffering from...I started in the 80's, as an engineer, writing ASM to solve problems. One of my first was a line frequency meter which took regular samples of line frequency and reported them to my Z80-based computer. I also did tons of Basic.Prior to that, in college I used FORTRAN for many years doing engineering projects for my engineering classes.In my 45+ years as an engineer I've used and written many software tools to, mostly, simulate real world systems (feedback/control systems, mechanical equipment dynamic response, etc.). These have been mostly higher level vendor-specific versions of their scripting and other applications. Also stuff like MATLAB, and tons of other software. I've also developed software Python-like modules for stuff like graphics/video compositing apps, etc. And as I've mentioned I've done a lot of programming of data acquisition devices like the Labjack, using their C/C++ interfaces.I also have Linux (Cinnamon Mint & Ubuntu) installed on my desktops and have used and programmed it on and off over the years, though I admit I have little tolerance for the command line as well as other user-unfriendly stuff. Oh, and I also have a Raspberry Pi with its version of Linux that I've prgrammed a lot. But no Arduino..A week or so ago I tried to get back in to Python (a short journey which I outlined previously in this thread), and decided the benefit wasn't worth the cost.Separately I've done a TON of graphics-based and other programming in C++, mostly along the lines of ray tracing, using stuff like DirectX and OpenGL. I've also done many tons of C# apps for a myriad of purposes over the years. Also NVIDIA C/C++ CUDA for parallel GPU computations and such, not only graphics but other engineering-based parallel problems.I'm sure there's a bunch of stuff I'm forgetting, but I agree with you. I have severe Dunning-Kruger. As my signature below says:"The best engineers know enough to realize they don't know nuthin"

author: madires
author_rank: Super Contributor
timestamp: May 13, 2020, 01:51:59 pm
content: Quote from: nctnico on May 13, 2020, 06:11:47 amI still got some Motif developer licenses for linux and several weighty tomes from O'Reilly.

author: madires
author_rank: Super Contributor
timestamp: May 13, 2020, 02:24:25 pm
content: Quote from: engrguy42 on May 13, 2020, 11:35:19 amI'm experienced in both, in hobbyist projects and non-embedded real world stuff. And after learning two BASIC variants, Z80, COMAL80, Modula, 68000 and three Pascal variants I stopped counting programming languages. Today I mostly do C and bash, while expecting some Python in the near future.

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 13, 2020, 04:22:00 pm
content: Quote from: engrguy42 on May 13, 2020, 01:17:54 pmI specifically didn't say that!I said that's what your posts read like.I find it very odd that someone with your experience would so aggressively ridicule others from using whatever tool they think is best for a particular problem, and discussing what that problem domain might be for C (that is not well covered by higher-level languages like C++) – that is the topic of this thread, after all. I'd really like to know why. Did all those other projects fail, or what?Quote from: engrguy42 on May 13, 2020, 01:17:54 pmNothing wrong with that, in my opinion. The OS you use is just another tool; whatever works for you, works for you.Quote from: engrguy42 on May 13, 2020, 01:17:54 pmWhen you found out Qt5 didn't integrate into Visual Studio, you dropped it on the floor. That has nothing to do with the language or its libraries; you just basically said that because it does not integrate nicely into Visual Studio, it won't fit your workflow.And that is fine. But don't berate others if they don't have your VS fixation. Whether the language and its libraries are well integrated or not into VS is not a sane measure of the language in general.Thelikegeeks PyQt5 tutorialseems to tell how to avoid the hassles in Windows, where to find the Qt Designer, and even that you do not need to "compile" the .ui file(s) you create in Designer, as you can just load them in your Python code using PyQt5.uic.loadUi(). So, it looks like a sensible place to start, if you are using Windows, and interested in Python + Qt5. (seems, because I don't use Windows, so I can't verify.)That said, PyQt5 documentationisannoyingly hard to locate; one will want to bookmarkhttps://www.riverbankcomputing.com/static/Docs/PyQt5/module_index.htmlfor that. For Python 3,https://docs.python.org/3/library/is the page to start with.If there is any interest, I'd be happy to provide a small example in a new thread in the Programming subforum.

author: IDEngineer
author_rank: Super Contributor
timestamp: May 13, 2020, 04:34:51 pm
content: Quote from: engrguy42 on May 13, 2020, 01:17:54 pmThat's funny, the vast majority of the one-off tools I write are command line based because I'm simply trying to get some task done, and don't want to waste time on a "pretty" GUI. In my humble experience, creation (and the seemingly endless fine-tuning) of a fancy front end takes far more time than writing the code that actually does the work in question. If it's not a commercially shipping product, I don't care what it looks like... I care that it gets the job done, and the faster the better.This is not meant as an insult to those with different priorities, just another data point to consider.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 13, 2020, 04:35:51 pm
content: Quote from: engrguy42 on May 13, 2020, 01:17:54 pmA phrase in a signature is proof of your humility?I'm sorry, but so far, none of your posts have really shown any sort of humility, so this is hard for others to see it between the lines.And your posts are consistently off topic too, but I'll admit you're not the only one here.All I've read from you are attempts at being funny (I guess?) while trying to belittle pretty much everyone else, and then bold statements like "this or that can't be done with this or that language", which was consistently false. You seem pretty good at twisting the logic of others' arguments to your advantage too, and ignore whatever you feel like ignoring if it's convenient.Whatever tools you use for your projects, that's really fine. No problem with that. You seem to be evangelizing CS, that's your problem. Some have had a few arguments against CS, but really nobody told you you were using the wrong tools either.I have rarely seen anyone here actually not respecting other people's experience and opinions to this level. It's amazing. Surely you're a very good and very humble engineer.Unfortunately, this thread now is IMHO growing a significant probability of ending up locked due to it completely derailing. Nice job.

author: Picuino
author_rank: Super Contributor
timestamp: May 13, 2020, 04:48:18 pm
content: Quote from: IDEngineer on May 13, 2020, 04:34:51 pmI can say the same of the tools that I program for few uses.When I want to complicate things a bit more and add options, I usually add them in a separate file called options.ini with a list of options that are self-explaining or with comments. That is easier to use than the command line when there are many options and it is still easy to implement in languages ​​like Python.

author: engrguy42
author_rank: Frequent Contributor
timestamp: May 13, 2020, 05:02:52 pm
content: Silicon Wizard,Really, you don't like my humor?If you have an unbiased reading of what I actually post (not what you want to read in between the lines) I've been merely mentioning an option to C (the original topic) that nobody else has mentioned, in order to provide reasons WHY C might not be the language of choice for everyone. But over and over I have been the one saying that whatever tool fits the job is fine. How is that bad?I've actually (as I usually do) been giving examples to show WHY C might not be the go-to language for some in the engineering world. Real world examples. From an engineer. Others rely on vague generalizations and dismissals, and unsupported opinion on stuff I'm increasingly starting to believe they just have no experience with.As I've said, I don't care about software. I don't "like" one tool or the other. I'm not a fanboy. I don't take this stuff personally. Unlike others who make personal attacks against those who disagree.Some languages are more frustrating than others, but that doesn't mean I don't use them. Or at least try them. And I try not to dismiss stuff without trying it. And I try not to make blanket, unsupported dismissals, which seem to be common here. As do claims of "you derailed this thread" by those who couldn't actually care less about whether anyone stays on topic, they just need some mud to throw.

author: Picuino
author_rank: Super Contributor
timestamp: May 13, 2020, 05:07:08 pm
content: Quote from: SiliconWizard on May 13, 2020, 04:35:51 pmTo focus the topic, the problem is not how good are other languages ​​to make GUIs or other similar things.The initial question is how many people still use C and why.I no longer use C on the PC. I did it before, but now there are better languages ​​for that environment.But many programmers still make C programs for the PC (operating systems, office automation, programming languages, ...)In the world of microcontrollers C it is still one of the best tools, not yet surpassed. Although there are those who program in C++, its advantages are not so many as to displace C.

author: Karel
author_rank: Super Contributor
timestamp: May 13, 2020, 05:28:02 pm
content: Quote from: Nominal Animal on May 13, 2020, 04:22:00 pmhttps://doc.qt.io/qtforpython/https://doc.qt.io/qtforpython/api.htmlhttps://doc.qt.io/qtforpython/modules.html

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 13, 2020, 05:59:49 pm
content: Quote from: Karel on May 13, 2020, 05:28:02 pmThose are for PySide2, not PyQt5, though. The Debian (and thus Ubuntu, Mint etc.)python3-pyqt5still use the RiverbankComputing GPL (non-LGPL) Python bindings, not the official ones. The official ones are relatively recent; I believe the PySide2 packages were added to Debian in July 2018.(For a long time, there were no "official" Qt bindings for Python at all. Debian and Debian-derived Linux distros used PyQt4 and PyQt5 bindings maintained by RiverbankComputing, under the GPL license. PySide2 is the relatively new, official set of Qt5 bindings for Python.)There is apython3-qtpycompatibility module that automatically switches between PyQt4, PyQt5, and PySide using the PyQt5 "style".Are the two bindings identical, or close enough? I do not know. But I didn't want to assume the twoareidentical, and get bit at some point.

author: Karel
author_rank: Super Contributor
timestamp: May 13, 2020, 06:08:45 pm
content: Quote from: Nominal Animal on May 13, 2020, 05:59:49 pmYou are right, my mistake.

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 13, 2020, 06:41:19 pm
content: No worries, Karel!I took a look at the glue interface in the python3-qtpy package (that provides a PyQt5 interface on top of PyQt5, PyQt4, or PySide), and here are the differences it smoothes over between PyQt5 and PySide2 currently:In PySide2, using Python objects as userData in QtWidgets.QComboBox can cause Segmentation Faults. Should get fixed upstream, is also easily worked around in Python code.QtCore has four differences between PyQt5 and PySide2: pyqtSignal, pyqtSlot, pyqtProperty, and QT_VERSION_STR in PyQt5.QtCore are Signal, Slot, Property, and __version__ in PySide2.QtCorePySide2 doesn't have QtMultimedia.ui file loader in PyQt5 is uic.loadUi(), but PySide2 provides a QtUiTools.QUiLoader class instead, with completely different use patterns. (python-qtpy implements a loadUi() based on the QUiLoader class on PySide2.)So, nothing alarming. This means that a Python3 Qt5 application can use either set of bindings, with just a couple of differences that are easy to fix either at application level or library level, and with the exception of uic and QtUiTools, one should be able to use either set of documentation. It is not difficult to write an application that uses whichever is available at runtime.

author: olkipukki
author_rank: Frequent Contributor
timestamp: May 13, 2020, 07:33:52 pm
content: Quote from: engrguy42 on May 13, 2020, 01:17:54 pmYou cannot get back to Python, you either "with us or not"I would say same to C++ than need preaching and worship on daily basis, otherwise a few years gap or decade will leave it as just a line in a person list of known languages.On another side, C punched in a brain gonna stay there forever.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: May 15, 2020, 08:24:58 pm
content: Quote from: madires on May 13, 2020, 01:51:59 pmMe too.

author: nctnico
author_rank: Super Contributor
timestamp: May 15, 2020, 09:08:38 pm
content: Quote from: engrguy42 on May 13, 2020, 05:02:52 pmThat is one of the hard parts of getting older. I know nothing of Python so when a younger engineer I work with regulary suggested to write an application in Python I had to take a bit of time in order not to Pavlov into 'I don't know it so it must suck. Use C++'. But I did tell him to investigate whether an application in Python is easy to deploy for customers (create and installer and so on) first.

author: Wolfgang
author_rank: Super Contributor
timestamp: May 15, 2020, 10:23:27 pm
content: Well done. I'm almost sixty, and this year I had to learn Python, too, and I must say for instrument automation,engineering and scientific tasks its better than C/C++. Being dumb is no problem - not learning something new is.

author: jfiresto
author_rank: Frequent Contributor
timestamp: May 16, 2020, 06:41:16 am
content: Quote from: Wolfgang on May 15, 2020, 10:23:27 pmA fun and rewarding aspect of Python is unlearning old habits from using C/C++. A couple decades of the latter (seasoned by a few years of TECO) took about seven years to unlearn.

author: SimonR
author_rank: Regular Contributor
timestamp: May 16, 2020, 10:14:50 am
content: Quote from: jfiresto on May 16, 2020, 06:41:16 amInteresting. I have to learn some python in the near future, What habits did you unlearn, what were they replaced with. In other words what traps are there for the unwary C programmer?

author: bd139
author_rank: Super Contributor
timestamp: May 16, 2020, 10:31:09 am
content: One simple thing. Don't try and write C in python. Good book ... just speed read it though and do the setup and some of the exerciseshttps://files.meetup.com/18552511/Learn%20Python%20The%20Hard%20Way%203rd%20Edition%20V413HAV.pdf

author: olkipukki
author_rank: Frequent Contributor
timestamp: May 16, 2020, 10:48:14 am
content: Quote from: bd139 on May 16, 2020, 10:31:09 amPython 2?!They will read it and after year or two need unlearn print " vs print(

author: bd139
author_rank: Super Contributor
timestamp: May 16, 2020, 11:04:26 am
content: Fail on my part. I thought I linked to the python 3 version. But I just linked to the 3rd edition of python 2 ffs.There is one! I'm not googling it on my phone though

author: paulca
author_rank: Super Contributor
timestamp: May 16, 2020, 11:35:10 am
content: Monoglots. Of course their language is the best language there is.... for everything.

author: nfmax
author_rank: Super Contributor
timestamp: May 16, 2020, 02:06:42 pm
content: Quote from: bd139 on May 16, 2020, 11:04:26 amThe worst thing about Python is the 2/3 split. When they decided to launch Python 3 they should have named it Beansprout or something else. I've just been investigating how to install Python 3 'properly' on Mac OS. Seemingly I should install some weird version of gcc (or maybe Xcode at a pinch) then install Homebrew to install some package which will allow me to install and compile some utility that lets me dynamically switch between the antique system Python (so old it no longer gets security updates) which will cause all hell to break loose if it isn't there, and the one I should be using.A good language, but life's too short!

author: bd139
author_rank: Super Contributor
timestamp: May 16, 2020, 02:37:14 pm
content: Oh it's a piece of piss to install python 3 on MacOS. Take the mac and chuck it out the window or install windows on it. Seriously. I was a mac user from ~2001 -> 2019 and now I spend the entire day watching our contractors fixing shit on it to do basic stuff that actually just works on windows. It's both hilarious and surprising because back in 2008 it was the other way round. Python packaging on linux is crap too. I spent at least 5 days this year unfucking centos python packages where someone has installed something with pip on the target node.So windows 10 + python/go + VScode + minikube for me now.Also surprisingly perhaps MS's cloud offering is the least shit as well (I'm not going to say the best because that doesn't exist)Edit: proof I'm a turncoat. Python on OSX ...Actually that machine gave me a nasty arm rash constantly.

author: olkipukki
author_rank: Frequent Contributor
timestamp: May 16, 2020, 04:08:46 pm
content: Quote from: nfmax on May 16, 2020, 02:06:42 pmThat's remind me how it done on Windowsto install either specific version of MS C++ tools and Mingw & Co

author: olkipukki
author_rank: Frequent Contributor
timestamp: May 16, 2020, 04:15:14 pm
content: For somebody who still in love with C, but tempted by Python, there is something for you too - calledCpythonhttps://en.wikipedia.org/wiki/Cython

author: bd139
author_rank: Super Contributor
timestamp: May 16, 2020, 04:20:29 pm
content: YuckOn windows you install Chocolatey and then run "choco install python"

author: chriva
author_rank: Regular Contributor
timestamp: May 16, 2020, 04:23:18 pm
content: Quote from: olkipukki on May 16, 2020, 04:08:46 pmI really don't get the mingw stuff. It's just another layer of headache. Is it my stuff, is it the wrapper, is it a windows bug?

author: olkipukki
author_rank: Frequent Contributor
timestamp: May 16, 2020, 04:28:26 pm
content: Quote from: chriva on May 16, 2020, 04:23:18 pmNo, it's clusterf@G

author: bd139
author_rank: Super Contributor
timestamp: May 16, 2020, 04:38:27 pm
content: If you're using mingw you're doing something wrong...

author: chriva
author_rank: Regular Contributor
timestamp: May 16, 2020, 04:40:25 pm
content: Quote from: bd139 on May 16, 2020, 04:38:27 pmAnyone using PS instead of shell gets a thumbs up from me. Miles ahead of the old stuff

author: bd139
author_rank: Super Contributor
timestamp: May 16, 2020, 04:41:58 pm
content: Yeah it's windows terminal + powershell as well. Waaay better. That plus vscode = bliss.I'm mostly using it to write Go and kubernetes manifests at the moment.

author: nfmax
author_rank: Super Contributor
timestamp: May 16, 2020, 04:46:54 pm
content: Quote from: bd139 on May 16, 2020, 04:41:58 pmAna a Gopher client:Quote from: bd139 on May 15, 2020, 12:13:26 pmPlease tell me your program is called 'pher", as in:$go pher

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 16, 2020, 05:04:03 pm
content: Quote from: bd139 on May 16, 2020, 04:38:27 pmWhy not run python3 explicitly?Yeah, the Python 2/3 split, and exactly which interpreter you get when running justpython, is annoying.Quote from: bd139 on May 15, 2020, 12:13:26 pmName itferto ensure maximum.

author: bd139
author_rank: Super Contributor
timestamp: May 16, 2020, 05:12:02 pm
content: It’s called nofur at the moment so half way there.I can run python3 or Python. Does the same thing. I have three different version on this box. Latest is just default

author: Picuino
author_rank: Super Contributor
timestamp: May 16, 2020, 08:17:10 pm
content: To install Python and its associated libraries in Windows it is best to use Anaconda or another similar package.https://www.anaconda.com/products/individualThis way you avoid incompatibilities between versions and resolve dependencies.Why do we need Anaconda when we have pip?

author: Kjelt
author_rank: Super Contributor
timestamp: May 16, 2020, 10:14:44 pm
content: Did this topic morph to a python topic ?

author: bd139
author_rank: Super Contributor
timestamp: May 16, 2020, 10:31:04 pm
content: Python is where it all ends

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 17, 2020, 01:00:56 am
content: Python is on-topic in the sense that the official interpreter, CPython, is written in C, and currently it is easiest to interface to Python via C.Which is one of the use cases I've already mentioned: writing code that can be used from multiple programming languages, without risking runtime library incompatibilities (as may happen with e.g. C++, if your code uses C++ version X and some other code used in the same process is compiled against C++ version Y).

author: Karel
author_rank: Super Contributor
timestamp: May 17, 2020, 07:01:35 am
content: One could say that, without C, other languages can't exist...

author: paulca
author_rank: Super Contributor
timestamp: May 17, 2020, 07:59:27 am
content: Quote from: Karel on May 17, 2020, 07:01:35 amIt's funny. Most of the internet runs on C. Unix/Linux etc is still the dominate OS.When people write business applications in Java/Python/<insert exotic language the kids want to use>. The C folks who write things like Docker, ngix, apache httpd, postfix, sendmail and the Linux OS smile and say, "Aww, bless! Look; they use milliseconds to time things. How quaint."

author: paulca
author_rank: Super Contributor
timestamp: May 17, 2020, 08:08:46 am
content: Quote from: bd139 on May 16, 2020, 02:37:14 pmMac-what? What's that?I have never installed Python on windows in my life. I'm too scared after installing perl once on windows. EDIT: I tell a lie. I do have PyCharm installed, so that counts I suppose.Redhat are arseholes. Some of their install conventions are absolutely bonkers. They modify Java to distribute it according to the FSH and move it all over the place leaving behind dozens of dynamic symlinks to make it look use-able to Java programs. It's moderately annoying when you want to install a version you can get an rpm for, it's massively annoying when you want to install a version you can't get an rpm for. Just unzip the damn tarball, update your JAVA_HOME and you are DONE! Stop the madness! /opt/java/jdk1_8 -> /opt/java/version/jdk_1.8.0_234 if you must.Python on gentoo was better, but there was always the hassle when an upgrade told you that you needed to update every Python module and reinstall everything that uses said modules. The page detailing this is an hours read on their wiki.Gentoo does have it's "Slotting" mechanism and as long as you are paying attention and don't leave upgrading too long, it's fairly usable to have multiple concurrent versions, even minor versions.On shells, I can't deal with CMD it's just rubbish. I can't deal with PowerShell cause it's just a .Net console running on CMD. If you have admin switch on the Linux developer layer in Windows 10 and install whatever Linux you want. Or use cygwin or at very least git bash. Never stoop low enough to be forced to use CMD, in any disguise.

author: dietert1
author_rank: Super Contributor
timestamp: May 17, 2020, 09:59:59 am
content: A compiled language like C/C++ prevails for people who want some IP protection. After that hands-on advice that even elderly people need to learn Python i started looking up some examples, then downloaded pycharm IDE. Then during installation a little panel popped up asking me for the root password. What? Isn't that IDE written in Python?Then i found i already had Python 3.7 on my Debian internet computer and the editor supported syntax hiliting for python, so i enjoyed the examples. Appended my first exercise if anybody is interested.Tried another example with pyqt5, but that complains about super()... Maybe i am invoking another old python.Regards, DieterEdit: The example script2.py worked after i made it invoke python3 instead of python. Besides that i had to install another Debian package with Qt5 bindings for python3 instead of Qt5 bindings for python that i had installed before. Now the first panels appear on my gnome desktop...

author: paulca
author_rank: Super Contributor
timestamp: May 17, 2020, 11:53:51 am
content: super() is valid .. at least in python 3.For example:def evaluate(self, data):state = super().evaluate(data)if not state:return []

author: jfiresto
author_rank: Frequent Contributor
timestamp: May 17, 2020, 12:08:04 pm
content: Quote from: paulca on May 17, 2020, 11:53:51 amUnfortunately, Python 2'ssuper()is wordier and needsevaluate()'s host class:def evaluate(self, data):state = super(Class, self).evaluate(data)if not state:return []Could feeding asuper()without arguments to Python 2 be the issue?

author: paulca
author_rank: Super Contributor
timestamp: May 17, 2020, 12:18:29 pm
content: Quote from: jfiresto on May 17, 2020, 12:08:04 pmProbably, but it reminds me of a great way to troll Python programmers.When they say, "It's object orientated.", reply, "No. It's not.", when they whine and get all uppity point them to the four corner stones of object orientation and get them to tick them off as to which Python supports.Abstraction - Nope. No protection, no formal interface, no "Interface" concept.Encapsulation - Nope. No protection, no internal/private/hidden members, everything is public.Inheritance - Sort of, but without the above it's a bit weak and allows you to do really messed up stuff that you really shouldn't.Polymorphism - Again, sort of, but not really.The fact it has "self" as a function argument to make it an instance method is a sure sign it's not truely OOP. It's OOP-like and only barely.It's not just python though. OOP-like languages include, PHP, C#, Javascript, Perl.

author: bd139
author_rank: Super Contributor
timestamp: May 17, 2020, 12:46:45 pm
content: It’s duck typed. None of those concepts make sense without a static type system.

author: jfiresto
author_rank: Frequent Contributor
timestamp: May 17, 2020, 01:08:36 pm
content: Indeed, the four ideas mostly strike me as specific, implementation requirements to make certain, non-dynamic(?) languages object-oriented.You could very well believe Python is object oriented after reading Alan Kay, who coined the term, or Brad Cox, who brought OO into the mainstream.

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 17, 2020, 02:28:31 pm
content: One way to classify programming languages is by their abstractions (specifically, by the complexity of their abstractions, or how far those abstractions are from how the hardware works in reality). (I actually prefer to classify programming languages by their paradigm, but bear with me here.)At the lowest level, you have assembly languages, which are just different symbolic representations of the underlying machine code, with trivial abstractions like labels instead of addresses.(Anything above that level is up to discussion, however; depending on how you define the complexity of abstractions.)At the next level, you have low-level programming languages. Nowadays (among actively-used programming languages), this includes C, Forth, and Fortran at least.If we look at freestanding C, we find that it is an extremely simple and compact programming language, with its abstractions more like compatibility layer between different hardware architectures rather than abstractions that help human programmers. In comparison, Forth is more abstract, as itbehaveslike a stack-based abstract computer. And Fortran has all sorts of abstractions, including array slicing, that are not "natively" supported by hardware, whose intent is to make "programming" something humans can do without knowing how computers actually work.In a very real way, freestanding C is the "simplest" portable programming language we have.In that sense, it is obvious how and why C is still being used. It is nowhere near perfect, as its "abstractions" – more like hardware compatibility features, really – no longer match the hardware, the hardware having vastly progressed forward, but the low-level programming languages staying stagnant, or justadding toinstead of refining their abstractions/compatibility layers... which should also explain the reason for my own rant at C standard development in this thread.

author: olkipukki
author_rank: Frequent Contributor
timestamp: May 17, 2020, 02:46:37 pm
content: Quote from: paulca on May 17, 2020, 12:18:29 pmLet's keep as is.If someone wants all-in-inclusive package, there are Ada and Esperanto around

author: Karel
author_rank: Super Contributor
timestamp: May 17, 2020, 03:01:50 pm
content: Quote from: Nominal Animal on May 17, 2020, 02:28:31 pmWhen I did my C programming course, it was considered a high-level programming language...The terms high-level and low-level are inherently relative. Some decades ago, the C language, and similar languages, were most often considered "high-level", as it supported concepts such as expression evaluation, parameterised recursive functions, and data types and structures, while assembly language was considered "low-level". Today, many programmers might refer to C as low-level, as it lacks a large runtime-system (no garbage collection, etc.), basically supports only scalar operations, and provides direct memory addressing. It, therefore, readily blends with assembly language and the machine level of CPUs and microcontrollers.https://en.wikipedia.org/wiki/High-level_programming_language

author: paulca
author_rank: Super Contributor
timestamp: May 17, 2020, 03:10:27 pm
content: Wanted to point out, I like Python. I like C, I like C++. I sort of like Java. I like any language that lets me do a job with the least appropriate amount of effort.Monoglots are frustrating. An example:We had a REST API service for registering job batches on a cluster. When I was faced with this, in test, I used a single line of curl to push a new job or update an existing one. The previous monoglotic Java engineers wrote an entire enterprise Java client with really funky non-standard commandline arguments. Why? The curl command takes 30 seconds and can be put into an sh file for later. The java app took a week, runs in about 20 times the time, takes up 100Mb of RAM.You "can" put a screw in with a hammer and you "can" put a nail in with a screwdriver, but doing so just makes you look unskilled.

author: Wolfgang
author_rank: Super Contributor
timestamp: May 17, 2020, 03:14:28 pm
content: ... but if a hammer is the only tool you have then every problem starts looking like a nail ..)

author: paulca
author_rank: Super Contributor
timestamp: May 17, 2020, 03:31:48 pm
content: Quote from: Wolfgang on May 17, 2020, 03:14:28 pmYup. When it really starts to suck though is when they start seeing every nail as a problem as well.

author: madires
author_rank: Super Contributor
timestamp: May 17, 2020, 03:38:26 pm
content: Therefore you should have a toolbox with different tools. Then you can choose the right tool for each job. Or if you have people with only one tool in their toolboxes, then you have to choose the person with the right tool.

author: jfiresto
author_rank: Frequent Contributor
timestamp: May 17, 2020, 03:50:09 pm
content: Quote from: Karel on May 17, 2020, 03:01:50 pmThat must be a more recent, retrospective narrative. I can not think of anyone who considered C to be high-level in the 1980s. Even Kernighan and Ritchie described C as a relatively low level language because of its (favorable) nearness to the hardware. I think everyone learned C from their book – it was so well written.

author: Karel
author_rank: Super Contributor
timestamp: May 17, 2020, 04:01:18 pm
content: Quote from: jfiresto on May 17, 2020, 03:50:09 pmI discovered that book after I did the course which came with Borland Turbo C compiler for DOS....I still have it somewhere (the book, the compiler I throwed it away once I mastered Linux).

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 17, 2020, 04:02:23 pm
content: Quote from: Karel on May 17, 2020, 03:01:50 pmThat's the reason for the 'Nowadays' in there.Things change, we adapt. We learn from the past, but live in today, and prepare for tomorrow.It takes a variety of problems and approaches to solving them to see and understand the value of having many tools.In some ways, I think of C the same way I think of PVA glue (wood glue, plain "white" or "yellow" glue, available in just about every store).It is cheap and simple. Because of that, some think it is "poor". Yet, for the task of gluing long-grain wood to long-grain wood (one of the most common cases, and problematic with many other glues in the long term), it is just about the best thing there is. Not only can you easily make the seams invisible (just clamp them tight, but not so tight you squeeze all the glue out of the seam), but the joint is stronger than the surrounding wood. And it won't fail due to wood movement, like epoxies and cyanoacrylates might, because the joint is slightly flexible. And while PVA glue is over a hundred years old invention, we do have improved on it with various slight changes and additives, that make "variants" for example waterproof after curing.Similarly, I think C has its use cases, and cannot be realistically replaced with something completely different. We could make it better, though; a lot of the hardware we use C on has features that really didn't exist four decades ago. Whether that should be a change to the language itself, or a "sibling language" (similar to Python 2 versus Python 3 being mostly the same but slightly different), I do not know. In all cases, it would need to be as simple and with as few abstractions as C has now, because that is its niche.

author: Wolfgang
author_rank: Super Contributor
timestamp: May 17, 2020, 04:08:43 pm
content: ... just an academic question:If you are allowed to use just *one* language in a large, real world problem ranging from GUI to math to drivers and control, data storage, multiplatform ...what language would *you* choose ?

author: chriva
author_rank: Regular Contributor
timestamp: May 17, 2020, 04:13:37 pm
content: C++...

author: bd139
author_rank: Super Contributor
timestamp: May 17, 2020, 04:19:10 pm
content: Quote from: Wolfgang on May 17, 2020, 04:08:43 pmSteel Bank Common LispEdit: fucking iOS autocomplete got me

author: paulca
author_rank: Super Contributor
timestamp: May 17, 2020, 04:30:12 pm
content: Quote from: Wolfgang on May 17, 2020, 04:08:43 pmI'd leave.But. If it came to that, it would have to be C or C++.

author: JPortici
author_rank: Super Contributor
timestamp: May 17, 2020, 06:11:33 pm
content: C++ hands down

author: olkipukki
author_rank: Frequent Contributor
timestamp: May 17, 2020, 06:29:07 pm
content: Quote from: Wolfgang on May 17, 2020, 04:08:43 pmEnglishIf you know so much, that's enough

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 17, 2020, 07:14:11 pm
content: If you want portability, use Python and Qt5. Qt5 not only provides an uniform look across all operating systems (not exactly "native", but uniform), but also has uniform interfaces to things like network, and serial and usb ports. A carefully written Python application can work as-is on most/all OSes.Unfortunately, Python I/O is not very efficient. If the application works on a lot of data, Python will be slow(er). Also, you do not use Python if the source code is a trade secret. You can license it however you wish, but the end users will be able to read the source code.Finally, the current official Python interpreter, CPython, only runs Python code in one thread per process. You can have multiple threads in the same process, and that is very useful for things like asynchronous I/O, but for heavy math, you need to use process parallelism to max out the performance.If you need OS drivers, in Linux you do it in C. (While technically it is nowadays possible to write an userspace "driver", those are fragile things that to an end user like me, are just turds. I know many members here advocating doing that instead of trying to write a kernel driver, but in myexperience, the userspace stuff just isn't worth the effort. The only exception is "drivers" that use an userspace-exported bus, like USB, Ethernet, Infiniband, or similar.)If you deal with lots of data, and want a graphical user interface, then your choices are basically C or C++. There is only one pure C GUI toolkit, GTK+, that has been ported to all OSes, but it does not provide a "native" use ańd feel on Mac OS or Windows, and outside the POSIX/Unix/Linux world, GTK+ is not well known among programmers. With C++, you have a lot more options available, including Qt; but also things like FLTK, that allows you to do portable GUIs that do look and feel native on different OSes. Some OSes, like Windows, have much better C++ support for their OS and kernel-level interfaces.If I was limited to a single programming language for whatever odd reasons, but still wanted to work on that project, the language I'd choose would depend on the particular requirements of said project, emphasizing the above points.If I was to work on it alone, right now I'd probably go with C and GTK+, developing on Linux, just because in the last few years I've done a lot of POSIXyC, and not much C++, so it'd be less effort for myself personally.If I was to work with other programmers, I think C++ (and Qt for the GUI) would be the best choice.You see, even if limited to a single tool – and this really is similar to asking a builder which tool they would choose, if they had to build a house using just a single tool –, I would still pick the tool based on the problem at hand.(For the house, it'd be a Finnish wood axe, because I could build (a horribly ugly, but livable) log cabin with that; for anything better, I'd need more tools.)

author: IDEngineer
author_rank: Super Contributor
timestamp: May 17, 2020, 11:56:07 pm
content: Quote from: Wolfgang on May 17, 2020, 04:08:43 pmC with a small smattering of C++, because I suspect it would yield the largest Venn diagram intersection of: 1) being available on a large number of diverse platforms, 2) known/supportable by a large number of personnel, 3) close-to-the-metal control and performance when you want it, 4) likely to have the library you're looking for when you don't necessarily need control and performance, 5) probably easiest to interface to some other language if needed/wanted.... the list goes on.This isn't a religious issue for me, I'm just interested in getting the job done with the least hassle. If I had to choose "just one language" that covered everything you said/implied, to me the choice is obvious. YMMV.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 18, 2020, 12:34:03 am
content: Yes, more or less agree with the two above.The "right tool for the job" is all nice, but if you are hypothetically restricted to only ONE language, while having to cover many different levels from low to high, one essential criterion, after making sure the language you choose *can* be used for all the tasks at hand, is that you have an excellent COMMAND of this language. You can't properly cover that many areas if you don't.

author: radioactive
author_rank: Regular Contributor
timestamp: May 18, 2020, 01:41:49 am
content: Quote from: IDEngineer on May 17, 2020, 11:56:07 pmSo, basically C with a small smattering of CS philosophy attached to it.

author: Fredderic
author_rank: Regular Contributor
timestamp: May 18, 2020, 01:46:21 am
content: Quote from: Wolfgang on May 17, 2020, 04:08:43 pmOne that gets far too little mention…D(dlang.org)…Older than most of the new crop (no Google or Mozilla pushing it so little less known), but it's been put to use in a number of large projects… Though it was built around a modern GC, there's ongoing (and already comprehensive) work to make that optional; and most of the standard library comes in at least both allocating and non-allocating forms. If the runtime it drags along is too much for you, the -betterC option pares it back to, pretty much as the name suggests. In general it has ahugeemphasis on code safety even with (as opposed to, IMHO, C/C++'s tendency to pit features against each other) templating, introspection, compile time evaluation, contracts, and most of the other fancy modern dohickeys, wrapped up in a systems level language following the C/C++ train. Most recently that I've heard, they've been adding borrower checking to let it drop many of it's runtime checks, and better support alternative allocators like reference counting. It also strives to bind to other languages, notably being able to invoke C/C++ libraries (with caveats mostly around C++ memory management). The developers are fanatics, even without backing from those huge companies, it's continued to move forward and pick up steam, and it's been fairly solid except for a split early on when they decided to redo the standard library.And to answer the challenge more directly; Disbeing used for GUI (it has it's own, plus bindings several others), web back-end (vibe.d), math (right in the basic language, array/scalar math has SIMD in mind, and others quite readily), drivers (there's an ongoing project to reimplement the Linux kernel in D, starting with the drivers — to bring in D's safety guarantee's, and putting D's system-level claims to the test in the process), control (something in the locomotive industry), data storage (at least one significant product), and multiplatform too (Windows, Linux, Mac, ARM).On a more personal note, and to swing the pendulum to the other extreme, while it's still a little heavy-handed for my favourite 8-bitters, it's move into AVR ųC (generally in betterC mode) looks to be coming along nicely, and on the desktop, I've often found it easier to throw together D code for some quick tasks, than a comparable bash or Python script (runs a heck of a lot quicker, too).

author: radioactive
author_rank: Regular Contributor
timestamp: May 18, 2020, 02:28:57 am
content: Quote from: Fredderic on May 18, 2020, 01:46:21 amI really keep meaning to take a closer look at D. Really does look interesting and worth investigating further (haven't seen a reference to it in some time). Thanks for bringing that up.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 18, 2020, 02:37:03 pm
content: D is an interesting beast - I've looked at it almost since the beginning - almost 20 years ago.A lot of interesting ideas, including modules. Much closer to a decent "upgrade" of C than C++ ever was IMHO.I've unfortunately always stayed away in practice. Not enough people using it, not enough tools supporting it on various targets.These days, GCC includes a D compiler. I tried, but was not able to successfully build a D cross-compiler for ARM (cortex-M), or RISC-V targets, for instance. Still a significant way to go IMO.If any of you manages to get a working D compiler for embedded targets though, please chime in.

author: Fredderic
author_rank: Regular Contributor
timestamp: May 19, 2020, 12:29:57 am
content: Quote from: SiliconWizard on May 18, 2020, 02:37:03 pmThat seems to be a common statement. It also seems like most people who've switched to D, haven't regretted it, but there are indeed comparatively few, and it's a bit of an uphill battle to get there — many of them, started by doing bits of tooling around their main project in D, and once they had a good handle on it, and a successful track record, started to bring that through into the main project. On the upside, if you use the comparable features in C++, D will probably feel like a breath of fresh air.Also of some amusement, watching a "Cpp Chat" episode last night from late last year, one of the guys on the panel mentioned C++'s "if constexpr" was in fact their answer to D's "static if". Thought that was interesting timing that I'd come across that right after posting about D here. That sense they've been chasing D's tail a bit so as not to be left behind…I will say also, since getting to know D, I try to bring a lot more templating and constexpr into my ųC code, and though I have some success, compared to D it's always a fight to get it to work. By the same token, Rust seems to have redoubled D's efforts towards memory safety. It's always been one of their main goals, with @safe being a thing since forever, and the reason they went with a GC — solves a lot of memory-reuse issues right off the bat. But their work on the borrower checker does seem to be on the heals of Rust potentially swooping in and usurping one of their main goals. In turn, Rust's system brings flashbacks of doing GTK+ GUI in C, which what seems like weird for this day and age, considering D's push towards cleaner code… All up, it's a bit like watching a very, very, slow motion 3-way competitive dining event. And it's great!As for D on ARM, LDC seems to be the more reliable compiler there. I haven't done much in that regard myself, or tried cross-compiling D at all for that matter, but LDC's what worked for compiling D code on the Raspberry Pi I have running my home automation, and I've run across other people saying much the same in my searches on the topic prior… It also seems to be the compiler used in the slow push towards smaller AVR's I've been watching… Though I don't really hold out much hope it'll get there in a practical way… As much as I hate to say it, smaller systems just plain aren't on their radar, as much as they need it. It looks at this point, like that'll be a spot where Rust will make itself home, as gruesome and ungainly as it is.Whatever way it plays out, I think the single biggest thing against C/C++, is memory safety. That's an ongoing battle these days, and the main flag being carried by the newer languages. If anything finally kills off C/C++, I think that'll be it.

author: Wojciech Krolopp
author_rank: Newbie
timestamp: May 19, 2020, 06:26:21 am
content: Using C is like driving a car with manual gearbox. It's great fun and about as simple as it can get (only engine, clutch, gearbox, transmission and finally wheels). Sure, you need some practice, you need to think what you're doing but millions of people do it every day safely.Interpreted languages like Python or LISP are similar to modern cars with automatic gearboxes. They are electronic, full of nice features, automation and safety devices but they are also sluggish (because emission regulations!) and lack any fun of driving. And when they break they cost thousands of zlotys for parts like some stupid sensor.I think people who code in Python are the same people who drive cars with automatic gearboxes. They are just clueless and don't want to use their brain. Computer engineer needs to understand what's going on under the hood, otherwise is he an engineer or just monkey who pushes "ok" button?For daily driving I have a 1997 VW Passat B3 that I will use as long as it keeps running and passes yearly inspections. Spare parts are cheap too! I also own ex-military FSR Honker with Polish-made Andoria 4C90 engine that I fixed myself (some rust needed to be welded-over). Honker has zero electronics and is very reliable when you know what to check periodically. It's great car to go camping in remote areas because it will drive almost through everything (like old Land Rovers).Once I had a chance to drive car with automatic gearbox and it was a horror. You have no control over vehicle whatsoever.

author: paulca
author_rank: Super Contributor
timestamp: May 19, 2020, 07:18:40 am
content: Quote from: Wojciech Krolopp on May 19, 2020, 06:26:21 amFirstly. I program Python quite a lot and I drive a manual car, always have. I think your analogue is somewhat lacking in perspective.Them: We are going to write it in python...You: But it's slow!Them: Don't care. Don't need speed.You: But people don't need to understand how it does everything.Them: Exactly.You: But you could write that in C in two weeks man!Them: LOL, You have 1 day.You: .... oh ....

author: Berni
author_rank: Super Contributor
timestamp: May 19, 2020, 07:41:24 am
content: Quote from: Wojciech Krolopp on May 19, 2020, 06:26:21 amI also occasionally program in python but still prefer a manual transmission car. At the same time i like C for when it is appropriate such as MCUs or low level stuff.Python is not designed to do the same thing as C. For example do you rewrite your .sh shell scripts in C so that they would run faster and use less memory?Yes Python commits some serious programming sins in the way code is written in it. But you can't deny its a really quick and easy way of getting stuff done. Go ahead try timing yourself writing a parser for some obscure ASCII file format in C and then time someone else who is used to Python program the same things. Even if the file is 1MB in size both C and Python will parse in the time it takes you to blink. If the file is 10GB in size and you have 1000 of them to parse trough on a daily basis then yeah you might want to go for C so that you don't sit around and wait for it each day. If you only need to run a few 1MB files trough it once, does it really matter if it takes 100ms longer and 2MB more RAM in exchange for the hours more work to program it?

author: bd139
author_rank: Super Contributor
timestamp: May 19, 2020, 07:55:37 am
content: Quote from: Wojciech Krolopp on May 19, 2020, 06:26:21 amIf you're in an accident in your 1997 Passat you are dead.Most people drive like idiots.QED.

author: chriva
author_rank: Regular Contributor
timestamp: May 19, 2020, 07:58:27 am
content: 90's cars are mostly fine. If you drive around in something from the 60's with a stiff window and no collapsable zones I'd agree tho...Nothing wrong with python. The problem is the idiots using it for stuff it's not meant to be used for. Like micropython on microcontrollers. Utterly idiotic...

author: Kjelt
author_rank: Super Contributor
timestamp: May 19, 2020, 08:15:33 am
content: Robert C Martin, Clean Architecture forword, comparing his begin days in the 60s to when he wrote the book in 2016:"And there is one thing more about the software we have now, compared to the software back then: it's made of the same stuff.It's made of if statements, assignment statements and while loops.Oh, you might object and say that we've got much better languages and superior paradigms.After all, we program in Java, or C#, or Ruby and we use object-oriented design.True- and yet the code is still just an assemblage of sequence, selection, and iteration, just as it was back in the 60's and 50's.When you really look closely at thepractice of programming computers, you realize that very little has changed in 50 years."

author: paulca
author_rank: Super Contributor
timestamp: May 19, 2020, 08:17:31 am
content: Quote from: Berni on May 19, 2020, 07:41:24 amFor that there is PySpark. Or Java Spark.

author: cgroen
author_rank: Unknown
timestamp: May 19, 2020, 08:17:49 am
content: Quote from: Wojciech Krolopp on May 19, 2020, 06:26:21 amHmm, so people that program in assembler drives a horse wagon ?I program in C (and have been doing that for 35+ years) but drive a car with automatic transmission, so there goes the idiotic theory....(and I think I would rather be in a car crash in my 3 year old Volvo XC70 than in your 23 year old Passat)

author: chriva
author_rank: Regular Contributor
timestamp: May 19, 2020, 08:21:09 am
content: "Hmm, so people that program in assembler drives a horse wagon ?"More like a spaceship with a million buttons. This is no limit to the insanity you can do

author: Kjelt
author_rank: Super Contributor
timestamp: May 19, 2020, 08:27:42 am
content: There are still some things you can do in assembly and not in C.

author: paulca
author_rank: Super Contributor
timestamp: May 19, 2020, 08:37:16 am
content: Quote from: Kjelt on May 19, 2020, 08:27:42 amExotic segmentation faults for instance.

author: chriva
author_rank: Regular Contributor
timestamp: May 19, 2020, 08:38:42 am
content: Quote from: paulca on May 19, 2020, 08:37:16 amWell.. Is that the language's fault or your own stupidity not comprehending the complexity?

author: Berni
author_rank: Super Contributor
timestamp: May 19, 2020, 08:51:12 am
content: Yep assembler lets you shoot yourself in the foot with even more style than just plain C.Tho programing entire projects in assembler these days...eeeh. You can do everything in C by plonking down some inline assembler sections or linking in a asembler source file. Sure technically its not pure "C" anymore but on the other hand pretty much all C compiles are designed to handle mixing in user supplied assembler code, heck its pretty common to see C startup scripts on MCUs written in assembler. Maybe such a thing makes sense for old stuff like a Commodore 64 where you might not have a C compiler that is advanced and stable enough for your liking.

author: Elasia
author_rank: Frequent Contributor
timestamp: May 19, 2020, 10:32:53 am
content: Quote from: Berni on May 19, 2020, 08:51:12 amIn some pics asm calls are still specifically done for certain functions like unlocking program memory for flashing, gotos etc.. i might even do a super critical / super fast function in asm so its permanent vs any optimizerOtherwise go go embedded C all the way.. i do very little else in my particular niche market

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 19, 2020, 01:35:05 pm
content: Quote from: Berni on May 19, 2020, 07:41:24 amPython's built-inCSV parseris particularly useful when interfacing to spreadsheet programs in a generic fashion; theDictReaderand DictWriter in particular can make short work of many types of problems.I do have roughly equivalent functionality with C code I've written myself (and that too handles the RFC 4180 oddish double quote rule:foo "bar" bazquoted is"foo ""bar"" baz"), but it takes a lot more code; plus, the Python code is simple enough to give to a new/non-programmer user, and they can do minor alterations to it themselves. Not so with the C code.Plus, you can add a PyQt5/PySide2 Qt GUI interface on top of it, and it'll work as-is on all major OSes, with just a couple of dozen lines of code; and code that is simple enough for nonprogrammers to understand.That is a perfectly valid niche. I claim so, because I've used it that way myself, successfully.(A lot of web-based services nowadays can output (authorized) parts of their database in CSV format, by the way. Using a CSV helper program – one that can be run as-is on different OSes – can munge those in a format that makes it vastly easier for not-very-technical users to do their work on it in a spreadsheet program. And that is not just papering over "lack of knowledge", either; it can apply policy, like anonymize data, and even do it in a reversible way. Such things are sometimes required by politics or internal guidelines – if by law, it must be included in the service itself – and being able to implement such quick tooling can make a big difference in practical operations office culture. Just remember to add Branding, so your work isn't forgotten the moment it is no longer needed.)Many classical (as in using potential models and not quantum mechanics) molecular dynamics simulations produce snapshots of the simulated system in a text-based format. When simulating large systems, they can literally spew this data like from a firehose. It turns out that with RAID storage systems, the bottleneck isn't I/O,but I/O parsing routines in the standard C library. I've written parser routines for that case too, working thus far at full I/O rates.Of course, the proper solution to that was to have the simulators output the data in more concise format, preferably using as little CPU time as possible. One such I wrote for Fortran, that allowed storing the data in binary locally (and thus reducing network traffic, speeding up the simulation itself slightly), with Fortran and C tooling that allows slicing that data (across multiple files) in time and space. No, I wasn't clever enough to name it Tardis. (Although "Istard" would've been even more my style.) The simulator was written in Fortran, and that particular simulation worked with almost 200 million atoms. That's roughly 5 GiB of data per "frame" (snapshot of simulation at one moment). I think the dataset, when compressed, did fit a 2 TiB drive.Sometimes you get to choose the language you use, sometimes you don't because you are maintaining or developing a mature project.The cost of time spent to develop a solution is often overlooked, but it really is important, and can go either way. A funky addition of a couple of hundred lines of Fortran 95 code can make a project possible, or turn it from a month-long research project (per run) to a week-long one; but you might need a semi-crazy programmer to know whether it is even possible, and how. Letting the programmer choose their favourite language instead of the most appropriate one may turn a one-day project into a multi-month one, because fun is fun, and sometimes the objective is forgotten when you're having too much fun.

author: paulca
author_rank: Super Contributor
timestamp: May 19, 2020, 02:00:35 pm
content: The one thing that puzzled me with Python was that it lacks basic JSON support built in. The is the "json" package and a few hacks you can do with the __dict__ member, but I honestly expected it to have amazing built in JSON marshalling support.

author: bd139
author_rank: Super Contributor
timestamp: May 19, 2020, 02:28:43 pm
content: It does have basic JSON stuff built in. I use it all the time. Part of the core libraries:https://github.com/python/cpython/tree/3.8/Lib/json

author: Berni
author_rank: Super Contributor
timestamp: May 19, 2020, 02:44:07 pm
content: Quote from: paulca on May 19, 2020, 02:00:35 pmThat's because Python is designed to keep actual features packaged in libraries while the core language just provides some basic core data types. Not everyone likes json, maybe they want xml instead, or maybe they like pythons own proprietary binary format. But it is part of the standard library so technically its included in the language. And if you need to do something not included in the standard library its typical practice so simply "pip install x" some X library that does that thing.But yeah if i need performance on a PC i typically just resort to C# since it can run almost as fast as C in most cases but still provide all the handy libraries for easily getting things done, even if its just boring string manipulation. Yes i know oldschool C also provides string manipulation in its standard library, but its really lacking compared to modern languages (Really feels like a chore working with strings there)

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 19, 2020, 02:48:50 pm
content: Quote from: paulca on May 19, 2020, 02:00:35 pmWhat do you mean? Thejsonmodule is built-in, a part of Python standard library. (That is, I do not understand what the problem is – unless it is that Python does not use JSON as the native serialization format – and a quick glance at the python-list mailing list didn't immediately show any discussion related to this. I'd like to know more.)(Ninja'd by bd139 above!)Std 90, also known asRFC 8259, is only 2.5 years old at this point, and the native serialization support in Python uses thepicklemodule (themarshalmodule is used for compiled .pyc files). The pickle format itself, as of this writing, is in its sixth variant already.In general, I've never trusted pickling, because I do not like to serialize code: it tweaks my paranoia way too much, being such a risky thing to do unless completely sandboxed. Using theeval()function (with custom globals and locals, to evaluate user-specified expressions – especially math) is my limit. In that sense, JSON serialization is better, because it does not support serializing Python code, unless you add such support yourself.

author: paulca
author_rank: Super Contributor
timestamp: May 19, 2020, 03:01:36 pm
content: Have you tried to use the json package? It's completely rubbish. Generates pages of boiler plate code and is pretty much just a bare bones parsing thing where it's up to you to do the actual marshalling. Often involving hacks with __dict__ and namedtuples.Or maybe I used it wrong. All I wanted was to say. "Here is some JSON, please give me a Python object with that data populated."In Java, while much heavier weight, things like JacksonBind or Sparks Encoders will serialise in and out of JSON with nothing but annotations on a value class.Example of python:Code:data_str=data.decode("utf-8")datums = Datum.jsonToDict(data_str)Fine, but I have to implement jsonToDict() as:Code:@staticmethoddef jsonToDict(data):ts = json.loads(data, object_hook=Datum._json_object_hook)datums = {}for t in ts:if "timestamp" in t._fields:timestamp = t.timestampelse:timestamp = "0"datum = Datum(t.key, t.name, t.shortName, t.value, t.type, t.units, timestamp )datums[t.key] = datumreturn datumsI also have to implement the object_hookCode:@staticmethoddef _json_object_hook(d):return namedtuple('Dict', d.keys())(*d.values())So only one line is actually helped by "json".For an untyped language with dynamic member creation at run time it's a bit shit TBH. Going a few more steps to ORM would have been nice.

author: bd139
author_rank: Super Contributor
timestamp: May 19, 2020, 03:11:18 pm
content: Yeah aware of that. TBH you're probably expecting a bit much out of JSON there. It's pretty loosely typed and so is python so there is no serialization contract. Everything is runtime inferred. You get the same problem using python's pickle stuff as well.This is one reason I use protobufs / gRPC for communication these days. Explicitly define the contract and generate the serializers etc. That gives strong contracts, strong type inference, portability of wire and disk formats and contract versioning.tl;dr: JSON is fucking shit. Avoid it like the plague.

author: paulca
author_rank: Super Contributor
timestamp: May 19, 2020, 03:19:50 pm
content: Quote from: bd139 on May 19, 2020, 03:11:18 pmHorses for courses, but JSON is both machine consumable and human consumable. It's very loosely typed, or barely typed at all, but XML is far, far, heavier.When a service goes tits up at 3am and it used JSON (say REST) you can poke it with a stick in a terminal without needing header files and a compiler or a suite of utility clients. It's also, like XML standardised and fully standalone/introspectable.I'm old enough to remember people starting to run scared from binary format and old enough to remember why. So when I see proto-buf and RPC returning, get the popcorn and listen to Cherly bassy - history repeating.

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 19, 2020, 04:59:38 pm
content: Quote from: paulca on May 19, 2020, 03:01:36 pmOnly to and fromdicts, server-side talking to ajax. And when I do that stuff, my mind is already bifurcated into two antagonists (one trying to implement the thing, another trying to misuse it), so I tend to not notice developer un/friendliness, unless the language/library actively fights me.It is interesting to note, however, that JS objects best correspond to Python dicts (orderedDicts prior to version 3.8 ), and not to Python objects per se.In fact, the two even have the same syntax in the two languages... which might explain why using JSON on Python objects is not comfortable/intuitive: the way those who use a lot of JSON in Python envisioned the json module to be used, would be mainly with dict/orderedDict objects.This is exactly the paradigm difference I've mentioned in other posts, and others have called "writing X in Y" (with X and Y both programming languages). It is not necessary for "object" to correspond to "object" in another programming language. Here, it just happens that the general equivalent of JS objects is not a Python object, but a Python dict, behaviour-vise.Note that this is a pitfall anyone with any amount of experience can fall into, because we humans are instinctive extrapolators, and are particularly susceptible of missing these unless we are aware of this pitfall. Me myself, I've had to climb out of these often enough, and instead of asking "what in Y is like Z in X" (with Y a class or function name, and X and Y prohramming languages) I've had to learn to look atbehaviourandfeaturesinstead of assume analogous behaviour based on name or hierarchy!In theory, that should be annoying (because it means the definition of "object" is now highly dependent on the context, and not like you were taught in school/course/book). Me myself, I don't mind, because I am aware of my limitations, and finding those different approaches allow me to overcome and exceed my own built-in limitations; to grow. You know, knowing how and why others see a different thing when looking at the same thing I am, tells me a lot about what my own limitations are, and how to overcome them. I like that a lot.

author: 2N3055
author_rank: Super Contributor
timestamp: May 19, 2020, 07:36:01 pm
content: Quote from: bd139 on May 19, 2020, 03:11:18 pmproto3 I presume ??

author: bd139
author_rank: Super Contributor
timestamp: May 19, 2020, 07:53:00 pm
content: Correct

author: paulca
author_rank: Super Contributor
timestamp: May 20, 2020, 06:44:20 am
content: Quote from: Nominal Animal on May 19, 2020, 04:59:38 pmI realised that, at least to some extent and if memory serves me I only created the value objects (Datum in my example) because I googled how to use the json package and it started telling me I needed Encoders and JSON hooks.My current protocol sends a dict of named dicts. eg. {"foo": {"...":"..."}, "bar": {"...":"..."}}But when I went to the docs I ended up getting into what I have now.Even reading this, it's horrible to be honest. It looks like a hacky undergraduate project to parse JSON.https://docs.python.org/3/library/json.html

author: Wojciech Krolopp
author_rank: Newbie
timestamp: May 20, 2020, 06:55:41 am
content: Quote from: Nominal Animal on May 19, 2020, 04:59:38 pmThe object oriented definitions are somewhat constrained, I mean we're not picking the same things. For instance, there's the "inside of the egg" reference, which seems to refer to the whole egg. However, it also happens to also say, "inside the sheet", which seems like an absolutely generic definition for the purpose of recognizing an object. No, I am not going to be able to tell you why it's a challenge to watch your choices and interpret them without trying to come up with a rational explanation as to why you made the decision you did. Maybe some people need that. But here's the thing: we don't have to be everyone's victim. It's really not that big of a deal to point out that the definition of "object" is silly and inconsistent. I think it's a good thing to consider, and that your own limitations are a very good thing to know about, especially in part with a deep understanding of the problem domain.

author: paulca
author_rank: Super Contributor
timestamp: May 20, 2020, 10:31:39 am
content: So I went back to look at the json module again.It seems it works fine deserialising to a Dict. So I can probably get rid of the hooks, drop my class type or create a class type which takes the dict as it's constructor arg, so it can handle default values for fields.Code:aDict = json.loads('{"garageTemp": {"key": "garageTemp", "name": "Garage Temp", "shortName": "GR", "value": "13.12", "type": "float", "units": "\'C"},"pressure": {"key": "pressure", "name": "Air Pressure", "shortName": "AP", "value": "1012.98", "type": "float", "units": "Hpa"},"humidity": {"key": "humidity", "name": "Humidity", "shortName": "HM", "value": "65.36", "type": "float", "units": ""}, "outdoor": {"key": "outdoorTemp", "name": "Outdoor Temp", "shortName": "OD", "value": "12.94", "type": "float", "units": "\'C"}}')aDict['garageTemp']{'key': 'garageTemp', 'name': 'Garage Temp', 'shortName': 'GR', 'value': '13.12', 'type': 'float', 'units': "'C"}

author: emece67
author_rank: Frequent Contributor
timestamp: May 21, 2020, 04:58:27 am
content: .

author: westfw
author_rank: Super Contributor
timestamp: May 22, 2020, 03:35:39 am
content: I feel like C++ has becomeSomewhat Arduino-like in that people don't write "C++ programs" - they go out and hunt down libraries and examples that are close to what they want, and work from there. "Oh, you want Boost, and the Boost extension for lambda expressions, and the XYZZY ray-tracing library, and the ZZZ front end for importing data, and ..."The language itself is a sort of "Computer Science Language For Computer Scientists who write libraries", which SO much stuff added to it that seems so far off in the ether: "abstracted N-dimensional graphs using lambda expressions; and improvement of Boost" (yeah, I'm picking on lambda expressions...)There's a cult following who won't like your C++ programs unless they've become completely unintelligible to people expecting to see actual code."That's not C++, that's Just C With Classes - you're not even using the STL!I keep seeing presentation "advantages of C++ in an embedded environment", where they keep listing features that have also been in almost all C compilers as well ("inline"? TGtbKM!)C++ proponents tend to be blind to needs of embedded and speed freaks - "named address spaces" were apparently explicitly rejected, for example. There's a lot of "C++ doesn't have to bad code for embedded; just avoid certain features", but not a lot of alternatives (STL almost immediately gets you dynamic allocation...)I pretty much like the level of C++ used in Arduino and other "careful" embedded projects. And I would certainly consider "real C++" for anything like implementing a GUI application on a desktop. But not everything is an object, and I don't necessarily need all of the new ways to shoot myself in the foot (I have plenty!)

author: kamtar
author_rank: Regular Contributor
timestamp: May 24, 2020, 02:55:01 am
content: I use C++ for all my embedded projects (which are ARM only)You just need to understand it well and know which abstraction costs what, then there is really no disadvantage in comparison to C.Because I'm dealing with tons of code that is shared through dozens of different MCUs and boards C++ became an irreplaceable tool for me.I don't really see the reasoning behind arguments mentioning stl, then don't use it and just stick with C libraries.Switching to C++ isn't about writing everything in a modern C++ but about not being afraid and using features from it you feel might be useful for you.

author: rgarito
author_rank: Regular Contributor
timestamp: May 24, 2020, 08:51:30 am
content: My very well-known employer's bread-and-butter networking gear code is all written in C with a little Assembler sprinkled in. (I'm one of the engineers) It's equipment that you are literally using every day if you are on the internet, being about 80% of the largest companies in the world are our customers... A small portion of our GUI code (backend to a web page GUI) is C++. The entire system is FreeBSD-based (with a heavily-modified kernel) which explains the C. Being such a large system, there is also a small amount of various scripting languages (bash, python, awk, perl, etc).I also do side work on embedded CPU's primarily as part of an LCD controller project. STM32 CPUs (mostly H757 nowadays, but also F429 and a few others). All C-coded. Primarily because that's what ST based the HAL on.

author: rsjsouza
author_rank: Super Contributor
timestamp: May 24, 2020, 01:33:35 pm
content: Quote from: westfw on May 22, 2020, 03:35:39 amInteresting; that is how I see Python: get code from somewhere... Pip away until you get all the libraries you need.Quote from: westfw on May 22, 2020, 03:35:39 amI agree, but to be fair I see that with C as well, especially with embedded. Modern compilers do a much better job reducing a somewhat lenghty (but legible) code but developers fall to the temptation to write cryptic constructs with the same effect. Perhaps to showcase how smart they are? Or job security?Quote from: westfw on May 22, 2020, 03:35:39 amI've seen lots of these presentations as well, and it feels as trying to push hard a soluion to a problem that already has a reasonable enough solution. C++ loses its major strengths of abstraction and code reuse when it is stripped from the most memory hungry and processor intensive functions.For me, I couldn't yet find a killer scenario for embedded that would only be possible to implement in C++ (or it would bring an unmatched advantage) apart from a GUI development.

author: coppice
author_rank: Super Contributor
timestamp: May 24, 2020, 01:49:10 pm
content: Quote from: rsjsouza on May 24, 2020, 01:33:35 pmDon't you realise that every parenthesis is sacred, and only to be used when all alternatives have been exhausted?

author: Wolfgang
author_rank: Super Contributor
timestamp: May 24, 2020, 01:55:49 pm
content: I am not really religious about languages but a key criterion is memory management.On an ARM, large platform, whatever, C++ is fine. OK, you also should use STL, it willdo a lot of dynamic memory juggling, but so what as long as you have enough space and time.On small controllers like Arduino, IMHO, C++ is off target. With the very little RAM available,you have to always know how much space you have, when its allocated and when its freed.Better forget about any dynamic memory, avoid String classes, and whatever uses it. Littlestack space is OK, keep constants in code space, use global vars when needed, ...all the dirty tricks. But, most important, there is no "out of memory" message in an Arduino.When stack and heap (or even static memory) collide thats just a crash in the best case,in the worst its unrepeatable errors. And you cannot debug that. IIRC there is not even an STLon an Arduino (would probably need all RAM just for itself).

author: rsjsouza
author_rank: Super Contributor
timestamp: May 24, 2020, 02:18:20 pm
content: Quote from: coppice on May 24, 2020, 01:49:10 pmAnd what makes me frustrated is to see that any IDE or editor worth its salt highlights the matching parenthesis, brackets, curly braces, etc., making these "savings" even less worth.

author: nuclearcat
author_rank: Unknown
timestamp: May 24, 2020, 02:20:58 pm
content: Quote from: Wolfgang on May 24, 2020, 01:55:49 pmIf you use C++ in a way that uses C++ features minimally (for example just C++ classes), you can actually use equal amount memory with same efforts.This article is in russian:https://habr.com/ru/post/347980/, but google translate might do job.At the end author come to almost same stack/flash numbers, but C++ code is much more concise and readable.I think there is no need to say that the probability of an error in such code is much less.But there is a simple reason to use C-only - MISRA and alike. C++ is just no-go in such applications.

author: madires
author_rank: Super Contributor
timestamp: May 24, 2020, 02:52:46 pm
content: Quote from: rgarito on May 24, 2020, 08:51:30 amThat's an area where you have to deliver fast and efficient software, otherwise you would lose customers, And from experience I know that the differences in performance between competitors can be huge. At the same time something contrary is happening at the OSS side. Lots of slow Python to manage the network elements. Professional bodge-ware.

author: Wolfgang
author_rank: Super Contributor
timestamp: May 24, 2020, 02:57:01 pm
content: I you exclude all C++ goodies (inheritance, STL, constructors and destructors, ...) the question is why you should use it then on a small platform (e.g., Arduino) at all. Just to write classes and methods instead of structs and functions is then more like syntactic sugar.The code there is size limited anyway, and it *is* possible to write decent code in whatever. Its more a "Torvalds" platformwhere he always want so foresee what code the compiler will create of his sources in order to keep contol.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 24, 2020, 03:33:50 pm
content: Quote from: Wolfgang on May 24, 2020, 02:57:01 pmI agree with this.Some people seem to like the syntactic sugar though.I usually use a naming convention with a prefix, so it's really a matter of sugar indeed.For instance:Code:void GPIO_Set(void){...}GPIO A;GPIO_Set(A);(or: GPIO_Set(&A), depending on how GPIO is defined exactly.)in C++ you'd have something like:Code:GPIO::Set(){...}GPIO A;A.Set();Cute, but that's sugar. Not even *that* much more compact. Thing is, C++ will tend to make you structure your code "better", whereas in C, you'll need more discipline for a similar result. To some it's not a problem at all, but I must admit I have witnessed a LOT of developers truly lacking discipline.One aspect of C++ some developers seem to like in embedded settings are templates. Whereas they are arguably "better" and a lot more featureful than macros, they can also be a nice opportunity for shooting yourself in the foot, so I'm not sure I'm completely sold. Never had that much trouble using macros, as long as they follow some rules, are clear and don't have unwanted side-effects.As some of us have already said, the crux of the matter is to define a subset of C++, with every developer using a slightly different one, and no real standard or hard guideline for choosing one.

author: Picuino
author_rank: Super Contributor
timestamp: May 24, 2020, 04:25:58 pm
content: For me, the discipline of programmer matters, and is more important than language itself.In C you can do things like this flight simulator:Code: (c)#include <math.h>#include <sys/time.h>#include <X11/Xlib.h>#include <X11/keysym.h>double L ,o ,P,_=dt,T,Z,D=1,d,s,E,h= 8,I,J,K,w,M,m,O,n,j=33e-3,i=1E3,r,t, u,v ,W,S=74.5,l=221,X=7.26,a,B,A=32.2,c, F,H;int N,q, C, y,p,U;Window z; char f; GC k; main(){ Display*e=XOpenDisplay( 0); z=RootWindow(e,0); for (XSetForeground(e,k=XCreateGC (e,z,0,0),BlackPixel(e,0)); scanf("%lf%lf%lf",y +n,w+y, y+s)+1; y ++); XSelectInput(e,z= XCreateSimpleWindow(e,z,0,0,400,400,0,0,WhitePixel(e,0) ),KeyPressMask); for(XMapWindow(e,z); ; T=sin(O)){ struct timeval G={ 0,dt*1e6}; K= cos(j); N=1e4; M+= H*_; Z=D*K; F+=_*P; r=E*K; W=cos( O); m=K*W; H=K*T; O+=D*_*F/ K+d/K*E*_; B=sin(j); a=B*T*D-E*W; XClearWindow(e,z); t=T*E+ D*B*W; j+=d*_*D-_*F*E; P=W*E*B-T*D; for (o+=(I=D*W+E*T*B,E*d/K *B+v+B/K*F*D)*_; p<y; ){ T=p+i; E=c-p; D=n-L; K=D*m-B*T-H*E; if(p +w[ p]+p== 0|K <fabs(W=T*r-I*E +D*P) |fabs(D=t *D+Z *T-a *E)> K)N=1e4; else{ q=W/K *4E2+2e2; C= 2E2+4e2/ K*D; N-1E4&& XDrawLine(e ,z,k,N ,U,q,C); N=q; U=C; } ++p; } L+=_* (X*t +P*M+m*l); T=X*X+ l*l+M *M;XDrawString(e,z,k ,20,380,f,17); D=v/l*15; i+=(B *l-M*r -X*Z)*_; for(; XPending(e); u *=CS!=N){XEvent z; XNextEvent(e ,&z);++*((N=XLookupKeysym(&z.xkey,0))-IT?N-LT? UP-N?& E:&J:& u: &h); --*(DN -N? N-DT ?N==RT?&u: & W:&h:&J); } m=15*F/l;c+=(I=M/ l,l*H+I*M+a*X)*_; H=A*r+v*X-F*l+(E=.1+X*4.9/l,t=T*m/32-I*T/24)/S; K=F*M+(h* 1e4/l-(T+E*5*T*E)/3e2)/S-X*d-B*A;a=2.63 /l*d;X+=( d*l-T/S*(.19*E +a*.64+J/1e3)-M* v +A*Z)*_; l +=K *_; W=d;sprintf(f,"%5d %3d""%7d",p =l/1.7,(C=9E3+O*57.3)%0550,(int)i); d+=T*(.45-14/l*X-a*130-J* .14)*_/125e2+F*_*v; P=(T*(47*I-m* 52+E*94 *D-t*.38+u*.21*E) /1e2+W*179*v)/2312; select(p=0,0,0,0,&G); v-=(W*F-T*(.63*m-I*.086+m*E*19-D*25-.11*u)/107e2)*_; D=cos(o); E=sin(o); } }https://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest#Flight_simulatorVery beautiful and compact but unintelligible. An example of flexibility of C language and its ability to adapt to all kinds of rules, even ones that should never be followed.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 24, 2020, 05:53:45 pm
content: Quote from: Picuino on May 24, 2020, 04:25:58 pmBeautiful if you like ASCII art, but otherwise, meh.The above is typical of IOCCC, but not per se typical of C. You could write something similar in C++, and in a handful of other languages, as (from what I've quickly read) it's mostly an exercise in formatting code, using non-helpful identifiers and "optimized" expressions. Some IOCCC code sources make heavy use of weird macros, which is even more unreadable, but even that is mostly doable in any language supporting macros. Even with clever templates I guess you could write pretty weird-looking stuff.Any language not enforcing any specific formatting of code or naming conventions could pretty much lead to this kind of code.You could say that Python (even if I for one don't like the concept of meaningful whitespaces) makes weird formatting of code almost impossible. So, it's probably harder to obfuscate Python code, at least this way.

author: Wolfgang
author_rank: Super Contributor
timestamp: May 24, 2020, 06:21:50 pm
content: Quote from: SiliconWizard on May 24, 2020, 05:53:45 pmI call this style of programming a Koan ( japanese lyrics). Nice to watch but ultimately futile and an elegant waste of time.BTW, the unsurpassed master language of all Koans is good old IBM APL.

author: Picuino
author_rank: Super Contributor
timestamp: May 24, 2020, 07:01:18 pm
content: You can also obfuscate Python if you want:https://wiki.c2.com/?ObfuscatedPythonCode:print ''.join('%(pre)s%(num)s %(bot)s on the wall, %(nul)s %(bot)s,\n%(tak)s\n' % (lambda c,b:{'pre':['','%s %s on the wall.\n\n' % (c,b)][abs(cmp(c,'Ninety-nine'))],'num':c, 'nul':c.lower(), 'bot':b,'tak':['Go to the store and buy some more... Ninety-nine %s.' % b,'Take one down, pass it around,'][abs(cmp(x,0))]})((lambda x,o: [(['Twenty','Thirty','Forty','Fifty','Sixty','Seventy','Eighty','Ninety'][x/10-2]+'-'+o.lower()).replace('-no more',''), o][int(x<20)])(x, ['No more','One','Two','Three','Four','Five','Six','Seven','Eight','Nine','Ten','Eleven','Twelve','Thirteen','Fourteen','Fifteen','Sixteen','Seventeen','Eighteen','Nineteen'][[x,x%10][int(x>=20)]]),'bottle%s of beer' % ['','s'][abs(cmp(x,1))])for x in xrange(99,-1,-1))This means that language by itself cannot prevent the programmer from doing outrageous actions, nor can it avoid the programmer from being very clean and systematic.Programmers make clean, standards-based programs, not languages.You can make good C or C ++ programs, it depends on the rules you follow. And you can make bad and poorly maintainable programs in both languages. It depends on the team of programmers and the rules.

author: Berni
author_rank: Super Contributor
timestamp: May 25, 2020, 08:07:35 am
content: Quote from: SiliconWizard on May 24, 2020, 03:33:50 pmWhere C++ syntax sugar is more effective for sweetening the code is when something has to maintain its own state and perhaps exist in multiple instances.Code:MasterSPI spi1(REGS_SPI1, 1000000);spi1.write(0xAA);Where as back in C one would have to do:Code:SPI spi1;spiInitMaster(&spi1, REGS_SPI1, 1000000);spiWrite(&spi1, 0xAA);This is the usual "C with classes" use of C++ to hide a struct under a fancy looking table cloth. Any decent C++ compiler should generate similar machine code for both of these, but the C++ version looks nicer and is less error prone. Fancier stuff like inheritance can be done by sticking structs in structs, virtual/override functions can be done with function pointers...etc it all just looks uglier in C but works much the same.Still its the programmers job to keep the code organized, the language just potentially gives him more tools to do so. The only issue with C++ is that it gives him a whole mechanics shop worth of tools but they never learn what all the tools are for, instead they figure out how to use some of them and then use those tools to do everything. As a result the tools get abused for doing things they ware never meant for, then the next guy come along and knows a different set of tools so the ones he used make no sense to him. But when all you get is a single tool belt with just the essential tools hanging of it then everyone will know what each tool is for and how to use it (like in C).

author: shangaoren
author_rank: Regular Contributor
timestamp: May 25, 2020, 08:33:57 am
content: Both languages are compiled languages, comparing two well written programs will result in a equality in terms of size and performance.I use c++ for embedded application, i really like constexpr, template and OO programming, i feel it more flexible but there is nothing that can't be done in C, it's just i prefer C++.The debate of STL is not meaningful as there is no such thing in C, IMO it's an "additionnal framework" you can do c++ without using STL.STL needs to be avoided for memory allocation in embedded application just like string and printf in C ...Any language can tend to crap if written by a bad programmer ....

author: JPortici
author_rank: Super Contributor
timestamp: May 25, 2020, 10:26:55 am
content: Quote from: rsjsouza on May 24, 2020, 01:33:35 pmI'd be tempted to say the first. It's not easy to admit that the compiler can be smarter than you, especially if you used to program with -O0 (ages old XC8 in Free mode cough cough..) and/or write cryptic code so you keep thinking you can write better assembly.

author: paulca
author_rank: Super Contributor
timestamp: May 25, 2020, 08:03:40 pm
content: On C++. I had to create a static class variable. The initialiser syntax is absurd. It's like they thought, "Which parenthesis have we used least? Give it some exercise."String MyESPDeviceClass::firmware{ String("") };Wha?!? It works, but it makes no sense.... and don't even get me started on class/object initialises versus constructors. My head melts.