On 20/07/2018, at 4:12 AM, Richard Earnshaw (lists) <richard.earns...@arm.com
<mailto:richard.earns...@arm.com>> wrote:
> On 19/07/18 12:30, Florian Weimer wrote:
>> * Segher Boessenkool:
>>
>>> What would the advantage of using Python be? I haven't heard any yet.
>>> Awk may be a bit clunky but at least it is easily readable for anyone.
>>
>> I'm not an experienced awk programmer, but I don't think plain awk
>> supports arrays of arrays, so there's really no good way to emulate
>> user-defined data types and structure the code.
>>
>
> You can do multi-dimentional arrays in awk. They're flattened a bit
> like tcl ones are, but there are ways of iterating over a dimention.
> See, for example, config/arm/parsecpu.awk which gets up to tricks like that.
Has it occurred to anyone to write a lean and fast tool in the host C++ subset
that is allowable for use in the host tools. I guess this is currently
C++98/GNU++98. This adds no additional dependencies. Sure it is a slight level
of effort higher than writing an awk script, but with a modern C++ this is less
of a case as it has ever been in the past. I personally use C++11/14 as a
substitute for python type programs that would normally be considered script
language material, mostly due to fluency and the fact that modern C++ has grown
more tractable as a replacement for “fast to code in” languages given it is
much faster to code in than C.
LLVM discussed changing the host compiler language feature dependencies to
C++11/C++14. There are obvious but not insurmountable bootstrap requirements.
i.e. for very old systems it will require an intermediate C++11/C++14 compiler
to bootstrap LLVM 6.0. Here is LLVM's new compiler baseline and it seems to
require CentOS 7.
- Clang 3.1
- GCC 4.8
- Visual Studio 2015 (Update 3)
[1] https://llvm.org/docs/GettingStarted.html#getting-a-modern-host-c-toolchain
I find I can be very productive and nearly as concise in C++11 as I can in many
script languages due to modern versions of <vector>, <map>, <set>, <memory>,
<string>, <regex>, auto, lambdas, etc. It’s relatively easy to write memory
clean code from the get go using std::unique_ptr<> and sparing amounts of
std::shared_ptr<>) and the new C++11 for comprehensions, initializer lists and
various other enhancements can make coding in “modern C++” relatively friendly
and productive. In the words of Bjarne Stroustrup: It feels like a new
language. I can point to examples of small text processing utilities that i’ve
written that could be written in python with a relatively similar amount of
effort. Fluency with STL and the use of lean idioms. STL and structs (data
hiding is only a header tweak away from being broken in a language like C++,
and the use of struct and is similar to language like python which resorts to
using underscores or “idiomatic enforcement”). i.e. there are lightweight, fast
and productive modern C++ idioms that work well with vectors, sets, maps and
unique_ptr or shared_ptr automatic memory management. I find with modern idioms
these programs valgrind clean almost always.
Would modern-C++ (for generated files) be considered for GCC 9? The new idioms
may make parts of the code considerable more concise and could allow use of
some of the new automatic memory management features. The reason I’m suggesting
this, is that for anything other than a trivial command line invocation of sed
or awk, I would tend to write a modern C++ program to do text processing versus
a script langauge like python. Firstly it is faster, Secondly I am proficient
enough and the set and map functionality combined with the new automatic memory
management is sufficient enough that complex nested data structures and text
processing can handled with relative ease. Note: I do tend to avoid iostream
and instead use stdc FILE * and fopen/fread/frwite/fclose or POSIX
open/read/write/close if I want to avoid buffering. I find iostream performance
is not that great.
How conservative are we? Is C++11 going go be available for use in GCC before
C++2x in 202x. Indeed <filesystem> would improve some of the Windows/UNIX
interoperability. I’ve found that writing C++11/14 allows me to write in an
idiomatic C/C++ subset that is quite stable across platforms. We now even have
<cstdint> on Windows. There has been quite a bit of convergence.
Having the constraint that modern C++11/14 can only be used for generated files
lessens the burden as the distribution build can maintain the same base
compiler dependencies.
Michael.
