Commit graph

13 commits

Author SHA1 Message Date
24b3bec4be Doxygen: prepare all unit tests for inclusion in the documentation
Doxygen will only process files with a @file documentation comment.
Up to now, none of our test code has such a comment, preventing the
cross-links to unit tests from working.

This is unfortunate, since unit tests, and even the code comments there,
can be considered as the most useful form of technical documentation.
Thus I'll start an initiative to fill in those missing comments automatically
2017-02-22 01:54:20 +01:00
48e9b7594a Doxygen: identify all files lacking a @file comment
reason is, only files with a @file comment will be processed
with further documentation commands. For this reason, our Doxygen
documentation is lacking a lot of entries.

HOWTO:
find src -type f \( -name '*.cpp' -or -name '*.hpp' \) -not -exec egrep -q '\*.+@file' {} \; -print -exec sed -i -r -e'\_\*/_,$ { 1,+0 a\
\
\
/** @file §§§\
 ** TODO §§§\
 */
}' {} \;
2016-11-03 18:20:10 +01:00
bdf48e1b7b WIP: desperate attempt to get out of the design deadlock
Arrrrgh.
I go round in circles since hours now.
Whatever I attempt, it again relies on
yet further unsecured suppositions
2016-02-26 22:57:49 +01:00
ecd1375e92 fix and adjust broken test defintions. Closes #985 2016-01-10 12:25:45 +01:00
2c20d407fc mass clean-up: adapt usage of std::cout pretty much everywhere
- remove unnecessary includes
- expunge all remaining usages of boost::format
- able to leave out the expliti string(elm) in output
- drop various operator<<, since we're now picking up
  custom string conversions automatically
- delete diagnostics headers, which are now largely superfluous
- use newer helper functions occasionally

I didn't blindly change any usage of <iostream> though;
sometimes, just using the output streams right away
seems adequate.
2016-01-07 20:12:46 +01:00
11ca89a2fd cover usage of predicate in unit test 2015-08-29 19:07:51 +02:00
da43d7f00f follow-up to the bugfix: just plain int is yet more readable
basically the 32/64bit problem was caused by things like 23L, which creates a long.
Unfortunately on 64bit platforms, this is aliased to int64_t,
while on 32bit i386, it is a distinct data type, but just 32bit,
like int.

The code in question here is just test / demonstration code
and actually just needs "some integer number". So let's stick
to good old boring int then.
2015-08-27 23:46:12 +02:00
4b2f7ef3ad fix a 32/64 bug
the obnoxious problem with long, which is
only 32bit on 32bit platforms.

incidentally, sitting here at FrOSCon 15
in the Lumiera developers room
2015-08-22 22:20:58 +02:00
5a4290d4a7 TICKET #738: re-implemented Variant functionality complete - unit test pass 2015-04-19 03:18:24 +02:00
7686122354 implementation complete -- kindof works
there is a problem with the virtual assignment,
seems the default policy was picked.

Beyond that, the rest of the unit test passes
2015-04-19 02:02:54 +02:00
c32685ada8 WIP: first round of implementation
finally got all those copy / assgnment flavours straight.

Still unsolved: unable to instantiate the Variant template
for a type with private assignment operator (like e.g. Time )
The problem is our virtual assignement operator, which forces
instantiation of the implementation (for the VTable), even if
the actual assignment is never invoked.
2015-04-17 19:33:25 +02:00
413a6a5d48 outline and stub the API functions. 2015-04-16 23:04:36 +02:00
eb263d44d7 TICKET #738: design API of a new variant implementation
- we do not want type mutations
- we do not want "empty" records ever
- we do not support "probing" for contents
- visitor style access for generic value handling
2015-04-16 20:29:03 +02:00