From: daniel.kruegler@googlemail.com
Am 30.09.2011 20:10, schrieb nmm1@cam.ac.uk:
> In article,
> =?ISO-8859-15?Q?Daniel_Kr=FCgler?= wrote:
>>
>> I'm indeed working with STL components in purely scientific projects
>> since years. ...
>
> Thanks very much. I would like to ask a few specific questions,
> if I may.
Sure. Free country, free questions, free beer, etc... ;-)
>> associative containers (Often std::map, but arguably most of them are
>> unordered containers),
>
> Thanks. That's what I noted as potentially relevant.
>
>> a lot of std::vector (internally), std::pair,
>
> But do those really help compared with rolling your own? My point is
> not that they don't work, but what practical benefits they convey.
std::vector didn't help me to roll my own analytical vector template,
but I certainly use it nearly always when I have to administrate
sequences of data that have a dynamic length or where the length is
determined by some configuration that is provided during runtime to the
program (but remains fix after this).
> When writing classes that needed vectors, I discovered that using
> std::vector didn't simplify the code significantly over ordinary
> arrays/pointers or provide significant extra checking. It does free
> space when writing a simple vector declaration and using exceptions to
> jump out, but that's about all I found.
IMO it also simplifies operations on the container, e.g. like insert or
erase operations. Where I use std::vector I usually cannot use native
pointers (except for traversal and such), mostly because of the
dynamicy. I also like the fact, that std::vector is fully
self-administrating, thus my code is easy to proof exception-safe.
> I agree that std::pair could be useful for one-off pairs (not as bases
> for classes), if one closes one's eyes to the type-matching ambiguities
> in the standard, but not everyone does that and some people consider
> it bad practice.
I use pair usually internally, where the actual member names are not so
relevant. I typically have wrapper classes that provide functions with
clearer names and which internally delegate to the first and second
member of pair.
>> IO streams for outputs (IO manipulators),
>
> Are they really a help compared to? I tried hard to use them,
> found them painful, and then queried it in a C++ expert forum, only to
> discover that even they found easier to use and more flexible.
> Indeed, I found them harder to use than Fortran formatted I/O!
Honestly, I use formatting with STL IO rather frequently. I very much
like that it is robust against simple type changes (e.g. long against
int or against uint16_t). Where I really like to use is in
low-level IO, e.g. when I implemented a so-called IO manipulator for
engineering format (it always ensures that the floating-point values are
converted into an exponential form where the exponent is a multiple of 3
to match with the multiple-of-three SI prefixes. But I prefer to use my
C++ engineering format manipulator in my actual code.
>> std::exceptions
>
> Yes, if your compiler supports tracebacks and cleaning up when you raise
> them. If not, they are just trivial syntactic sugar.
I use them a lot for configuration validation of the user input. The
program typically parses a text-like file with a huge amount of program
parameters. It is very helpful to have a simple way of defining a
reasonable message and a quick program-exit but still being able to
perform some necessary post-operations (setting time-stamps and such
things).
>> std::string
>
> Yes, but relatively few scientific programmers do much string
> manipulation. If they do, obviously they should use that.
I'm not using the strings for the actual data processing within the
analytical engine, but usually as a storage room for some string data,
and especially within the implementation of necessary text-analysis
components, e.g. to process the user configuration. In the classical
sense, in the IO layer before and after the number crunching.
>> Further, I'm taking massively advantage of STL algorithms, including
>> those from numeric.
>
> Interesting. Do they really save much complication? I find that the
> complexity of setting up an iterator outweighs the benefit for most of
> them. For example, calculating the trace of a matrix using accumulate.
> The number I have looked at where it is significantly simpler to
> call the algorithms than write out the code (complex transcendentals
> and sorting excepted) is fairly small.
I agree that a bit work is necessary for preparing the iterator types,
especially when I started with my classes and where I didn't have
iterator facades available like those from boost. But actually I rarely
did need to write them from scratch on. And IMO the work done has been
paid back quickly because of the amount of useful functionality
available through iterators.
I found very good usages for std::find, std::fill, std::rotate,
std::partial_sort_copy, std::sort, std::replace, std::accumulate
(internally in my matrix class), std::transform (within vector and
matrix classes), ...
But that doesn't mean that I don't write my loops manually ;-)
>> When I would restart a new project with a
>> C++11 library I would have a lot of good usages for the new random
>> number library
>
> Be warned: those are not very good classes of generator, and the
> standard does not specify the quality of implementation. If your
> program depends on subtle aspects, and especially if it is parallel as
> well, they may not be a good solution.
I'm especially referring to the framework, not necessarily to the
concrete generators. This is quite similar as to concrete hash
implementations. I can still take advantage of the unordered containers
framework from a library, but I don't need to rely on the q.o.i of
concrete hash algorithms.
> If anyone wants to look into this area in more depth, a good starting
> point is Pierre L'Ecuyer's papers. They are NOT easy reading. Most
> Web pages on this topic (and even published papers) are ghastly or
> worse :-(
Thanks for the tip, Nick. I will take a look at them.
Greetings from Bremen,
Daniel Krügler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
