81–90 of 264 posts
This sounds like it's written from the point of view of implementing something inhouse. I fail to see how FPGA programming will be relevant if one wants to distribute software for consumers (or am I technologically clueless...).
Sounds like he is suffering from bias of the problem domain he is working on right now.
Earlier quoted context omitted.
> A complicated function may be made of a bunch of statements where each statement makes sense easily. The entire function may still be complicated. Statement yes, but I avoid them where possible - the complexity comes from their interactions because their interactions are unmanaged, implicit and arbitrary. If you make each function an expression made up of expressions and functions, then I think it becomes true that…
As far as the complexity of programs are concerned, there is a similarity between statements at one level of abstraction and functions at a higher level. I have seen many cases where small functions have been assembled into complicated programs. These programs often have a proliferation of 'helper' classes and functions, where you have to trace through long series of calls to get to where the work is done. They often…
Earlier quoted context omitted.
Compiler intrinsics as Assembly replacement go back all the way to the 60s.
But good codegen from intrinsics goes back only a dozen years or so (ymmv)
The real problem with C++ is the standard committee, the design by committee approach for such a complex language is failing. If C++ is taken over by a company, it will be a much better language.
Earlier quoted context omitted.
Compiler intrinsics as Assembly replacement go back all the way to the 60s.
But good codegen from intrinsics goes back only a dozen years or so (ymmv)
ESPOL, NEWP and Algol-68RS are some examples of Algol based systems programming languages where the hardware was fully exposed as intrisincs and no Assembly was required.
This article is not very general. Much of what it tries to convince us is not going to matter for most developers, and has the cost of suggesting modern features are not good for any developers. For example: >It is not rare to see Modern C++ applications taking 10 minutes to compile. With traditional C++, this number is counted in low seconds for a simple change. This is simply a bogus statement with respect to what…
Just an anecdote, but I also work at a successful HFT as well modern C++ is almost everywhere, without any performance hits and much cleaner code. Often it's easier to write fast code with it.
Earlier quoted context omitted.
> In my opinion this only shift the problem from coding clean code to handling hundreds or thousands of simple and small source files. This will make much more complicated to handle a large project because everything is scattered in such an extend that a developer spend more time searching thru the include list of files than understanding what the code is actually doing. I've worked on a number of very large codebase…
> That's the compiler's business. I don't care one way or the other about its implementation details. Actually, you do- for at least several reasons. 1. If the runtime or compiler were to have problems with interdependencies. 2. If the compiled code that will actually be executed or the application or service itself across cores, processors, VMs, geography at runtime takes longer to run because of its compiler implem…