Tuesday, July 10, 2018

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

Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 10 10:56PM +0100

On 09/07/2018 12:56, Rick C. Hodgin wrote:
> will.  I am not a self-made man.  I am a component of His creation,
> and a minor cog at that.  Things must align per His plans, or none
> of what I plan will come to fruition.
 
Too late mate: Terry A. Davis has beaten you to it. He had all the same
goals you had and he accomplished them in his mind's eye. Now he just
randomly shouts at dust motes.
 
https://en.wikipedia.org/wiki/TempleOS
 
Please take your medication. When you are better spend your time on more
useful endeavours.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Jul 10 03:22PM -0700

On 7/10/2018 2:56 PM, Mr Flibble wrote:
 
> https://en.wikipedia.org/wiki/TempleOS
 
> Please take your medication.  When you are better spend your time on
> more useful endeavours.
 
This is some pretty crazy shi% man:
 
https://www.reddit.com/user/TempleOSV413
 
There seems to be some strange white power and pedophile crap in there.
 
Very weird! I wonder if Rick has conversed with this "thing"?
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Jul 10 03:24PM -0700

On 7/10/2018 3:22 PM, Chris M. Thomasson wrote:
 
> This is some pretty crazy shi% man:
 
> https://www.reddit.com/user/TempleOSV413
 
> There seems to be some strange white power and pedophile crap in there.
 
Unfortunately, I just read it a bit more carefully, and things got even
more dark and weird. I don't even want to quote anything in that pile of
whack job garbage! ;^o
 
 
> Very weird! I wonder if Rick has conversed with this "thing"?
 
Wow.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 10 03:37PM +0200

On 10.07.2018 14:58, Juha Nieminen wrote:
 
> Only the first one is relevant and will tell you the problem.
 
> What exactly do you think should happen if you try to output a
> vector to a stream?
 
Something reasonable.
 
It doesn't matter exactly what the output is, except for the distinction
between display for humans, versus round-trip conversion support where
the text representation can be parsed and yield the original data.
 
I've briefly encountered a number of libraries that produce reasonable
text output of any standard library container. So it's possible. It's
just not standardized and readily available, which would have been nice.
 
 
> Fragile... What exactly is it that you want? For the compiler to guess
> using AI what you *really* wanted to say, even though it's not syntactically
> correct?
 
IMO most of the problems with silly error avalanches in C++ stem from
using too low level language features to directly implement higher level
stuff, because the language lacks the middle level of abstraction.
 
For example, because of the lack of abstraction an error message will
typically show the complete template instantiation for something,
instead of just a simple recognizable name like `std::string`.
 
With C++ templates we're essentially using `goto` directly instead of
structured flow control like `for` loops. So, in that analogy, the
errors don't relate to loop variant and invariants, or something like
that, but instead to invalid position for label, computed goto with
possibly invalid resulting jump address, ... blah blah details details,
of no interest to one whose goal is to loop over items of a collection.
 
 
Cheers!,
 
- Alf
Bart <bc@freeuk.com>: Jul 10 03:02PM +0100

On 10/07/2018 13:58, Juha Nieminen wrote:
 
>> std::vector<int> v = {10,20,30,40};
 
> It's not doing the same thing at all. Nor is it demonstrating the point
> of my post.
 
The end result was presumably to create an instance of a vector of
size_t initialised to N elements set to some values (I suppose I could
have initialised mine to ten 20s).
 
 
>> v := (10,20,30,40)
>> println v # output: (10,20,30,40)
 
> Why should it write "(10,20,30,40)"?
 
Because that's the default output for that type in this language? The
same as you might get in Python or Ruby in Javascript; the details will
vary but you will get the values 10, 20, 30, and 40 printed out in some
form and in that order.
 
> Why not "10, 20, 30, 40"? Or "[10, 20, 30, 40]"? Or "[10,20,30,40]"?
> Or each number in its own line? Or the about one million other possible
> variations? Why is that the "correct" one?
 
You can write a printlist() routine for a generic list to get it
displayed as you want.
 
Or superimpose a user type on it that requires a certain output style
that will use a dedicated stringify routine. But for quickly displaying
the value(s) of a variable, it doesn't matter.
 
(How would a debugger for C++ display such a vector?)
 
 
> Fragile... What exactly is it that you want? For the compiler to guess
> using AI what you *really* wanted to say, even though it's not syntactically
> correct?
 
I'm saying it is fragile.
 
What are we declaring here? Some sort of flexible, ie. expandable array
of a specific type? You can express that in C with a tweak in the syntax:
 
int v[flex] = {10,20,30,40};
 
Of course, 'flex' arrays would need to be implemented. The point is that
such syntax for them is more robust and also tidier (and more consistent
with existing arrays) than the C++ where such things have to be
implemented using its language building features. And the syntax for
invoking those has limitations.
 
 
--
bart
red floyd <no.spam@its.invalid>: Jul 10 08:22AM -0700

On 07/07/2018 07:27 PM, Alf P. Steinbach wrote:
>                 );
>         }
>     ...
 
OK, I'll ask the obvious.
 
Why (*this).Itemlist instead of this->Itemlist
 
I'm assuming the explicit refernce to this is due to some template
weirdness. Otherwise the question becomes, why explicitly specify
"this"?
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 10 05:44PM +0200

On 10.07.2018 17:22, red floyd wrote:
 
> I'm assuming the explicit refernce to this is due to some template
> weirdness.  Otherwise the question becomes, why explicitly specify
> "this"?
 
This is a should-have-been-simple-really forwarding to the base class
`operator<<`, which is rvalue-qualified.
 
The rvalue qualification means that it must be called on an rvalue
expression. I would be happy to learn of some better way than the
`move(*this)`. It was the first I could think of, but it is very very
ugly to my eyes... So, suggestions/ideas/knowledge very welcome.
 
It's rvalue-qualified so the machinery can be used to construct a menu
in a single expression, like this (it's my actual code at the moment):
 
 
$with( gui_ext::Auto_parent{ *this } )
{
using namespace gui_ext::menu_data;
const auto& menubar = *new gui_ext::Menu_bar{
Itemlist{}
<< (Sub{ "App" }
<< Text_item{ 0, "Blah" }
<< Text_item{ 0, "Blah blah" }
<< Separator{}
<< Text_item{ Cmd::app_exit, "Exit" })
<< (Sub{ "Help" }
<< Text_item{ 0, "Help" }
<< Separator{}
<< Text_item{ Cmd::help_about, "About" }),
[this]( const int id ) { on_menuitem_picked( id ); }
};
 
...
 
 
In between the resulting FLTK menu bar and the pure data Itemlist's <<
machinery, is a generator class Menu_bar that translates the hierarchy
of menu items to FLTK menu text paths, for FLTK menu creation. Yes, it's
incredible, but one uses the actual country-specific menu text, forming
a path with "/" as separator, to specify an item's hierarchical
position. It's so insane that I could not believe it, I wasted a day
searching for the more normal functionality that I felt had to be there.
 
Another thing about FLTK, it has an implicit-parent window scheme where
any new widget is automatically put, hence no explicit parent specs above.
 
The translation code, mapping the hierarchy of menu data items to FLTK
widget, is in the constructor of Menu_bar. It's currently some 70+
lines, far more than I consider reasonable for a function body. But I
see no good simple ways to refactor it. I can post it here if someone's
willing to take a look and say, you idiot Alf, here's how to do it. E.g.
recursive instead of my iterative code, or something?
 
 
Cheers!,
 
- Alf
Rosario19 <Ros@invalid.invalid>: Jul 10 06:00PM +0200

On Mon, 9 Jul 2018 10:23:25 +0200, "Alf P. Steinbach" wrote:
 
>>> struct Sub
>>> : Text_item
>>> , Itemlist
 
here ther is for me the 1 problem
class sub:Tex_item could mean that sub is a 'subset' of class Tex_item
(this possible is ok)
what does it mean "sub:Tex_item,Itemlist" (the ",Itemlist")?
 
>>> {
>>> template< class Item >
>>> auto operator<<( Item item ) &&
 
i never used auto, but here the problem is for me conceptual: what
does it mean "&&"? it appear it means "reference reference"
i never tought on that nor used
than i miss 100% the meaning of:
 
"auto operator<<( Item item ) && -> Sub&&"
 
>>> -> Sub&&
>>> {
>>> return static_cast<Sub&&>(
 
i used only C cast ()
 
>>> move( *this ).Itemlist::operator<<( item )
 
this would mean that move has as argument *this, its result is one
type has one .Itemlist::operator<<()
apply to item...
 
Manfred <noname@add.invalid>: Jul 10 05:56PM +0200

On 7/10/2018 4:02 PM, Bart wrote:
 
> The end result was presumably to create an instance of a vector of
> size_t initialised to N elements set to some values (I suppose I could
> have initialised mine to ten 20s).
 
C++ gives you that, it is called initializer list, and this is what you
came across - the defining syntax is a brace-enclosed list of elements,
separated by commas.
This is different from the 2 argument /constructor/ (no list) which
takes 1 value and a number of elements.
These are two logically different constructs, which justify the
different syntax.
 
> same as you might get in Python or Ruby in Javascript; the details will
> vary but you will get the values 10, 20, 30, and 40 printed out in some
> form and in that order.
 
Well, C++ does not have a default output for all types - in fact there
are 2 kind of outputs: the one inherited from C (stdio) and the standard
C++ library, which basically offers output operators for fundamental
types (ints, floats, strings) and little (or nothing?) more, it's that
simple!
 
Yes, this requires that you write output operators for more complex
types (or use a library), but a) in any serious project you /want/ to do
just that, so that /you/ control the output format, and b) you don't
have to learn what is the default output for those types (C++ is big
enough without adding this too, I believe)
In fact the examples of Python, Ruby, Javascript are IMHO only good for
contexts where the actual output format is not relevant, and this is
IMHO only acceptable for e.g. in-house tools. Moreover, these languages
require that you learn what is the default format, and how to override
it, which I find annoying whenever I need to control my own output.
 
 
> Or superimpose a user type on it that requires a certain output style
> that will use a dedicated stringify routine. But for quickly displaying
> the value(s) of a variable, it doesn't matter.
 
In C++ you would do neither, you would define a custom insertion
operator (operator <<) that does the job without the need to modify the
type system.
 
 
> (How would a debugger for C++ display such a vector?)
(both VS and gdb display it their own way)
>>> C++ seem to promise this sort of simplicity in user code (even in a
>>> static language rather than my dynamic examples), but I'm not seeing it.
>>> The user code syntax seems rather fragile.
I believe it can be agreed that simplicity is not a promise of C++, in
fact it seems that nowadays Bjarne is concerned that the language is
becoming (has already?) too complex.
 
 
> I'm saying it is fragile.
 
> What are we declaring here? Some sort of flexible, ie. expandable array
> of a specific type?
 
Recalling:
std::vector<std::size_t> v(10, 20);
 
This declares an object v of type "vector of size_t's" which is a
template instantiation of a class template defined in the standard
library (which is the same as a user-defined template as far as the
language is concerned).
I see nothing fragile in it, and it is clearly different from a raw
array (which would be:
size_t v[length];
)
 
You may say it is complex or verbose, but I wouldn't define it fragile.
 
 
You can express that in C with a tweak in the syntax:
> with existing arrays) than the C++ where such things have to be
> implemented using its language building features. And the syntax for
> invoking those has limitations.
 
The way I see it, having flex arrays look like ordinary arrays, but
behave differently, would be more fragile than std::vector, and if they
were implemented in the language itself instead of a library, they would
make the whole language more fragile (i.e. rigid and hard to maintain)
Manfred <noname@add.invalid>: Jul 10 08:01PM +0200

On 7/10/2018 7:23 PM, Stefan Ram wrote:
 
> int main(){ two_argument_constructor_no_list INITIALIZER_LIST; }
 
> transcript
 
> two_argument_constructor_no_list
 
;)
 
http://shop.oreilly.com/product/0636920033707.do
Item 7
Vir Campestris <vir.campestris@invalid.invalid>: Jul 10 11:11PM +0100

> You ever read the STL source code? Its enough to make anyone weep. There's
> no reason a similar library (albeit without the templating) couldn't be
> written in C and then the application code using it would look a lot tidier.
 
The whole point of the standard TEMPLATE library is the templates.
 
But yes, I have read it. And yes, it's horrible.
 
Andy
Vir Campestris <vir.campestris@invalid.invalid>: Jul 10 11:20PM +0100

On 10/07/2018 07:29, Juha Nieminen wrote:
 
> it just seems needlessly complicated for no good reason. Everybody and
> their grandmother understands "int main()", and using the trailing type
> syntax serves mostly the use of making the code harder to read.
 
I'll bite.
 
Back when C was invented the return type should have been last. After
all, it's the last thing you'll need from the function. But it wasn't.
 
Now there are reasons for having it last, and that's why the new syntax.
 
Trouble is we're all old fashioned C programmers at heart, and don't
like change... so the new one looks odd.
 
If you ever start on a green field project with a code standard that
forces it you'll be used to it in 3 months, and the old one will look odd.
 
(but I don't think I've started on a greenfield project since 19-something)
 
Andy
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 10 09:14AM -0400

On 7/10/2018 8:48 AM, Bo Persson wrote:
> So, starting from scratch might look promising initially, but...
 
It is generally foolish to start from scratch. Building on the labor
of prior efforts is most desirable. But still there are valid reasons
to do it. If you don't have desirable licensing for the software, then
you have to start from scratch. If you have specific goals that aren't
possible otherwise from the software at hand (such as my case with CAlive
where I wish to create something from inception designed to honor my
Lord and Savior Jesus Christ, that's simply something not possible using
existing software that was from inception created for other purposes
(Matthew 12:30)). And there are reasons relating to innate design. It
is sometimes better to start over than it is to refactor. But...
 
It takes A LOT of work to author, debug, and adequately expand soft-
ware to meet the needs of a reasonable project. It is almost always
better to take what you have, sit down in long planning meetings, re-
group, refocus, rewrite portions, document what you have, extend the
API, add additional code, remove or combine lesser-used code, and
perform some kinds of general refactoring than it is to start from
scratch.
 
I'm also realizing the sometime benefits of simple things like flat
data files, console-based interfaces for increased productivity in
certain circumstances, the ability to have complex viewers available
at the debugger level, etc.
 
"The right tool for the right job" takes on increasing meaning the
more "advanced" I get in my development.
 
I'm also beginning to see just how far we went off course embracing
OS designs like Windows. It would've been better to extend DOS to
include driver frameworks which run atop the existing API. Code for
DOS was so much simpler than code for a modern OS. And it doesn't
need to be more complex today. A similar API extended to facilitate
the needs of user requirements would've been doable. In fact, I'm
thinking the further I get into design and support for development
of my OS, just how much should be removed for greater simplicity. A
modern 64-bit OS with GUI abilities should be able to run in a few
MB of source code. It does this by sticking closer to the hardware,
and further away from abstraction. But, we'll see. I could be wrong.
 
--
Rick C. Hodgin
boltar@cylonHQ.com: Jul 10 01:50PM

On Tue, 10 Jul 2018 13:54:57 +0100
>>> for an "owning" pointer which frees memory automatically.
 
>> I didn't find the videos.Do you have the links?
 
>Try: https://inductive.no/jai/
 
I'm immediately suspicious when someone calls a programming language "exciting".
Languages may be useful, interesting or clever, but they're never exciting.
Overuse of hyperbole using means a load of tedious crap is to follow. Mind you,
he's certainly been busy writing his own praises on wikipedia. I'm thinking
Mr Blow is a good case of nominative determinism.
Thiago Adams <thiago.adams@gmail.com>: Jul 10 10:04AM -0700

On Tuesday, July 10, 2018 at 9:39:50 AM UTC-3, Thiago Adams wrote:
> > bad idea and in another video he introduces a special pointer syntax
> > for an "owning" pointer which frees memory automatically.
 
> I didn't find the videos.Do you have the links?
 
Maybe is this one:
 
Constructors, Destructors
https://youtu.be/8C6zuDDGU2w?list=PLmV5I2fxaiCKfxMBrNsU1kgKJXD3PkyxO
Vir Campestris <vir.campestris@invalid.invalid>: Jul 10 09:57PM +0100

On 10/07/2018 11:41, Bart wrote:
> To hear people on these groups tell it, Windows is hopeless for software
> development.
 
IMHO Visual Studio is the best IDE out there.
 
These days I'm writing semi-embedded Linux stuff, and I miss Visual
Studio. I haven't found a Linux one as good.
 
Andy
Ian Collins <ian-news@hotmail.com>: Jul 11 09:57AM +1200

On 11/07/18 08:57, Vir Campestris wrote:
 
> IMHO Visual Studio is the best IDE out there.
 
> These days I'm writing semi-embedded Linux stuff, and I miss Visual
> Studio. I haven't found a Linux one as good.
 
Visual Studio Code?
 
https://code.visualstudio.com/
 
--
Ian.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 10 10:43PM +0100

Whilst coding my C++ JSON parser, "NoFussJSON", I used generic lambdas for
the first time. How cool/elegant are they? Look here:
 
case element::Number:
{
json_string newNumber{ currentElement.start, currentElement.start ==
nextOutputCh ? nextInputCh : nextOutputCh };
if (currentState == json_detail::state::NumberInt)
{
std::visit([this, &currentElement](auto&& arg)
{
buy_value(currentElement, arg);
}, string_to_number(newNumber.as_view()));
}
else
buy_value(currentElement, neolib::string_to_double(newNumber.as_view()));
}
break;
 
They make using variants a breeze. The variant in question here is the
result of string_to_number function which can be int32_t, uint32_t,
int64_t, uint64_t or double depending on the parsed number string.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
Jeff-Relf.Me @.: Jul 10 01:52PM -0700

% <persent@gmail.com>: Jul 10 01:56PM -0700

> Launch( L"/Program Files/Common Files/microsoft shared/ink/TabTip.EXE" ),
> PostMessage( Keyboard, WM_LBUTTONDOWN, 0, 0 ),
> PostMessage( Keyboard, WM_LBUTTONUP, 0, 0 );
 
wait until you see what a real computer can do
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 10 01:33PM -0400

Is there something like this:
 
class CWhatever
{
public:
// Mated constructor / destructor pair
CWhatever(... params ...)
{
// Constructor code here
std::cout << "Constructor" << std::endl;
 
} ~ {
// Mated destructor code here
std::cout << "Mated destructor" << std::endl;
}
 
// Generic destructor
~CWhatever()
{
// Generic destructor code here
std::cout << "Generic destructor" << std::endl;
}
 
// Other things here
};
 
Such that it would generate this output on use:
 
Constructor
Mated destructor
Generic destructor
 
--
Rick C. Hodgin
Ian Collins <ian-news@hotmail.com>: Jul 11 08:21AM +1200

On 11/07/18 05:33, Rick C. Hodgin wrote:
 
> Constructor
> Mated destructor
> Generic destructor
 
No.
 
There is only ever one destructor. If the work of the destructor
depends on how the object was construct, include a flag. This pattern
is uncommon.
 
--
Ian.
ram@zedat.fu-berlin.de (Stefan Ram): Jul 10 05:23PM

>takes 1 value and a number of elements.
>These are two logically different constructs, which justify the
>different syntax.
 
main.cpp
 
#include <iostream>
#include <ostream>
#include <string>
using namespace ::std::literals;
 
struct two_argument_constructor_no_list
{ two_argument_constructor_no_list
( int const one_value, int const a_number_of_elements )
{ ::std::cout << "two_argument_constructor_no_list\n"s; }};
 
#define INITIALIZER_LIST { 1, 2 }
 
int main(){ two_argument_constructor_no_list INITIALIZER_LIST; }
 
transcript
 
two_argument_constructor_no_list
ram@zedat.fu-berlin.de (Stefan Ram): Jul 10 05:30PM

>explains, and the nature of programming means that significant amounts
>of time get dedicated to "what is essentially busywork."
>without him fully realizing that.
 
»Much of the relative simplicity of Java is — like for
most new languages — partly an illusion and partly a
function of its incompleteness. As time passes, Java
will grow significantly in size and complexity. It will
double or triple in size and grow implementation-
dependent extensions or libraries.«
 
Bjarne Stroustrup, 1995
 
Today (2018), the renowned Java expert Joshua Bloch
acknowledged that Bjarne Stroustrup was right.
Tim Rentsch <txr@alumni.caltech.edu>: Jul 10 06:51AM -0700


> I never realised you could do that with C function parameters.
> Is that C99? It just shows that one is never too old to learn
> something new!
 
The construction is called a compound literal, and indeed was
added in C99. The syntax for it is
 
( type-name ) { initializer-list }
 
(and as usual the initializer-list is allowed an optional
trailing comma). It creates an object of automatic storage
duration in the smallest enclosing block, initialized each time
the compound literal is reached. Oh by the way it isn't just
function arguments, compound literals can be used as regular
expressions, with the same precedence level as function calls
or array indexing.
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)