Friday, July 27, 2018

Digest for comp.lang.c++@googlegroups.com - 10 updates in 3 topics

Juha Nieminen <nospam@thanks.invalid>: Jul 27 05:23AM


> Instead of learning for each editor which trick does it, I just indent
> my text as I want. Very simple but 100% effective, and uses zero BM. I
> do not have to remember anything.
 
This is the most asinine thing I have read in a long while.
Paavo Helde <myfirstname@osa.pri.ee>: Jul 27 11:07AM +0300

On 26.07.2018 23:22, Richard wrote:
> VS 2017 has built-in support for clang-format (you can even specify
> the particular clang-format executable to use) and it will then format
> according to clang-format's configuration.
 
URL:
https://blogs.msdn.microsoft.com/vcblog/2018/03/13/clangformat-support-in-visual-studio-2017-15-7-preview-1/
 
It's actually nice to see MS is actually trying to cooperate with the
rest of the world, for a change.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jul 27 01:41PM

On Mon, 2018-07-23, Thiago Adams wrote:
 
> I would like to understand better what you want to say.
> More abstract code scale better? How? Maybe because you can
> do the same think in less lines of code?
 
"Abstractions", not "more abstract". A good abstraction is, to me,
something rather concrete that's easy to reason about. It's often
something that exists in the problem domain, like a monthly salary in
a payroll program, or a zombie in a FPS game.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Thiago Adams <thiago.adams@gmail.com>: Jul 27 11:20AM -0700

On Friday, July 27, 2018 at 10:41:30 AM UTC-3, Jorgen Grahn wrote:
> something rather concrete that's easy to reason about. It's often
> something that exists in the problem domain, like a monthly salary in
> a payroll program, or a zombie in a FPS game.
 
My view is that we need to keep abstractions very small
and direct.
 
I liked this part of the video where Jon Blows talk about
layers.
 
https://www.youtube.com/watch?v=uZgbKrDEzAs&feature=youtu.be&list=PL_LX30v0VQqEMTTX3uG93_tUnTUPMG6X6&t=351
 
"..layers don't generally couple together perfectly.."
Thiago Adams <thiago.adams@gmail.com>: Jul 27 11:27AM -0700

On Friday, July 27, 2018 at 3:20:53 PM UTC-3, Thiago Adams wrote:
> layers.
 
> https://www.youtube.com/watch?v=uZgbKrDEzAs&feature=youtu.be&list=PL_LX30v0VQqEMTTX3uG93_tUnTUPMG6X6&t=351
 
> "..layers don't generally couple together perfectly.."
 
I forgot to conclude..sorry
 
Then, considering too much layers of abstraction, I think
this makes the software harder to scale and maintain.
Also programmers can lost control of some components they
don't know how they are implemented.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jul 27 08:16AM

On Thu, 2018-07-26, Adam Wysocki wrote:
>> */
 
> Could be (if we replace \retval with \return). It's Doxygen syntax (more
> precisely: JavaDoc syntax, but used with Doxygen).
 
Ok. I use Doxygen too, but don't like its \tags. It may be a quirk in
my personality, but I prefer documenting as a paragraph of text, in
the same style and tone that typical Unix man pages uses under
DESCRIPTION. A good (and fairly complex) example is the Linux
strtol(3) manual page.
 
I find that most of the time, if I write that text well, the parameter
and return value lists become superfluous.
 
Doxygen supports that style too.
 
IME, documentation using \param and \return often ends up as a list of
tautologies and still doesn't explain what the function does. I think
that's because an author who isn't really interested in documentation
can get away with doing it mechanically, like filling in a table.
 
(That doesn't apply to you; you're obviously interested in correct and
complete documentation.)
 
Then, to be complete, I should mention that if I design my classes
well and document them as needed, often the related functions need no
documentation at all.
 
 
> http://www.chmurka.net/r/usenet/fizzbuzz.png
 
> The code is not visible here (and should not be), only this documentation
> and prototypes.
 
I sometimes wonder how often people read the Doxygen-generated
documentation, as opposed to reading the comments in the source. I
tend to end up doing the latter. Sometimes I read both, but only use
Doxygen as an index, and as a tool to visualize class diagrams and
#include hierarchies.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jul 27 08:19AM

On Thu, 2018-07-26, Rick C. Hodgin wrote:
> or if the application's thread isn't suspended to save battery life,
> etc. There may be more factors than a raw read and report. The
> documentation here would give that information, up or down.
 
To me, that's part of the reason not to document this function: then
the reader knows something non-obvious is happening when she
encounters that other function.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 27 10:17AM -0400

On 7/27/2018 4:19 AM, Jorgen Grahn wrote:
 
> To me, that's part of the reason not to document this function: then
> the reader knows something non-obvious is happening when she
> encounters that other function.
 
 
I agree ... in some cases. It depends on how this one function exists
in the rest of the system. If everything is documented a particular
way, then to document it commensurately is appropriate. For a tiny
standalone app like this, it's unnecessary.
 
That's an example of the variation and nuance required to understand
when to apply documentation, and when not to. Universal or blanket
statements about how to document things are ill-effective and ill-
advised. It depends on a great many factors, but on the whole, I tend
to lean to the side of over-documenting, because it doesn't hurt, and
I also type very fast. :-)
 
--
Rick C. Hodgin
Thomas Kaufmann <tokauf@gmail.com>: Jul 27 04:04AM -0700

Thanks. I'll try it.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jul 27 12:07PM


> #include <stdlib.h>
> #include <sqlite3.h>
 
> static int callback(void *NotUsed, int argc, char **argv, char **azColName) {
...
 
Perhaps you should look for a C++ API to sqlite3. Callbacks is one of
those things that C++ (especially C++11 with lambdas and
std::function) are better at than C, and a C++ API would surely let
you use those (or avoid callbacks entirely).
 
The C API lets you pass a context as a void*, but you're not using it.
I find that I almost always end up using it, because otherwise I must
use global variables to communicate with the callback's
implementation. (In your case you use stdout and cout.)
 
> printf("%s = %s\n", azColName[i], argv[i] ? argv[i] : "NULL");
> }
 
> cout << "\n";
 
Mixing printf()/stdout output with std::cout output is supported, but
it's confusing and can hurt performance. Stick to one of them.
 
> return EXIT_SUCCESS;
 
EXIT_SUCCESS is normally used with the return from main(), or in exit().
If the sqlite3 docs don't explicitly tell you to use it, don't.
 
...
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)