Wednesday, May 15, 2019

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

"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 15 09:39AM -0700

On Saturday, May 11, 2019 at 7:00:24 AM UTC-4, Mr Flibble wrote:
> A) Your bible is false.
> B) Your god the existence of which is predicated on your bible being true
> is, given (A), also false.
 
Leigh, would you back up your statements with those facts you
believe make the certification you stamp upon these claims
valid?
 
You claim, "A) Your bible is false," as the fundamental premise,
making your B) claim therefore assertive as well.
 
What is your bottom-line, most easy to assert and believe state-
ment / belief that A) is true above?
 
And, more importantly, if it can be demonstrated that your many
claims for A) being true are, in fact, false ... will you own up
to it and change your position?
 
In short: Do you seek the truth here? Or are you only asserting
something you personally hold / believe?
 
--
Rick C. Hodgin
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 15 09:20PM +0100

On 15/05/2019 17:39, Rick C. Hodgin wrote:
> to it and change your position?
 
> In short: Do you seek the truth here? Or are you only asserting
> something you personally hold / believe?
 
We have already been over this. Evolution falsifies Genesis m8.
 
/Flibble
 
--
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who
doesn't believe in any God the most. Oh, no..wait.. that never happens." –
Ricky Gervais
 
"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."
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 15 01:24PM -0700

On Wednesday, May 15, 2019 at 4:21:05 PM UTC-4, Mr Flibble wrote:
> We have already been over this. Evolution falsifies Genesis m8.
 
This is my point. Evolution is disproven by genetics, but you
do not accept that. You also cannot prove evolution, because
it's never been seen to exist at a macro scale (a dog becomes
a non-dog), but you do not accept that. The Biblical explanation
of how the species propagate out from the original source animal
(or plant or insect) is not accepted by you, even though it literally
exactly mirrors what we see in this world (like taking a mutt dog
and selectively breeding it to get poodle-like offspring, and great
dane-like offspring, etc., over geneations).
 
You won't accept the proof that exists which disproves evolution.
 
You won't even listen to the supporting evidence.
 
You are not seeking the truth, because if you were you'd be willing
to listen to the evidence and push it, interrogate it, poke at it,
prod at it, pull back the covers, look inside, etc. You won't.
 
You self-condemn, Leigh.
 
--
Rick C. Hodgin
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 15 10:25PM +0100

On 15/05/2019 21:24, Rick C. Hodgin wrote:
> to listen to the evidence and push it, interrogate it, poke at it,
> prod at it, pull back the covers, look inside, etc. You won't.
 
> You self-condemn, Leigh.
 
And Satan invented fossils, yes?
 
/Flibble
 
--
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who
doesn't believe in any God the most. Oh, no..wait.. that never happens." –
Ricky Gervais
 
"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."
Ian Collins <ian-news@hotmail.com>: May 15 05:01PM +1200

On 15/05/2019 01:56, Thiago Adams wrote:
> - __FILE__ __LINE___
> - Literal strings (I prefer macros than const char * )
> - constants ( I am not using constexpr yet)
 
__FILE__ and line __LINE__
 
and a few macros passing them along with function names, functions and
arguments as parameters, such as
 
#define Check( fn, args ) \
utils::Exception::check( #fn, fn args, __FILE__, __LINE__ )
 
where check is
 
static int check( const char* fn,
int result,
const char* file,
int line );
 
--
Ian.
Paavo Helde <myfirstname@osa.pri.ee>: May 15 08:39AM +0300

On 15.05.2019 1:09, Alf P. Steinbach wrote:
> source location information. More DRY, Don't Repeat Yourself.
 
> Maybe it will be part of C++23?
 
> Of course, with that class' magic one will be able to ditch the macro.
 
Looking forward to it!
 
 
> Instead of one specific macro for each kind of thing one wants to have
> constructor and destructor execution of, I suggest using just one or two
> general macros.
 
Mutex locks are the only place where I have ever needed this kind of
macro, so for me there is no need for generalization. YMMV, of course.
 
 
> PH_WITH(boost::mutex::scoped_lock(mx)) {
> // Code here
> }
 
IIRC in C# the "with" construct is the poor man's substitute for RAII.
In C++ we have real RAII.
 
If we are speaking about language extensions, then I would rather see an
extension like [[must_have_scope]] which could be attached to the lock
class definition and would prohibit using it in such a way that there is
no other code executed between its ctor and dtor.
 
> ///
> #define PH_WITH_CONST( ... ) \
> if( const auto& _ [[maybe_unused]] = __VA_ARGS__; true )
 
This would not get rid of the macro...
 
> foo( myvec.Data<dispatch_t>(), myvec.Size(), 42 )
> }()
> );
 
Yes, lambdas might be a cleaner solution. Using decltype to rediscover
the type seems interesting. And with lambdas I believe many usages can
be put inline in the lambda so that I do not need to define artificial
helper functions with cumbersome names, and can replace a lot of
parameter passing boilerplate with the automatic lambda capture.
 
Thanks for suggestions!
Paavo Helde <myfirstname@osa.pri.ee>: May 15 08:55AM +0300

On 15.05.2019 1:38, Bart wrote:
>>> myvec.ElemType(), foo, (myvec.Data<dispatch_t>(), myvec.Size(), 42));
 
>> If you want to get rid of the C11 style macros,
 
> My own view is that the above code should be taken out and shot.
 
Agreed the macro approach is ugly.
 
> (Each invocation would presumably repeat all this code at each
> invocation point. But if it's only used once, then why use the macro.
 
No, the macro is defined once, and used ... let me grep ... 184 times.
Maybe you missed that the macro can call an arbitrary template function
with arbitrary number of arguments.
 
There are a couple of other similar macros like DISPATCH_INTEGER and
DISPATCH_FLOATING, but these are also defined once and used many times.
 
> However, there is also a clear pattern here, and there must be a better
> way of doing it (whatever it is)).
 
There probably is a better way. Alf's suggestions about lambdas look
promising. These macros predate lambdas about 10 years so maybe it's the
time for a facelift indeed.
Thiago Adams <thiago.adams@gmail.com>: May 15 04:36AM -0700

On Tuesday, May 14, 2019 at 7:38:19 PM UTC-3, Bart wrote:
 
> where these special names are known to the compiler and get substituted
> for the actual module name, and actual source line number. No special
> macros, no special classes, all very easy.
 
For C and C++ the preprocessor needs to be more integrated with
the compiler and then __FILE__ and __LINE__ could be especial
identifiers just like __func__.
 
Because compiler and preprocessor are separated you can imagine that
the compiler is not seen files and lines anymore, just tokens.
For __func__ this works but for __FILE__ and __LINE__ not.
 
I will just add this as another reason why I think preprocessor
should be integrated with the compiler.
 
 
I read about std::experimental::source_location but is not clear
how it works. I think they should proposed a basic feature that
allow this class to exist.
"Öö Tiib" <ootiib@hot.ee>: May 15 07:31AM -0700

On Tuesday, 14 May 2019 16:56:58 UTC+3, Thiago Adams wrote:
> - Literal strings (I prefer macros than const char * )
> - constants ( I am not using constexpr yet)
> -
 
Macros go nowhere until reflection is only possible with preprocessor.
We will need to print variable's name, enumerator's name, function's
name or the whole expression or the source code file path as readable
text at places. That is useful feature and only preprocessor provides
that feature.
 
The features of preprocessor are better to read used through macros.
Otherwise our code can contain number of repetitive things like:
 
fprintf(stderr, "%s - Internal error: "
"negative string length %d"
"at %s, line %d.",
timetext(), length,
__FILE__, __LINE__);

The parts of that repetitive garbage that are macros (like __FILE__
and __LINE__) can only be reduced out with macros. I mean that
most of us want to have bloat-free interface like:
 
report_internal_error("negative string length %d", length);
 
Also most of us want it to print rest of stuff too like the fprintf did
above. So we have to have report_internal_error as a macro.
Bart <bc@freeuk.com>: May 15 05:19PM +0100

On 15/05/2019 15:31, Öö Tiib wrote:
 
> report_internal_error("negative string length %d", length);
 
> Also most of us want it to print rest of stuff too like the fprintf did
> above. So we have to have report_internal_error as a macro.
 
void report_internal_error(char* message, int length,
char* file=__FILE__,
int lineno=__LINENO__) {
fprintf(stderr, "%s - Internal error on line %d in %s\n",
timetext(), lineno, file);
fprintf(stderr, message, length);
fprintf(stderr,"\n");
}
 
Used as:
 
report_internal_error("negative string length %d", length);
 
No extra macros needed beyond __LINE__ and __FILE__, and these are easy
candidates to become special compiler variables (they are predefined
macros so are already special).
 
But it does need:
 
- Default parameter values
 
- For this example to work, the expansion of the __LINE__ etc must be
done at the call-site (mentioned this is in a previous post).
 
So looking ahead to more useful alternatives, rather than building more
and more stuff that absolutely needs to use macros.
"Öö Tiib" <ootiib@hot.ee>: May 15 10:11AM -0700

On Wednesday, 15 May 2019 19:19:18 UTC+3, Bart wrote:
> }
 
> Used as:
 
> report_internal_error("negative string length %d", length);
 
But that does not work with anything.
 
 
> - Default parameter values
 
> - For this example to work, the expansion of the __LINE__ etc must be
> done at the call-site (mentioned this is in a previous post).
 
C preprocessor does not have such concept of "call site". For it most
of our program code is just random pile of text from what it searches
its directives and macros and then rearranges, alters, inserts and
erases it based on those directives and macros.
 
If you have some wiser preprocessor, then paste its link in github
here and let's have a look. ;)
 
> So looking ahead to more useful alternatives, rather than building more
> and more stuff that absolutely needs to use macros.
 
You are joking? The example I did choose was what people have used
last 30 years at least but the function you posted just does work with
nothing that I know of.
Bart <bc@freeuk.com>: May 15 07:14PM +0100

On 15/05/2019 18:11, Öö Tiib wrote:
 
> You are joking? The example I did choose was what people have used
> last 30 years at least but the function you posted just does work with
> nothing that I know of.
 
I thought that (1) the C++ group was more receptive to new ideas; (2)
that part of the purpose of the thread was how existing macro usage
could be replaced by something new.
 
What I proposed could be done with new additions, and in fact Alf
already posted a link to something that can added to a future C++ to
help with this particular requirement.
 
However, I can write the above today in one of my languages (here using
C's printf to keep it more familiar; in this language access to C's
stderr is tricky):
 
proc reporterror(ichar mess, int param, lineno=$lineno,
ichar modulename=$modulename) =
printf("Internal error on line %d in module %s:\n ",
lineno, modulename)
printf(mess, param)
printf("\n")
end
 
And called like this, these calls being on lines 15, 16 and 17 of my
test program 't.ext':
 
reporterror("Error1 %d",813)
reporterror("Error2 %d",4909)
reporterror("Error3 %d",75)
 
Output is this:
 
Internal error on line 15 in module t:
Error1 813
Internal error on line 16 in module t:
Error2 4909
Internal error on line 17 in module t:
Error3 75
 
(I had to tweak the processing of '$lineno' so that it is expanded
later, and takes on the location of the invoking code.)
 
So it's not like this stuff is impossible. My implementation doesn't
involve macros, and I can write it now.
Paavo Helde <myfirstname@osa.pri.ee>: May 15 09:55PM +0300

On 15.05.2019 21:14, Bart wrote:
> printf(mess, param)
> printf("\n")
> end
 
It appears in your language there are no semicolons between the
statements. I wonder how do the assignments look like?
Thiago Adams <thiago.adams@gmail.com>: May 15 12:10PM -0700

On Wednesday, May 15, 2019 at 3:14:18 PM UTC-3, Bart wrote:
> >> fprintf(stderr, message, length);
> >> fprintf(stderr,"\n");
> >> }
 
C#, that doesn't have a separated preprocessor (it is not like
C preprocessor) ant it doesn't support macro expansion.
They found a solution for __LINE__ and __FILE__.
 
Caller Information has been added to .NET 4.5
https://stackoverflow.com/questions/696218/do-line-file-equivalents-exist-in-c
 
It is an attribute:
 
public void Log(string message,
[CallerFilePath] string filePath = "",
[CallerLineNumber] int lineNumber = 0)
{
// Do logging
}
 
I didn't like this approach but it is interesting to see
alternatives.
 
 
Rust has:
https://doc.rust-lang.org/std/macro.file.html
 
I don't know how macros works in Rust but they are probably different
from C.
 
 
In my opinion it should be __line__ and __file__ just like
__func__ and compilers do what is necessary to implement it.
Bart <bc@freeuk.com>: May 15 08:18PM +0100

On 15/05/2019 19:55, Paavo Helde wrote:
>>      end
 
> It appears in your language there are no semicolons between the
> statements. I wonder how do the assignments look like?
 
Plenty of languages have learnt how to do without semicolons. Which
makes sense since even 'free-format' language syntax is predominantly
written in a line-oriented format.
 
Here however the semicolons are still needed to separate statements.
It's just that end-of-line is interpreted as a semicolon (save when the
line obviously continues onto the next, eg. after "("). Extra semicolons
are also harmless.
 
(This is a more extensive program in that syntax (first assignment on
line 91):
 
https://github.com/sal55/qx/blob/master/lisp.m
 
Zero semicolons in 2000 lines, except inside string constants. There are
also zero macros.
 
Note this is not working code; it's been auto-converted from C as an
experiment in visualisation. The difference from the original C is striking:
 
https://github.com/sal55/qx/blob/master/lisp.c
peteolcott <Here@Home>: May 15 01:11PM -0500

In AI research the following can be used to anchor the notion of
[truth conditional semantics] in a single [axiom schema True(x) predicate]
for the [knowledge ontology inheritance hierarchy].
 
Because valid deduction from true premises necessarily derives
a true consequent we know that the following predicate pair
consistently decides every deductively sound argument.
 
The notion of complete and consistent formal systems is exhaustively
elaborated as conventional formal proofs to theorem consequences
where axioms are stipulated to be finite strings with the semantic
property of Boolean true.
 
// LHS := RHS the LHS is defined as an alias for the RHS
∀x True(x) := ⊢x
∀x False(x) := ⊢¬x
 
Introduction to Mathematical logic Sixth edition Elliott Mendelson (2015) Pages 27-28
http://liarparadox.org/Provable_Mendelson.pdf
 
 
 
--
Copyright 2019 Pete Olcott
All rights reserved
"Öö Tiib" <ootiib@hot.ee>: May 15 06:39AM -0700

On Tuesday, 14 May 2019 16:25:13 UTC+3, Thiago Adams wrote:
> #pragma PUSH SCOPE -assert
 
> #define assert redefing_assert_here
 
> #pragma POP SCOPE
 
Interesting things. Something close to those is already
implementable using some preprocessor metaprogramming.
Some tricks generating needed #ifdef, #ifndef, #define,
#undef and #include directives.
 
I am still skewed towards defining NOMINMAX either as
default command line option or before including windows.h
in that stdafx.h or pch.h or whatever it is. It will be less to
type than those pragmas (or calls of metaprogramming
macros) and more pleasant for eye to read. Kind of done
once and then forgotten forever with works(TM).
Thiago Adams <thiago.adams@gmail.com>: May 15 07:10AM -0700

On Wednesday, May 15, 2019 at 10:40:11 AM UTC-3, Öö Tiib wrote:
...
> type than those pragmas (or calls of metaprogramming
> macros) and more pleasant for eye to read. Kind of done
> once and then forgotten forever with works(TM).
 
I put the sample of windows.h min/max just as reference.
I am not worried about this specific case.
 
At the #scope proposal pdf (A simple scoping mechanism for
the C/C++ preprocessor) we can find more motivation at 'the
problem' section.
 
"
The problem
We need to protect code, especially code in header files, from
accidental matches of macros. The basic traditional defense is to
define all macros as ALL_CAPS and never define other identifiers
with all capital letters. Unfortunately, in much code not all macros
are ALL_CAPS and some identifiers (notably some enumerators and some
consts) are defined using all capital letters (and thus especially
vulnerable to macro substitution). All useful programs must use
headers, but we cannot control how macros are defined in headers
nor can a writer of a header control how an #includeing program
use identifiers.
Therefore, "house style rules" cannot in general prevent accidents,
and errors are common.
These problems are well known and partially effective remedies
are widely adopted. However, there is a huge variety in the kind
of remedies adopted and the degree to which they are systematically
applied. In all cases, the result is defensively written code
that to various degrees departs from the ideal expression of the
ideas it represents.
 
The seriousness of this problem increases with the number of macros used,
the number of headers included, and the number of independent sources
of headers. Most large organizations – even quite mature and experienced
ones – are regularly "bitten" by macro.
 
"
 
The main point for me is:
 
"Unfortunately, in much code not all macros
are ALL_CAPS and some identifiers (notably some enumerators and some
consts) are defined using all capital letters (and thus especially
vulnerable to macro substitution). All useful programs must use
headers, but we cannot control how macros are defined in headers
nor can a writer of a header control how an #includeing program
use identifiers. "
 
for C++, modules will help this I guess.
"Öö Tiib" <ootiib@hot.ee>: May 15 09:23AM -0700

On Wednesday, 15 May 2019 17:11:05 UTC+3, Thiago Adams wrote:
> headers, but we cannot control how macros are defined in headers
> nor can a writer of a header control how an #includeing program
> use identifiers. "
 
I agree. But the motivator is not really motivator for me. There *will*
*be* *defects* that are caused by incompatibilities introduced by
cooperation in huge and deep, potentially recursive cascade of
header writers and header includers. These will be there. Period.
 
It is way wider issue than macros and even orthogonal to
macros. Some sort of macro scopes added may simplify fixing
a subset of those defects caused but in general that will just
complicate the things up even more and worse.
 
> for C++, modules will help this I guess.
 
Yes. The modules can not be some kind of rocket science.
Look at PASCAL module (unit) as example:
 
unit UnitName;
interface
 
{* declare your
interface here. *}
 
implementation
 
{* define your
implementation and
internal stuff here. *}
 
Usage of that unit in other module is like that:
 
uses UnitName;

That was so done at 1970 and works perfectly, no complaints.
The obvious question arises then why in C++ we need to
#include millions of lines of irrelevant to us code of typical
#include cascade into each cpp file for to call couple of
functions from elsewhere? If it is because compiler wants to
optimize that whole call cascade that might form that way
then who holds it back from doing that without it all being
vomited onto my table? I still want to see the names in
interfaces that I have said that I use and not to see anything
else. Easy.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 15 07:55PM +0200

On 14.05.2019 15:24, Thiago Adams wrote:
 
> "I am using all macros except min"
> #pragma PUSH SCOPE -min
> #pragma POP SCOPE
 
AFAIK `#pragma push_macro` is already supported by Visual C++ and g++,
hence presumably also Intel and Dang. It's not quite as general as what
you outline. But mostly what's needed in practice.
 
Good luck working for standardization of existing `#pragma` practice.
 
The case of `#pragma once` shows that it's not easy.
 
 
[snip]
Cheers & hth.,
 
- Alf
Thiago Adams <thiago.adams@gmail.com>: May 15 04:43AM -0700

On Tuesday, May 14, 2019 at 7:23:14 PM UTC-3, Nikki Locke wrote:
 
> If you know of a library which is not in the list, why not fill
> in the form at http://www.trumphurst.com/cpplibs/cppsub.php
 
> Maintainer: Nikki Locke - if you wish to contact me, please use the form on the website.
 
Hi, At
Tools for C++ Programmers
See
Cback - Cfront optimiser
 
There is no link just e-mail. Is this correct?
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)