Monday, March 26, 2018

Digest for comp.lang.c++@googlegroups.com - 25 updates in 7 topics

Pvr Pasupuleti <pvr.ram34@gmail.com>: Mar 26 09:35AM -0700

https://unacademy.com/lesson/controlling-loop-statements/3QOIQ506
"Öö Tiib" <ootiib@hot.ee>: Mar 26 10:25AM -0700

On Monday, 26 March 2018 19:35:24 UTC+3, Pvr Pasupuleti wrote:
> https://unacademy.com/lesson/controlling-loop-statements/3QOIQ506
 
That https://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list
makes huge understatement how poor the situation is:
 
| Unlike many other programming languages, which are often picked up on
| the go from tutorials found on the Internet, few are able to quickly
| pick up C++ without studying a well-written C++ book. It is way too
| big and complex for doing this. In fact, it is so big and complex,
| that *there* *are* *very* *many* *very* *bad* *C++* *books* out there.
| And we are not talking about bad style, but things like sporting
| glaringly obvious factual errors and promoting abysmally bad
| programming styles.
 
Your site is too terrible even for to be parody of described bad C++
textbooks. Why every next moron tries to add more to that nightmare?
Why none of them attempts to learn C++ before starting to teach it?
Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 26 06:04AM

On Sat, 2018-03-24, Daniel wrote:
 
> I find it curious that you seem to be spending so much time in the debugger.
> I rarely, hardly ever, do. Is there something about how you approach a
> programming problem that requires you to be in the debugger that much?
 
There are different schools. There are good programmers (mostly
Windows-oriented ones AFAICT) who use step-wise debugging heavily, and
others who never do. It was discussed here (or in comp.lang.c) at
length a few years ago.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Mar 25 11:33PM -0700

On 3/24/2018 6:37 PM, Melzzzzz wrote:
 
>> Well, Rick does seem to like compiling C code in C++...
 
> Heh, when I want C, I use C compiler.
 
Amen.
David Brown <david.brown@hesbynett.no>: Mar 26 08:44AM +0200

On 26/03/18 08:04, Jorgen Grahn wrote:
> Windows-oriented ones AFAICT) who use step-wise debugging heavily, and
> others who never do. It was discussed here (or in comp.lang.c) at
> length a few years ago.
 
Sometimes I find I am doing step-wise debugging quite heavily. But that
is often in connection with hardware issues in my code, running on small
microcontrollers - the kind of thing that is particularly hard to write
tests for. (How do you write good tests for code to run some hardware
that has only minimal documentation?) I could see "edit-and-continue"
programming fixes being occasionally useful in such circumstances, if it
were practical on the targets I use (it isn't). I could not imagine
trying to use it as a main development process, however.
wyniijj@gmail.com: Mar 26 02:21AM -0700

Rick C. Hodgin於 2018年3月24日星期六 UTC+8上午2時43分49秒寫道：
> I remote connected to a foreign server and it was faster there
> over our LAN than it is here locally when I debug this particular
> process.
 
I rarely use debugger, I use only in cases some codes produce results
not as expected, even for micro-controllers(more rarer).
In situation you mentioned, analyzing symptom and narrowing down to
something verifiable is the general method I would use.
Using debugger for finding issues between computers connected via
LAN, if I might envision, involves filtering lots of 'noises'. So you
would complain and ask for faster debugger tool.
 
Sorry not a direct answer. But anyway, having seen your discussions,
I decided a try using VS.
 
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 26 04:58AM -0700

> would complain and ask for faster debugger tool.
 
> Sorry not a direct answer. But anyway, having seen your discussions,
> I decided a try using VS.
 
I think because the debugger facilities in Visual Studio are so
advanced, many Windows users have had a tool the *nix world with
a GCC/GDB-like toolchain hasn't, so there's an understandable divide.
 
I made a video a while back showing some of the advantages of the
edit-and-continue debugger:
 
Length 9:40. Demonstrates VS 2008 debugger. Visual Studio
2015 and later have more advanced debuggers. Not sure about
VS2012, never used it:
 
http://www.visual-freepro.org/videos/2014_02_13__demonstrate_x86_debugger.ogv
 
> > speed is slow enough I'm looking for another tool. If I can
> > correct my setup here so it goes faster, I'll be happy to try
> > these tools.
 
VS2010 has proven just like I'd expect. I also re-installed VS2008
to see how it will do, but Win10 complained that part of what it
needed to run (for SQL Server 2005) was no longer supported in this
version of Windows... so maybe it will work, maybe it won't. You
never know for sure until you try.
 
--
Rick C. Hodgin
David Brown <david.brown@hesbynett.no>: Mar 26 04:31PM +0200

On 26/03/18 13:58, Rick C. Hodgin wrote:
 
> I think because the debugger facilities in Visual Studio are so
> advanced, many Windows users have had a tool the *nix world with
> a GCC/GDB-like toolchain hasn't, so there's an understandable divide.
 
Apart from the "edit and continue" support, which is something I don't
see much use of for my C or C++ code (I sometimes modify python code
live, but not C or C++), what does Visual Studio have that is so
"advanced" ? Why should I be interested in it for x86 development? (It
would be useless for my main work, as it does not support embedded
targets, remote debugging, hardware JTAG debugging, simulators, etc.)
scott@slp53.sl.home (Scott Lurndal): Mar 26 03:01PM

>>> which I also think is outrageous.
 
>> $1600 in a professional environment is peanuts.
 
>It's too much if gcc or clang can do the job 98% as well.
 
The intel compiler does a better job of autovectorization
than the open-source competition, which is one selling point
for ICC, but that is specific to certain workloads (HPC).
Paavo Helde <myfirstname@osa.pri.ee>: Mar 26 06:36PM +0300

On 26.03.2018 17:31, David Brown wrote:
> "advanced" ? Why should I be interested in it for x86 development? (It
> would be useless for my main work, as it does not support embedded
> targets, remote debugging, hardware JTAG debugging, simulators, etc.)
 
FWIW, Visual Studio supports remote debugging. It also appears to
support cross-compilation to ARM.
 
Granted, it it is more suited for certain project types and for certain
development styles. To each his own. For example, I like when I can
click open deep container (std::map) hierarchies in a breakpoint and
actually see what data they contain. Not that I would need this every
day (if I needed this every day an automated non-clicking solution would
be preferable).
 
Cheers
Paavo
Melzzzzz <Melzzzzz@zzzzz.com>: Mar 26 04:01PM


> The intel compiler does a better job of autovectorization
> than the open-source competition, which is one selling point
> for ICC, but that is specific to certain workloads (HPC).
I just installed intel C and C++ compiler . Whooping 13GB on disk.
I guess they have some tools besides compiler ;)
ihttps://software.intel.com/en-us/system-studio/choose-download
It is free now.
 
--
press any key to continue or any other to quit...
David Brown <david.brown@hesbynett.no>: Mar 26 06:13PM +0200

On 26/03/18 17:36, Paavo Helde wrote:
>> targets, remote debugging, hardware JTAG debugging, simulators, etc.)
 
> FWIW, Visual Studio supports remote debugging. It also appears to
> support cross-compilation to ARM.
 
What about debugging via jtag with ARM microcontrollers? That's a
little different from, say, debugging ARM Linux (or WinRT) processes.
 
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 26 09:17AM -0700

On Monday, March 26, 2018 at 11:37:06 AM UTC-4, Paavo Helde wrote:
> FWIW, Visual Studio supports remote debugging. It also appears to
> support cross-compilation to ARM.
 
In Visual Studio 2017 it also supports the full GCC/GDB toolchain:
 
What's New in Visual Studio 2017?
https://www.youtube.com/watch?v=TYEoJorFn54
 
Visual Studio 2015 or higher GDB Debugger Extension
https://www.youtube.com/watch?v=-3toI8L3Oug
 
Linux development with Visual Studio 2017
https://www.youtube.com/watch?v=XIiFuBczd6A
 
> actually see what data they contain. Not that I would need this every
> day (if I needed this every day an automated non-clicking solution would
> be preferable).
 
There is an add-on for Visual Studio called Visual Assist X by
Whole Tomato that extends its abilities into some really amazing
extensions that I use daily.
 
https://www.wholetomato.com
 
It's the best development platform in existence. I've looked for
others. One written called Sun Studio by Sun Systems for the now
"defunct" Sun OS was the second best I've seen, as Oracle has kind
of destroyed that whole platform.
 
My goals for CAlive are to produce a Visual Studio-like experience,
and to integrate compiler info into the IDE.
 
--
Rick C. Hodgin
scott@slp53.sl.home (Scott Lurndal): Mar 26 05:17PM


>> FWIW, Visual Studio supports remote debugging. It also appears to
>> support cross-compilation to ARM.
 
>What about debugging via jtag with ARM microcontrollers?
 
DSTREAM is the typical answer, but the external debugger
protocol and capablities are well documented by ARM and thus
could be integrated with existing debuggers.
 
https://developer.arm.com/products/software-development-tools/debug-probes-and-adapters/dstream
Paavo Helde <myfirstname@osa.pri.ee>: Mar 26 08:20PM +0300

On 26.03.2018 19:13, David Brown wrote:
>> support cross-compilation to ARM.
 
> What about debugging via jtag with ARM microcontrollers? That's a
> little different from, say, debugging ARM Linux (or WinRT) processes.
 
I do not know anything about jtag, so I have no idea. Googling JTAG MSVC
turns up some third-party add-ons like https://visualgdb.com/ - not sure
if this would be feasible for anything.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 26 10:04AM

On Sun, 2018-03-25, Daniel wrote:
 
> subdirectory name: optional
> namespace name: optional_ns
> class name: optional
 
Note that Boost is a general library; different needs compared to a
class in a program.
 
> for a subdirectory, namespace and class name is "cbor" (a class
> encapsulating the Concise Binary Object Representation and related
> algorithms.)
 
Having a 1:1 mapping between subdirectories and major namespaces
sounds like a good idea.
 
My only thought is that having both a namespace and a class named cbor
seems a bit suspect. Maybe the namespace isn't needed? Or maybe
there's a better class name? I'm not familiar with CBOR, but I could
imagine cbor::Encoder and cbor::Decoder being better names.
 
The class name should IMHO be read as in the context of the namespace,
and then cbor::cbor would just be superfluous, and say nothing about
the class itself.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Daniel <danielaparker@gmail.com>: Mar 26 06:36AM -0700

On Monday, March 26, 2018 at 6:05:17 AM UTC-4, Jorgen Grahn wrote:
> > class name: optional
 
> Note that Boost is a general library; different needs compared to a
> class in a program.
 
The context is a general purpose open source library for json, cbor,
msgpack and related json-inspired data models, as well as standard and defacto standard algorithms that apply to these data models, such as
jsonpath, json content rules, jsonpointer, and jsonpatch. So the needs are
the same.
> > algorithms.)
 
> Having a 1:1 mapping between subdirectories and major namespaces
> sounds like a good idea.
 
Agreed. That's what boost does most of the time, except in the few cases
where the "natural" name for the subdirectory, path and class are the same,
e.g. bimap. In that case boost made the namespace plural, but in the case
of option, they made the namespace option_ns.
 
 
> My only thought is that having both a namespace and a class named cbor
> seems a bit suspect. Maybe the namespace isn't needed?
 
It is. cbor, msgpack, jsonpointer, jsonpath etc. are distinct libraries.
 
> Or maybe
> there's a better class name? I'm not familiar with CBOR, but I could
> imagine cbor::Encoder and cbor::Decoder being better names.
 
Encoders, decoders, validators, there are all of those things, but
in addition there's a need for a value representation of the bytes,
with a corresponding set of member functions, some common to json,
cbor, and msgpack. That's what allows query algorithms like jsonpointer
and jsonpath to be applied to any of the json-like data models,
whether unpacked or binary encoded.
 
But this is the main issue, whether to choose a different namespace
name, which seems to be boost's practice, or to give the value like class a
different name, e.g. cbor_val or cbor_value.
 
> The class name should IMHO be read as in the context of the namespace,
> and then cbor::cbor would just be superfluous, and say nothing about
> the class itself.
 
I suppose cbor::value (msgpack::value) would be an option, but value by
itself seems uninspired. Or perhaps cbor::packed (msgpack::packed), as
these encapsulate packed arrays of bytes.
 
Thanks for the comments, questions about naming conventions tend to be sparsely responded to here :-) But at the same, there are clearly best practices for naming, and with libraries it's helpful to follow conventions,
so feedback appreciated.
 
Daniel
legalize+jeeves@mail.xmission.com (Richard): Mar 26 04:05PM

[Please do not mail me a copy of your followup]
 
Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code
 
>The class name should IMHO be read as in the context of the namespace,
>and then cbor::cbor would just be superfluous, and say nothing about
>the class itself.
 
In my canonical solutions to problems on the C++ language track for
exercism.io, I often ended up with a single function that was the
solution. However, I wanted to exhibit that the only thing that
should be declared in the global namespace is main(), so I put the
function in a namespace. Most of the time it ended up being foo:foo
for not having any better alternative. The context of the problems
are small enough that you generally just needed a single identifier,
but I didn't want that in the global namespace. I don't like naming
functions "process" or even worse "doit", so I settled for a little
repetition. Example:
<https://github.com/exercism/cpp/blob/master/exercises/anagram/example.h>
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Daniel <danielaparker@gmail.com>: Mar 26 10:17AM -0700

On Monday, March 26, 2018 at 12:05:33 PM UTC-4, Richard wrote:
 
> I don't like naming functions "process" or even worse "doit",
 
Agreed
 
> so I settled for a little
> repetition. Example:
> <https://github.com/exercism/cpp/blob/master/exercises/anagram/example.h>
 
Okay, but I always thought that introducing a class name the same as the
namespace name was disfavored because it introduced ambiguities, e.g.
 
namespace anagram
{
class anagram
{
};
}
 
using anagram::anagram;
 
int main()
{
anagram x;
}
 
Error: a namespace name is not allowed
 
Daniel
legalize+jeeves@mail.xmission.com (Richard): Mar 26 04:36PM

[Please do not mail me a copy of your followup]
 
<http://legalizeadulthood.wordpress.com/2018/03/25/give-your-old-code-some-new-love/>
 
If you're not careful, entropy creeps its way into your code base. You
take a shortcut or code something in a way that you know is sloppy and
you say to yourself "I'll come back to that later", but later you're
faced with new feature requests or some other Imminent Disaster(tm)
and you don't go back and clean up the mess you made earlier. This is
only natural in a code base and when the messes are few and far between,
it is tolerable.
 
[...]
 
In this post, we'll take a look at an open source project with a code
base that is over 30 years old and has accumulated some "cruft" along
the way. We'll discuss various strategies for coping with the cruft
and how to get rid of it in as safe a manner as possible. After all,
we don't want to introduce bugs while we clean up cruft.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
woodbrian77@gmail.com: Mar 25 07:21PM -0700

On Friday, March 23, 2018 at 11:01:38 AM UTC-5, Richard wrote:
 
> /* ... */
 
> private:
> std::vector<std::unique_ptr<Widget>> m_widgets;
 
::boost::base_collection<Widget>
would probably be better:
http://www.boost.org/doc/libs/1_66_0/doc/html/poly_collection.html
 
. Beyond the performance advantages described there, there
are also serialization-related performance advantages over
a vector of pointers. To the best of my knowledge, the C++
Middleware Writer is the only library to have serialization
support for boost::base_collection.
 
 
Brian
Ebenezer Enterprises - Enjoying programming again.
http://webEbenezer.net
scott@slp53.sl.home (Scott Lurndal): Mar 26 02:58PM


>I have trouble applying them in practical code, too, after 15 years
>with C++. In the sense that run-time polymorphism (a better word for
>the language feature as a whole, IMHO) is not needed in every program.
 
I use virtual functions in most of my code.
 
As a concrete example, consider a computer system simulation (used to
experiment with different architectural changes prior to implementation
in silicon).
 
This simulation models several different I/O controllers, yet all the I/O
controllers have a common interface to the central processor. Each I/O
controller is an instance of a Data Link Processor (DLP). It makes
sense, then, to model the interface as an abstract class (c_dlp) which
provides virtual functions that are common to all controllers:
 
class c_dlp {
...
public:
c_dlp(ulong, ulong, c_logger *);
virtual ~c_dlp(void);
 
/**
* Cancel all outstanding IOCB's. The implementation of this
* method must discontinue all outstanding operations, producing
* result descriptors for each oustanding operation.
*
* The cancel MLI opcode value is 0xc.
*
* @param iocb The IOCB for the cancel operation.
*/
virtual bool cancel(c_iocb *iocb) = 0;
 
/**
* Echo operation. Write data to DLP and immediately read back into
* buffer following written data. Diagnostic use.
*
* The echo MLI opcode value is 0x1.
*
* @param iocb The IOCB for the echo operation.
 
*/
virtual bool echo(c_iocb *iocb) = 0;
 
/**
* Test the DLP, or test an individual Unit on the DLP. The
* test operation variants are DLP specific.
*
* The test MLI opcode value is 0x2.
*
* @param iocb The IOCB for the test operation.
*/
virtual bool test(c_iocb *iocb) = 0;
 
/**
* Read data from the DLP. The read operation is DLP specific.
*
* The read MLI opcode value is 0x8.
*
* @param iocb The IOCB for the read operation.
*/
virtual bool read(c_iocb *iocb) = 0;
 
/**
* Write data to the DLP. The write operation is DLP specific.
*
* The write MLI opcode value is 0x4.
*
* @param iocb The IOCB for the write operation.
*/
virtual bool write(c_iocb *iocb) = 0;
 
/**
* Retrieve a text string describing the DLP.
*/
virtual const char *get_name(void) = 0;
 
....
};
 
Each device model then implements (in the Java sense) that interface.
 
io/dlps/buffered_printer_dlp.h:class c_buffered_printer_dlp : public c_dlp {
io/dlps/fips_tape_dlp.h:class c_fips_tape_dlp : public c_dlp {
io/dlps/ht_dcp_dlp.h:class c_ht_dcp_dlp : public c_dlp {
io/dlps/ht_dpdc_dlp.h:class c_ht_dpdc_dlp : public c_disk_dlp {
io/dlps/isc_dlp.h:class c_isc_dlp : public c_dlp, public c_port_transport {
io/dlps/odt_dlp.h:class c_odt_dlp : public c_dlp,
io/dlps/qwik_dlp.h:class c_qwik_dlp : public c_dlp {
io/dlps/ssp_dlp.h:class c_ssp_dlp : public c_dlp, public c_ssp_client {
io/dlps/telcom_dlp.h: public c_dlp,
io/dlps/train_printer_dlp.h:class c_train_printer_dlp : public c_dlp {
io/dlps/uniline_dlp.h:class c_uniline_dlp : public c_dlp,
 
The I/O controller model then simply uses the c_dlp interface to access
all the device models and never sees the actual device model class
name.
 
e.g.
 
c_dlp *dlpp = get_dlp(channel);
if (dlpp != NULL) {
if (!dlpp->read(iocbp)) {
/* Operation Failed */
set_coms(HIGH);
} else {
set_coms(EQUAL);
}
}
legalize+jeeves@mail.xmission.com (Richard): Mar 26 03:59PM

[Please do not mail me a copy of your followup]
 
Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code
 
>I have trouble applying them in practical code, too, after 15 years
>with C++. In the sense that run-time polymorphism (a better word for
>the language feature as a whole, IMHO) is not needed in every program.
 
I found that when practicing pure TDD, pure abstract interfaces show
up more often in my code. That means virtual functions in C++. There
are other design benefits to using pure abstract interfaces, but when
testing behavioral classes (e.g. not simple value types like std::string)
you tend to have one class collaborating with another and you want to
mock out the collaborators. This is trivial if the collaboration is
done through a pure virtual interface.
 
A modern compiler may even notice that this "virtual" function is only
ever called on one particular class implementation and eliminate the
indirection through the vtable.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
seeplus <boardmounrt@gmail.com>: Mar 25 09:16PM -0700

On Monday, March 26, 2018 at 7:31:32 AM UTC+11, computer45 wrote:
> Hello....
 
> This is only one post here about Islam..
 
> I will give my explanation of Islam and the Koran..
 
Can you please both hopefully fight to the death over this idiotic RUBBISH
.... but just not HERE!
woodbrian77@gmail.com: Mar 25 04:59PM -0700

On Saturday, March 24, 2018 at 2:52:22 AM UTC-5, Jorgen Grahn wrote:
> context what the type is. Or you just pass the value on without
> caring what it is. There I happily use auto (or const auto, or const
> auto&).
 
I would write auto const or auto const&, but otherwise agree
with you.
 
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
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)