Friday, July 28, 2017

Digest for comp.lang.c++@googlegroups.com - 15 updates in 5 topics

Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 28 11:34PM +0100

Profanity in this channel is .. excellent ..
 
https://www.youtube.com/watch?v=JaY7VTftPdY
 
BOLLOCKS!
 
Oh shit I've said fuck oh fuck I've said shit!
 
Up your cunt! Fuck you sideways!
 
Fuck off you cow!
 
/Flibble
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 28 06:41PM -0400

On 7/28/2017 6:34 PM, Mr Flibble wrote:
> Profanity in this channel is .. excellent ..
 
> https://www.youtube.com/watch?v=..
 
> [SNIP]
 
Anyone can use profanity, Leigh. Anyone can be vulgar and
cruel and hateful and mean. You just need to open your mouth
and out it spews, pick a target and attack.
 
It takes someone stronger, more focused, more purposed, to NOT
do those things. And it takes someone of wisdom to not do
them for the right reasons.
 
How strong are you, Leigh? How wise?
 
Thank you,
Rick C. Hodgin
woodbrian77@gmail.com: Jul 27 03:28PM -0700

On Thursday, July 27, 2017 at 7:29:17 AM UTC-5, Scott Lurndal wrote:
 
> Gratuitous advertisement elided.
 
> Note that the aforementioned feature is already implemented
> in clang.
 
Concepts were implemented in a C++ compiler around 2008.
Not sure of the year, but it was before 2011. Possibly in
2020 Concepts will become a part of C++.
 
 
Brian
Ebenezer Enterprises - "We few, we happy few, we band of
brothers." http://shakespeare.mit.edu/henryv/henryv.4.3.html
 
http://webEbenezer.net
Manfred <noname@invalid.add>: Jul 28 07:15PM +0200

On 07/26/2017 07:06 PM, Lynn McGuire wrote:
> more powerful and simpler."
 
> Looks a little complicated to this old Fortran hacker.
 
> Lynn
 
The thing looks of some appeal, but then rethinking about it I recalled
what I had experienced in large organizations about code generation.
 
'Cause the thing is closely related with code generation, and I recalled
things like an 'interface' metaclass being considered, and then
discarded, because, even if they are of wide use:
They are typically intentionally designed to be very thin, not to pose
excessive overhead on the project as a whole. The advantage of having
them generated is therefore very limited - since they are designed to be
thin, it is trivial to write an interface class in plain C++.
And on the other hand, adding the new feature to the framework (or even
the language as in this case), poses some adaptation costs for the
programmers, so in my experience, when it was considered, it was not
worth it.
 
This is only my personal experience, so, by definition, very limited.
 
Moreover, the way I see it, other metaclasses like 'value' tend to pose
too much cost in terms of constraints on the programming ability of the
developer, compared to the gain in enforced project structure.
I mean that, when developing some specific application software (i.e. in
the real world), there can very well be patterns that fit well in the
specific application domain, but deviate from general preferred use - if
you need a 'value' metaclass, I may imagine it can be significantly
customized for the application domain, so I am in doubt if a metaclass
construct would be that more convenient than a plain C++ template class.
 
Nonetheless, the ability of creating some 'keywords' of your own sounds
appealing.
legalize+jeeves@mail.xmission.com (Richard): Jul 28 10:35PM

[Please do not mail me a copy of your followup]
 
Manfred <noname@invalid.add> spake the secret code
>excessive overhead on the project as a whole. The advantage of having
>them generated is therefore very limited - since they are designed to be
>thin, it is trivial to write an interface class in plain C++.
 
I agree with your analysis ('interface' is thin), but disagree with
your conclusion.
 
I have seen lots of people write 'interface' classes where they forget
the virtual d'tor or implementation methods start leaking into the
interface, or they have other concrete methods in the interface.
 
Having a compiler enforce what it means for something to be an
interface is a solution to all these problems that arise from a lack
of self discipline.
 
If we considered it sufficient to rely on self discipline alone, then
we would just use C. But we don't, we value the extra checks that the
type system of C++ can provide and we lean on that to prevent
ourselves from getting sloppy in this regard.
 
I found the more compelling examples to be in his YouTube video, which
I encourage you to watch if you've only looked at the proposal and the
blog post. The flags enum example was particularly useful. He also
shows how it cleans up a whole bunch of crufty things like having to use
IDL compilers or the Qt moc compiler, making them entirely unnecessary
without imposing costs on people who don't use these facilities.
Furthermore, having them be testable libraries that can be distributed,
tested, improved upon and ultimately standardized via the library working
group is much better for the community than attempting to standardize
them through the language working group in the standards body.
 
One advantage of the approach advocated by Herb Sutter is that if you
don't like these metaclasses, you're not paying for them in any way.
Even if the standard library starts using them in conjunction with
concepts, I can't see that any of your code would be affected by their
use. If you provide implementations that are different from the
default supplied by a metaclass, it doesn't change your code.
--
"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>
David Brown <david.brown@hesbynett.no>: Jul 28 09:20AM +0200

On 27/07/17 21:57, Vir Campestris wrote:
> moved" from "This lump has been inserted, and that one deleted".
 
> Which becomes really interesting in reviews, when you really need to
> know whether it has been changed slightly when it moved.
 
Again, this is /not/ a problem - because it does not happen often.
 
And the period of the development process when you might be likely to be
moving bits around more, is the time when you are writing a lot of code
and making a lot of changes anyway.
 
I do accept, however, that moving code can make it harder to see changes
in the source when comparing versions - it is a valid argument against it.
Ian Collins <ian-news@hotmail.com>: Jul 28 08:48PM +1200

On 07/27/17 07:42 AM, Rick C. Hodgin wrote:
 
> -----
> What can be done to initiate a grass roots movement to remove the need
> for having forward declarations in upcoming C and C++ Standards?
 
Such a change would be largely irrelevant in C++ where most functions
are class members which are declared in class declarations. The reset
tend to be anonymous namespace functions which every coding standard
I've worked to live at the top of the compilation unit.
 
> I think some kind of compiler switch which disables the forward-
> declaration requirement, allowing an additional pass to be run on
> source code to resolve unknown references would be desirable.
 
C++ name lookup rules are complicated enough without adding more
complexity...
 
--
Ian
Bo Persson <bop@gmb.dk>: Jul 28 11:43AM +0200

On 2017-07-28 10:48, Ian Collins wrote:
> are class members which are declared in class declarations. The reset
> tend to be anonymous namespace functions which every coding standard
> I've worked to live at the top of the compilation unit.
 
And in C++ you can already abuse the rule than class members need not be
forward declared:
 
struct program
{
// all functions go here
};
 
The "member functions" can now freely call each other irrespective of
their declaration order.
 
 
Bo Persson
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 28 07:48AM -0400

On 7/28/2017 4:48 AM, Ian Collins wrote:
> are class members which are declared in class declarations. The reset
> tend to be anonymous namespace functions which every coding standard
> I've worked to live at the top of the compilation unit.
 
What about the case where file1.h and file1.cpp exist, and they
possess their own functions and do their own thing autonomously.
And then file2.h and file2.cpp exist, and they do likewise. But
then later you decide you want to implement some features in file1
which reference file2 abilities, and features in file2 which also
reference file1 abilities.
 
If you only declare their references in the .h files and write the
bode code in the .cpp file then it works, but if you want something
like an accessor and want to code the entire function in the .h
file you cannot do it because in either the file1-to-file2, or the
file2-to-file1 reference, something will be undefined if you're
only using the file1.h and file2.h headers. You have to now create
something like a common.h header which includes those things file1
and file2 will share so you can include common.h ahead of both of
them, then all works.
 
And as you make your file1 and file2 work also with file3 and
file4 and fileN, then you begin to have this convoluted requirement
of making sure things are defined before their use, when they are
simply defined already a few lines further down. It seems to be
a legacy exercise in ridiculousness when computers today are more
than capable enough to perform the extra pass for us, saving us
the labor time and headaches of making things just right for the
compiler's needs. I prefer to place value ahead of the compiler,
and make the developer's needs paramount when the compiler is
capable of performing a task for us.
 
In my view, the existing system works well for pointer references,
but not for member references. At least that's been my experience.
I could be doing it wrong.
 
Thank you,
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 28 07:53AM -0400

On 7/28/2017 5:43 AM, Bo Persson wrote:
> {
> // all functions go here
> };
 
I've never known this. Do you know if something like this works
properly?
 
struct program
{
#include "file1.h"
#include "file2.h"
#include "file1.cpp"
#include "file2.cpp"
};
 
And in that way, then file1.h can reference member functions
defined in file2.h and given a body in file2.cpp?
 
If so, that might cure all of my woes. :-)
 
> The "member functions" can now freely call each other irrespective of
> their declaration order.
 
Awesome. Thank you.
 
Yours in software,
Rick C. Hodgin
David Brown <david.brown@hesbynett.no>: Jul 28 04:14PM +0200

On 28/07/17 13:53, Rick C. Hodgin wrote:
> #include "file1.cpp"
> #include "file2.cpp"
> };
 
That might work, I think, as long as there are no conflicts between the
files (like types, functions, etc., with the same name in both file1 and
file2). I believe that in theory, it is not valid to include standard
headers at any scope other than file scope - but in practice I expect it
would work.
 
Of course, main() would no longer be the start of the code - you'd need
to add something like:
 
int main() {
program prog;
return prog.main();
}
 
outside of the "struct program".
 
(If you have a lot of data, you might want to put "program prog" outside
of main so that it goes in the bss section rather than on the stack.)
 
 
Give it a shot, and see if it works for you.
 
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 28 02:34PM -0400

On 7/28/2017 7:53 AM, Rick C. Hodgin wrote:
 
> And in that way, then file1.h can reference member functions
> defined in file2.h and given a body in file2.cpp?
 
> If so, that might cure all of my woes. :-)
 
I was able to test this program in Visual Studio 2015 and it worked.
I was able to reference class xyz and its members before it was /
they were defined:
 
-----[ Begin ]-----
 
#include <stdlib.h>
#include <stdio.h>
 
struct STest
{
int a;
 
// Here's a reference to STest::xyz before it's defined
int STest_main(int argc, char* argv[])
{
STest::xyz* x = new STest::xyz();
 
x->m_int = 5;
x->printf("something");
 
return 0;
}
 
class xyz
{
public:
xyz() {};
~xyz() {};
 
void printf(char* text) { ::printf(text); }
 
public:
int m_int;
};
 
int b;
};
 
int main(int argc, char* argv[])
{
STest t;
 
t.STest_main(argc, argv);
return 0;
}
 
-----[ End ]-----
 
Thank you,
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 28 02:40PM -0400

On 7/28/2017 2:34 PM, Rick C. Hodgin wrote:
> int STest_main(int argc, char* argv[])
> {
> STest::xyz* x = new STest::xyz();
 
// In my haste at refactoring, I also forgot these other references,
// both of which work with a defined before, and b defined after.
 
a = 3;
b = 4;
 
> return 0;
> }
 
> -----[ End ]-----
 
I think I may have found a reason to withdraw my earlier request
to have this non-forward declaration feature added to C/C++. It
already exists! (at least to some extent)
 
Thank you,
Rick C. Hodgin
Tim Rentsch <txr@alumni.caltech.edu>: Jul 27 10:16PM -0700


>> A class (or other kind of structuring construct) can
>> stand in for a type, but it is not the same as a type.
 
> Again you are wrong. In C++ a class is a type.
 
I'm sorry we weren't able to have a more productive
conversation.
legalize+jeeves@mail.xmission.com (Richard): Jul 28 02:20AM

[Please do not mail me a copy of your followup]
 
I've been tinkering around with how C++ can improve embedded
development. My reference platform is the Nintendo Game Boy Advance.
It has a bunch of coprocessing circuitry that is controlled through
memory-mapped registers. I came up with this little header for
modeling read-only, write-only and read-write registers located at a
specific address. I'm interested to hear if anyone else has done
something similar and how you approached the problem. This is my
lowest level abstraction around a memory-mapped register. Higher
level abstractions would be built on top of this.
 
I'm also interested to hear how you might have unit tested any embedded
code. I have my own ideas, but I don't want to lead the question with
my thoughts before I hear what oethers have done.
 
namespace RegisterModel
{
 
template <typename T, volatile T const *const address>
struct ReadOnlyRegister
{
operator T() const { return *address; }
T operator=(T) = delete;
};
 
template <typename T, volatile T *const address>
struct WriteOnlyRegister
{
operator T() const = delete;
void operator=(T value) { *address = value; }
};
 
template <typename T, volatile T *const address>
struct ReadWriteRegister
{
operator T() const { return *address; }
void operator=(T value) { *address = value; }
};
 
}
--
"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>
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)