You can forget to write a using statement. In C++ you can omit your destructor entirely if all the members are already RAII classes, whereas in C# you still need to write a .Dispose() method.
Memory management is by and far the vast majority of resource management in C++ for me, which C# takes care of with garbage collection - so I don't miss RAII too much in C#. But if you tried to give me a C++ with using blocks but no RAII (read: you gave me C) I'd scream.
RAII is no panacea - I'd say C#'s manual resource burden without RAII is still less than C++'s with RAII. Which is why I don't miss it too much. But it'd still be a nice addition. And I missed it dearly during my initial adoption of C#.
 e.g. in C++, you still have to worry about reference cycles, implementing the RAII constructs in the first place if existing ones aren't suitable, ensuring parents are kept in scope while referencing children, etc..
Even ignoring personal taste: I care about MSVC. I also care about clang. GCC is the one compiler I'm able to not care about.
> IMHO new C code should be using the gcc cleanup extension
Even if I didn't care about MSVC, I'd disagree.
I'm OK with extensions that are "harmless" in that the program will still run without them working if I #if them out on other compilers - error pragmas, deprecation annotations, static analysis hints, pre-C++11 override keywords, etc.
I'm not OK with self inflicting vendor lock-in for something as important as cleanup rely on a specific compiler's extensions - especially not when we have a perfectly standard, portable, significantly better tested (and thus less likely to have bugs) reasonable alternative in the form of C++ destructors.
If I'm not using C++ destructors, it's either because:
1) I'm doing small changes to an existing C project (in which case I'd be stylistically inconsistent with it's preferred cleanup patterns for minimal gain, since it almost certainly doesn't use the gcc cleanup extension)
2) because I can't rely on having decent C++ compilers on my target platforms (which means I can't rely on having GCC either, and thus can't rely on the gcc cleanup extension by definition.)
> For what its worth, it is only MSVC without support.
How recently? I've been enough versions back that clang documented pragmas haven't been available. The cleanup attribute... I can only find docs for GCC. Although I see LLVM bugs for it, so you're right about clang supporting it - at least on HEAD.
> gcc compiler extensions are otherwise still rather portable.
Portable or not, I'd say only about half the extensions I've sought out on clang have actually been available. If that.
> To clang and icc at least.
I should note in scenario #2 above I don't have these available either, since these are decent C++ compilers.
It's interesting that ARM32 has conditional execution and I like them a lot for writing readable assembly code. Short jumps that result from a simple if can be encoded in three successive instructions, no branches.
However, it's now falling out of favor (mostly gone from ARM 64) and apparently it's due to the relative cost of putting conditional execution on the die vs. relying on smarter compilers.
I think ARM64 dropped predicates to remove excessive flags-register read ports. Nearly every instruction could read flags register and this limited core frequency (critical path), opportunities to out-of-order execution (and register renaming). Not sure though, maybe someone who knows more about OoO on ARM64 could fill me in?
I am sorry you suffer from the dongle collection woes too. The only reason I can see to buy expensive dongles are the ones that have a big blob of RAM on them for quickly reading debug output from the chip without slowing it down, and ones that can adapt to highly exotic voltages and pin outs automatically. But usually the software for these only work in windows, have secret drivers, and are NOT worth 2 thousand dollars.
Xilinx and Altera would not have to give up their custom algorithm. It is like building GCC instead of using Intel's compiler. We just want to know what the chip's instructions are, we will find a way to make it optimal ourselves.
In the microcontroller world, expensive debug dongles are essentially hardware keys for the software included. Lauterbach's Trace32 for instance don't even have software keys, the license for their very extensive debugging software is stored in the dongle itself.
Another piece of software that isn't often mentioned in these discussions is the driver for the embedded flash memory inside parts. USB has quite poor latency (1ms) and flash peripherals require quite a few read-modify-write operations, which soon adds up. More expensive JTAG dongles can run these operations locally on the dongle, with USB just for bulk data transfers, or even download and run code on the target itself for even lower latency, greatly increasing download speed. Since this software needs to be tested for each target, requiring a physical chip to be bought, this gets very expensive to develop. Even a "cheap" dongle like the Segger J-Link has an incredibly long list of targets, and I suspect a substantial amount of the purchase price is in engineering and testing flash drivers for those.
ARM seem to be trying to solve some of these problems in the ARM world with CMSIS-DAP, an open standard for JTAG/SWD dongles USB protocol. It uses USB HID, so no drivers should be needed on any platform, and they have even created an Apache licensed implementation, which Freescale are now using in their FRDM boards.
I had no idea some companies went so far as directly making their debugger the software key. That is intense but makes a lot of sense.
In the case of the Xilinx Platform Cable I wrote firmware to, they have a CPLD that does the JTAG writing of data, and a Cypress FX2LP handling the USB information. They use a quad buffered USB endpoint to let the PC load as much crap as possible into USB and in my experience the buffer fills up fast and the jtag work takes the time. Of course this is only because multiple 'pages' were preloaded, otherwise the delay to request more pages would be insane.
Are you talking about the flash driver for loading external SPI flash? If so you likely know this but you have to load the FPGA with a program to load the flash with the program you want the FPGA to load on reboot. Each of these programs have to be compiled and tested per chip.
While looking through OpenOCD I found they had drivers for the actual flash, and I am not sure if this is required for the fpga flash boot strapper I just described.
I will look over these links. I recently started messing with ARM chips and they are programmed very differently than FPGAs so I have some stuff to learn on that.
>Are you talking about the flash driver for loading external SPI flash?
I was slipping into talking about ARM microcontrollers there, which have internal flash. Reads from it are memory mapped, but writes generally require feeding peripheral registers with commands, hence the latency sensitive read-modify-write. Some ARM microcontrollers do have more direct methods though, some of Freescale's Kinetis range have a feature called EzPort, where you hold a pin low on boot and it pretends to be SPI flash instead, and tiny 8 bit micros like the AVR all have something similar as full JTAG would be too big for them.
>If so you likely know this but you have to load the FPGA with a program to load the flash with the program you want the FPGA to load on reboot. Each of these programs have to be compiled and tested per chip.
Yeah, this is what I meant by having code run on the "target", this being the microcontroller you are programming. You are right in thinking this means the JTAG dongle no longer needs to know how to program flash itself, but it still needs to code to load in and instructions on how to do it (setting up clocks etc), which are also very platform specific. You could do the same for external flash, but its often easier just to connect to it directly and bypass the microcontroller.
Feel free to PM me if you have any more questions.