Saturday, June 29, 2019

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

Jorgen Grahn <grahn+nntp@snipabacken.se>: Jun 29 02:55PM

On Sat, 2019-06-29, Stefan Ram wrote:
...
 
Lots of things are more important than C++, but they are still
offtopic here.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Keith Thompson <kst-u@mib.org>: Jun 29 02:23PM -0700

> Subject: Re: What does C++ say about climate change?
 
Nothing.
 
> »"Goodbye, " << "Planet!"«
 
> n4800, 28.10.3.4 Member functions [syncstream.osyncstream.members]
 
In context, it's simply a phrase in contrast to "Hello, World!".
 
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 29 10:36PM +0100

On 29 Jun 2019 12:09:08 GMT
 
> n4800, 28.10.3.4 Member functions [syncstream.osyncstream.members]
 
> (It might sound cynical, but when people are driving
> 90 miles an hour down a dead-end road what else is left?)
 
I think that by mistake you posted to the wrong group. C++ says nothing
about climate change. C++ is a programming language.
 
Evidence indicates beyond reasonable dispute that global temperatures
are rising, partly because of human intervention. Sea levels are about
2cm higher than 200 years ago. They are about 130 metres higher than
at the end of the last glaciation maximum, mainly because of natural
temperature and climate variation because we are now in an inter-glacial
period of an ice age. Sea levels are still over 200 metres lower than
they were 100 million years ago (a blink of the eye geologically
speaking). 250 million years ago Antartica was forested even though it
was only somewhat further north than now, because the joining of the
North and South American continents had not then occured so
extinguishing trans-global currents. For the larger part of earth's
history there has been no permanent ice on both poles: ice ages such as
the present one are typically unusual (plate techtonics have been a big
driver of climate variation): in earth's history there have been at
least 5 of them. One of them (the Cryogenian) may have produced a
"snowball earth" with ice sheats to the equator.
 
Carbon dioxide absorption by silicate weathering will in due course
become a threat to bio-diversity (100 to 500 million years ahead) by
reducing carbon dioxide below the level required for the main form of
photosynthesis to occur (but new forms of vegetation will adapt).
Increased solar radiation is a bigger long term threat as nuclear fuel
is slowly expended, which at some point (approx 1 billon years ahead)
will cause thermal runaway and evaporation of the oceans, long before
the sun turns into a red giant. If technology is sufficiently existent
at that time, then it may possibly be averted technologically be
reflecting the radiation back into space. Nothing is likely to defend
when the sun becomes a red giant in some 5 billion years time, and
nothing at all will defend the subsequent extinguishment of solar
radiation.
 
As Private Fraser would say, "we are all doomed". We are all on your
dead-end road. (The universe is also, by virtue of the 2nd law of
thermodynamics - the universe has an arrow of time.)
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 30 01:21AM +0200

On 29.06.2019 23:36, Chris Vine wrote:
 
> As Private Fraser would say, "we are all doomed". We are all on your
> dead-end road. (The universe is also, by virtue of the 2nd law of
> thermodynamics - the universe has an arrow of time.)
 
Since we're off-topic and it's, well now it's Sunday already. Since it's
Sunday.
 
The last parenthetical remark, short as it is, contains a number of errors.
 
First, the application of a statistical law that applies to inert gases,
to the universe at large, is at best invalid. It's not the case that a
system of more interestingly interacting parts than inert atoms, is
necessarily likely to evolve towards an uninteresting homogeneous state.
Of course it depends on what one means by interesting, but. It's easy to
construct artificial systems, systems with less than totally inert
parts, that evolve in interesting ways without ever going into a
homogeneous state. If such a system is started in an apparently
homogeneous state it can/will evolve away from it, towards complexity.
 
To wit, the current generally accepted cosmological hypothesis, called
the Big Bang, has it that the universe started in a nearly completely
homogeneous state, and evolved to the interesting complex structure we
see around us.
 
Sad observation of the kind of science going on: the cosmological
principle is the idea that at a sufficiently large scale the universe is
still homogeneous. But every proposed and at the time accepted scale,
has been contradicted by observations, and this has happened many times.
Every time the idea, alleged fact, is refuted by observations of larger
structures, say roughly once a decade, it's relaunched with just an
adjustment of the scale, and worse, scientists then forget the history.
 
Secondly, the remark seems to equate increase of entropy with time.
 
For a sufficiently simple system, like the mentioned inert gas, a time's
arrow causes entropy increase. Necessarily, logically, because the
uninteresting gas-everywhere states are in the zillions compared to
those states that can be identified as not-gas-everywhere, and there's
no structuring process going on. So with a random walk to nearest states
it rapidly gets to gas-everywhere. But even in such a simple system it's
the time's arrow that drives the system evolution, not opposite. They're
not on equal terms, as one can readily see by implementing a simulation.
 
It pains me that the scientific community is at odds with both logic and
observations about this matter. I think it's like religion, or some
kinds of politics, or war. Everybody adopts or pretends to adopt the
belief that they see that everybody else, in particular authorities, say
they have. And so we had 2000 years of crystal spheres. And now a
hundred years at least of Big Bang and predicted entropic death of the
universe. Happily sooner or later there will be observations that
shatter the current variation of belief, like Tycho Brahe's comet
shattered the crystal spheres (or rather didn't), but as the repetitive
history of the cosmological principle shows, that may not be enough:
with a strong enough social force the theory is just amended.
 
Cheers!,
 
- Alf
G G <gdotone@gmail.com>: Jun 28 07:46PM -0700

are these checks still necessary or is there another way?
 
https://wiki.sei.cmu.edu/confluence/display/c/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow
 
Like:
 
#include <limits.h>

void f(signed int si_a, signed int si_b)
{
signed int sum;
 
if (((si_b > 0) && (si_a > (INT_MAX - si_b))) ||
((si_b < 0) && (si_a < (INT_MIN - si_b))))
{
/* Handle error */
}
else
{
sum = si_a + si_b;
}
 
/* ... */
}
 
to protect against over flow like: (that may happen)
 
void func(signed int si_a, signed int si_b)
{
signed int sum = si_a + si_b;
/* ... */
}
 
the code above is taken from:
 
https://wiki.sei.cmu.edu/confluence/display/c/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 29 05:54AM +0200

On 29.06.2019 04:46, G G wrote:
> }
 
> the code above is taken from:
 
> https://wiki.sei.cmu.edu/confluence/display/c/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow
 
Checks are still necessary when there is a possibility of overflow that
one wishes to handle. C++ has not gained any support for overflow
handling of integer arithmetic.
 
However, the checking can be simplified, possibly more efficient, and
modulo late-late-night + full-of-painkillers I think this doesn't rely
on C++20 requirement of two's complement form:
 
inline auto sign( const int x ) -> bool { return x < 0; }
 
void func( const int a, const int b )
{
const int sum = static_cast<int>( 0u + a + b );
const bool overflow =
(sign( a ) == sign( b ) and sign( sum ) != sign( a );
// ...
}
 
Disclaimer: off the cuff code.
 
Also, formally the `static_cast` here has implementation defined
behavior, IIRC. But hey.
 
An alternative can be to use floating point and rely on NaN. But there
is danger in there. The standard library's facilities for checking NaN
are not good enough to deal with GCC and MSVC fast float optimizations.
 
Cheers!,
 
- Alf
David Brown <david.brown@hesbynett.no>: Jun 29 11:56PM +0200

On 29/06/2019 04:46, G G wrote:
> }
 
> the code above is taken from:
 
> https://wiki.sei.cmu.edu/confluence/display/c/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow
 
Signed integer overflow is undefined behaviour in C++ (and C). There
are many ways to avoid overflowing, depending on the circumstances, the
operations you are doing, the target compiler (if portability is not a
concern), etc. In most cases, signed integer overflow is an error -
it's a case of garbage in, garbage out. And in most cases, a check like
you have made above is meaningless and inefficient because all it does
is check if the addition can be done with those types, without
overflowing. It is rare that you are adding two integers with unknown
origins, and unknown usage, and that adding them is all you are doing -
and thus rare that it makes sense to make a check like that. It is far
better to check for the validity of data when it comes in from the
outside, checking against sensible limits. And then make your
calculations valid for all sensible data (use bigger types if necessary).
G G <gdotone@gmail.com>: Jun 29 04:02PM -0700

> better to check for the validity of data when it comes in from the
> outside, checking against sensible limits. And then make your
> calculations valid for all sensible data (use bigger types if necessary).
 
I'm sure you don't mean me per se , but only cause I'm asking and showing
the code. But to ensure I'm not taking undue credit, the code is from a CERT
website, www.securecoding.cert.org from a search INT32-CPP.
At that site, they show many other concerns and suggestions how to mitigate.
Horizon68 <horizon@horizon.com>: Jun 29 02:52PM -0700

Hello,
 
 
My Universal Scalability Law for Delphi and FreePascal was updated to
version 3.22
 
I have implemented and enhanced this powerful tool.
 
I have included a 32 bit and 64 bit windows and linux executables called
usl.exe and usl_graph.exe inside the zip, please read the readme file
to know how to use it, it is a very powerful tool.
 
Now about the Beta and Alpha coefficients of USL:
 
Coefficient Alpha is: the contention
 
And
 
Coefficient Beta is: the coherency.
 
Contention and coherency are measured as the fraction of the sequential
execution time. A value of 0 means that there is no effect on
performance. A contention factor of 0.2, for instance, means that 20% of
the sequential execution time cannot be parallelized. A coherency factor
of 0.01 means that the time spent in the synchronization between each
pair of processes is 1% of the sequential execution time.
 
 
Also there is something very important to know, and here it is:
 
So to optimize more the criterion of the cost for a better QoS, you have
to choose a good delta(y)/delta(x) to optimize the criterion of the cost
of your system and you have to balance better between the performance
and the cost. You can read about my powerful tool and download it from:
 
https://sites.google.com/site/scalable68/universal-scalability-law-for-delphi-and-freepascal
 
 
Thank you,
Amine Moulay Ramdane.
woodbrian77@gmail.com: Jun 29 12:30PM -0700

On Thursday, August 30, 2018 at 11:50:04 AM UTC-5, Jorgen Grahn wrote:
> > So I guess this is still a problem for poll().
 
> Yes, and also for epoll(7). The problem/feature is in the kernel code
> that's underlying for all these functions.
 
It looks like this may finally be fixed. What I wrote last
year was about Linux 4.14. Now I have 4.19 installed and I
can't find any mention of this problem in the docs for poll,
(p)select or epoll. Am I missing something? Maybe my
perseverance is starting to pay off. Thanks.
 
 
 
Brian
Ebenezer Enterprises - In G-d we trust.
https://github.com/Ebenezer-group/onwards
alexo <alelvb@inwind.it>: Jun 29 05:18AM +0200

Il 29/06/19 00:53, Alf P. Steinbach ha scritto:
> formula, using that function. Because it discards the delimiter it stops
> at. Which means, in any way I think of using it, that it discards the
> parentheses.
 
What I wrote doesn't use the strok function. I analyzed the formula from
left to right skipping invalid letter combinations and analyzing
numerical coefficients.
I wrongly supposed that strok function could help me in the job, but it
is not so.
 
 
> whether there can be multi-digit integers in there. From what I remember
> of chemistry and quantum mechanics I guess the maximum number would be 7
> or less, maybe just 4? But guesswork doesn't make up for a clear spec.
 
The numerical coefficient theorically can be of any lenght, but usually
are not greater than, say, 15.
 
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 29 06:08AM +0200

On 29.06.2019 05:18, alexo wrote:
>> clear spec.
 
> The numerical coefficient theorically can be of any lenght, but usually
> are not greater than, say, 15.
 
OK. The following is a manual approach to lexing such formulas. I've
assumed that they can contain whitespace.
 
 
-------------------------------------- chemical-elements.hpp
#pragma once
#include <string_view>
 
namespace chemical
{
using std::string_view;
 
struct Element
{
int number;
string_view symbol;
string_view name;
};
 
constexpr Element elements[] =
{
{ 1, "H", "Hydrogen" },
{ 2, "He", "Helium" },
{ 3, "Li", "Lithium" },
{ 4, "Be", "Beryllium" },
{ 5, "B", "Boron" },
{ 6, "C", "Carbon" },
{ 7, "N", "Nitrogen" },
{ 8, "O", "Oxygen" },
{ 9, "F", "Fluorine" },
{ 10, "Ne", "Neon" },
{ 11, "Na", "Sodium" },
{ 12, "Mg", "Magnesium" },
{ 13, "Al", "Aluminium" },
{ 14, "Si", "Silicon" },
{ 15, "P", "Phosphorus" },
{ 16, "S", "Sulfur" },
{ 17, "Cl", "Chlorine" },
{ 18, "Ar", "Argon" },
{ 19, "K", "Potassium" },
{ 20, "Ca", "Calcium" },
{ 21, "Sc", "Scandium" },
{ 22, "Ti", "Titanium" },
{ 23, "V", "Vanadium" },
{ 24, "Cr", "Chromium" },
{ 25, "Mn", "Manganese" },
{ 26, "Fe", "Iron" },
{ 27, "Co", "Cobalt" },
{ 28, "Ni", "Nickel" },
{ 29, "Cu", "Copper" },
{ 30, "Zn", "Zinc" },
{ 31, "Ga", "Gallium" },
{ 32, "Ge", "Germanium" },
{ 33, "As", "Arsenic" },
{ 34, "Se", "Selenium" },
{ 35, "Br", "Bromine" },
{ 36, "Kr", "Krypton" },
{ 37, "Rb", "Rubidium" },
{ 38, "Sr", "Strontium" },
{ 39, "Y", "Yttrium" },
{ 40, "Zr", "Zirconium" },
{ 41, "Nb", "Niobium" },
{ 42, "Mo", "Molybdenum" },
{ 43, "Tc", "Technetium" },
{ 44, "Ru", "Ruthenium" },
{ 45, "Rh", "Rhodium" },
{ 46, "Pd", "Palladium" },
{ 47, "Ag", "Silver" },
{ 48, "Cd", "Cadmium" },
{ 49, "In", "Indium" },
{ 50, "Sn", "Tin" },
{ 51, "Sb", "Antimony" },
{ 52, "Te", "Tellurium" },
{ 53, "I", "Iodine" },
{ 54, "Xe", "Xenon" },
{ 55, "Cs", "Caesium" },
{ 56, "Ba", "Barium" },
{ 57, "La", "Lanthanum" },
{ 58, "Ce", "Cerium" },
{ 59, "Pr", "Praseodymium" },
{ 60, "Nd", "Neodymium" },
{ 61, "Pm", "Promethium" },
{ 62, "Sm", "Samarium" },
{ 63, "Eu", "Europium" },
{ 64, "Gd", "Gadolinium" },
{ 65, "Tb", "Terbium" },
{ 66, "Dy", "Dysprosium" },
{ 67, "Ho", "Holmium" },
{ 68, "Er", "Erbium" },
{ 69, "Tm", "Thulium" },
{ 70, "Yb", "Ytterbium" },
{ 71, "Lu", "Lutetium" },
{ 72, "Hf", "Hafnium" },
{ 73, "Ta", "Tantalum" },
{ 74, "W", "Tungsten" },
{ 75, "Re", "Rhenium" },
{ 76, "Os", "Osmium" },
{ 77, "Ir", "Iridium" },
{ 78, "Pt", "Platinum" },
{ 79, "Au", "Gold" },
{ 80, "Hg", "Mercury" },
{ 81, "Tl", "Thallium" },
{ 82, "Pb", "Lead" },
{ 83, "Bi", "Bismuth" },
{ 84, "Po", "Polonium" },
{ 85, "At", "Astatine" },
{ 86, "Rn", "Radon" },
{ 87, "Fr", "Francium" },
{ 88, "Ra", "Radium" },
{ 89, "Ac", "Actinium" },
{ 90, "Th", "Thorium" },
{ 91, "Pa", "Protactinium" },
{ 92, "U", "Uranium" },
{ 93, "Np", "Neptunium" },
{ 94, "Pu", "Plutonium" },
{ 95, "Am", "Americium" },
{ 96, "Cm", "Curium" },
{ 97, "Bk", "Berkelium" },
{ 98, "Cf", "Californium" },
{ 99, "Es", "Einsteinium" },
{ 100, "Fm", "Fermium" },
{ 101, "Md", "Mendelevium" },
{ 102, "No", "Nobelium" },
{ 103, "Lr", "Lawrencium" },
{ 104, "Rf", "Rutherfordium" },
{ 105, "Db", "Dubnium" },
{ 106, "Sg", "Seaborgium" },
{ 107, "Bh", "Bohrium" },
{ 108, "Hs", "Hassium" },
{ 109, "Mt", "Meitnerium" },
{ 110, "Ds", "Darmstadtium" },
{ 111, "Rg", "Roentgenium" },
{ 112, "Cn", "Copernicium" },
{ 113, "Nh", "Nihonium" },
{ 114, "Fl", "Flerovium" },
{ 115, "Mc", "Moscovium" },
{ 116, "Lv", "Livermorium" },
{ 117, "Ts", "Tennessine" },
{ 118, "Og", "Oganesson" }
};
} // namespace chemical
 
 
-------------------------------------- chemical_formula-Tokenizer.hpp
#pragma once
#include "chemical-elements.hpp" // chemical::(Element, elements)
#include <cppx-core/all.hpp> // <url:
https://github.com/alf-p-steinbach/cppx-core>
 
namespace chemical_formula
{
$use_std(
stoi, string_view
);
$use_cppx(
Map_, // A std::unordered_map with [] indexing of
const instance.
P_, // P_<T> is an alias for T*. It supports prefix
const.
p_first_of, p_beyond_of
);
namespace ascii = cppx::ascii; // ascii::is_*
 
struct Token
{
struct Kind{ enum Enum {
none,
element,
number,
left_parens = '(', right_parens = ')',
left_bracket = '[', right_bracket = ']'
}; };
 
Kind::Enum kind;
string_view text;
int n; // Only used for `element` and
`number`.
};
 
class Tokenizer
{
const string_view m_formula;
const P_<const char> m_p_beyond_formula;
 
Token m_current;
 
struct Symbols_to_elements_map:
Map_<string_view, P_<const chemical::Element>>
{
Symbols_to_elements_map()
{
auto& self = *this;
for( const chemical::Element& elem : chemical::elements ) {
self[elem.symbol] = &elem;
}
}
};
 
auto is_in_formula( const P_<const char> p )
-> bool
{ return p != m_p_beyond_formula; }
 
void find_token_that_starts_at( const P_<const char> p_start )
{
static const auto symbols = Symbols_to_elements_map();
 
const char first_char = *p_start;
if( ascii::is_digit( first_char ) ) {
P_<const char> p_beyond = p_start + 1;
while( is_in_formula( p_beyond ) and ascii::is_digit(
*p_beyond ) ) {
++p_beyond;
}
const auto text = string_view( p_start, p_beyond -
p_start );
try {
m_current = { Token::Kind::number, text, stoi(
p_start ) };
} catch( ... ) {
m_current = { Token::Kind::none, text, -1 };
}
} else if( ascii::is_uppercase( first_char ) ) {
P_<const char> p_beyond = p_start + 1;
while( is_in_formula( p_beyond ) and
ascii::is_lowercase( *p_beyond ) ) {
++p_beyond;
}
const auto text = string_view( p_start, p_beyond -
p_start );
try {
m_current = { Token::Kind::element, text,
symbols[text]->number };
} catch( ... ) {
m_current = { Token::Kind::none, text, -1 };
}
} else {
const auto text = string_view( p_start, 1 );
switch( first_char ) {
case '(': [[fallthrough]];
case ')': [[fallthrough]];
case '[': [[fallthrough]];
case ']': {
m_current = { Token::Kind::Enum( first_char ),
text, -1 };
break;
}
default: {
m_current = { Token::Kind::none, text, -1 };
}
}
}
}
 
void find_next_remaining_token()
{
P_<const char> p_start = p_beyond_of( m_current.text );
while( is_in_formula( p_start ) and ascii::is_whitespace(
*p_start ) ) {
++p_start;
}
if( p_start == m_p_beyond_formula ) {
m_current = { Token::Kind::none, string_view( p_start,
0 ), -1 };
return;
}
find_token_that_starts_at( p_start );
}
 
public:
auto current() const
-> Token
{ return m_current; }
 
auto is_at_end() const
-> bool
{ return p_first_of( m_current.text ) == p_beyond_of( m_formula
); }
 
void advance()
{
find_next_remaining_token();
}
 
Tokenizer( const string_view& formula ):
m_formula( formula ),
m_p_beyond_formula( p_beyond_of( formula ) ),
m_current{ Token::Kind::none, string_view( formula.data(),
0 ), -1 }
{
assert( m_current.text.data() == formula.data() );
find_next_remaining_token();
}
};
} // namespace chemical_formula
 
 
-------------------------------------- main.cpp
#include "chemical_formula-Tokenizer.hpp"
#include <cppx-core/all.hpp>
 
auto main() -> int
{
$use_std( cout, endl );
 
const auto& formula = "[Be(N(CH3)24)255555555555555555555]3";
 
cout << "Tokens:" << endl;
for( auto tokens = chemical_formula::Tokenizer( formula );
not tokens.is_at_end();
tokens.advance() )
{
const chemical_formula::Token tok = tokens.current();
cout << "* ";
if( tok.kind == chemical_formula::Token::Kind::none ) {
cout << "<invalid> ";
}
cout << "\"" << tok.text << "\"" << endl;
}
}
 
 
Output:
 
Tokens:
* "["
* "Be"
* "("
* "N"
* "("
* "C"
* "H"
* "3"
* ")"
* "24"
* ")"
* <invalid> "255555555555555555555"
* "]"
* "3"
 
 
Cheers & hth.,
 
- Alf
alexo <alelvb@inwind.it>: Jun 29 06:21AM +0200

Il 29/06/19 05:18, alexo ha scritto:
>> clear spec.
 
> The numerical coefficient theorically can be of any lenght, but usually
> are not greater than, say, 15.
 
For a single central atom the coordination number can be higher than 7,
but the coefficient can be very high in organic chemistry formulas,
where there is not a limit to the number of carbon atoms that can be
chained together. They are usually reported grouping methyl or methylene
groups as this:
 
CH3(CH2)10CH(CH3)(CH2)3CH3
 
5-methyl-hexadecane.
 
For the parentheses, formulas usually involve a pair of square brackets
inside of which there are round parentheses.
 
The example I reported earlier, namely, [Be(N(CH3)2)2]3 even if simple,
fails to be recognized by my parser.
 
2(3HC)-N-N-(CH3)2 being the 1,1,2,2 tetramethyl-hydrazine group
alexo <alelvb@inwind.it>: Jun 29 06:31AM +0200

Il 29/06/19 06:08, Alf P. Steinbach ha scritto:
>>>>> On 28.06.2019 19:14, alexo wrote:
 
> OK. The following is a manual approach to lexing such formulas. I've
> assumed that they can contain whitespace.
 
No Alf, chemical formulas don't have spaces inside them. They are a list
of the atoms, or group of atoms the molecule contains.
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Jun 28 09:49PM -0700

On 6/28/2019 9:08 PM, Alf P. Steinbach wrote:
>         string_view     name;
>     };
 
>     constexpr Element elements[]    =
[...]
>         { 116, "Lv", "Livermorium" },
>         { 117, "Ts", "Tennessine" },
>         { 118, "Og", "Oganesson" }
[...]
 
Where 115 = ununpentium or Lazarium? lol. ;^)
 
Just having some fun.
Bonita Montero <Bonita.Montero@gmail.com>: Jun 29 08:40AM +0200

>> -versions with internal buffers which are thread-local?
 
> Because it makes much more sense for the caller to provide the
> storage for the metadata, as POSIX realized two decades ago:
 
I think storing the saveptr yourself is less convenient than a
strtok() with internal thread-local buffers. And even more this
solution with be fully backward-compatible.
Manfred <noname@invalid.add>: Jun 29 04:47PM +0200

On 6/28/19 11:57 PM, Keith Thompson wrote:
 
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
 
> Annex K is normative but optional. An implementation that supports it
> must pre#define __STDC_WANT_EXT1__.
 
Just an extra bit of practical info: glibc, as diffuse as it is, does
_not_ support annex K, on purpose.
 
[...]
Bonita Montero <Bonita.Montero@gmail.com>: Jun 29 04:51PM +0200

> * Microsoft submitted their silly *_s bounds checking functions for
> standardization in C.
 
They aren't silly! If you don't use C++-strings but stick with C
char-arrays the make sense.
Manfred <noname@add.invalid>: Jun 29 06:59PM +0200

On 6/29/2019 4:51 PM, Bonita Montero wrote:
>> standardization in C.
 
> They aren't silly! If you don't use C++-strings but stick with C
> char-arrays the make sense.
 
Except that they are poorly designed, i.e., in human language, silly.
 
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1969.htm
ram@zedat.fu-berlin.de (Stefan Ram): Jun 29 12:09PM

»"Goodbye, " << "Planet!"«
 
n4800, 28.10.3.4 Member functions [syncstream.osyncstream.members]
 
(It might sound cynical, but when people are driving
90 miles an hour down a dead-end road what else is left?)
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 29 01:39AM +0200

On 29.06.2019 01:16, Mr Flibble wrote:
> egregious will it take for you to stop posting fucking egregious code?
 
> Please when posting snippets that are answers to questions:
> 1) DO NOT use your personal non-standard fucktarded library
 
There's nothing non-standard about the library, other than purely
formally some macro names that you can trivially transform to formally
conforming.
 
You have been so informed numerous times.
 
You keep forgetting.
 
 
> that flings
> dollar sign shit all over the walls of the room;
 
Reiterating what you've been told several times before:
 
You can trivially replace each macro name's dollar sign with prefix
`CPPX_`, and just uppercase the rest, to avoid the /emotional/ affront
to you.
 
You can even do that in your head, no editing effort involved, since
examples posted in clc++ are seldom posted for their output but for
understanding things.
 
When you don't that means you're lazy, or trolling, or both.
 
 
> it;
> 3) DO NOT write auto main() ... (see (2)) as it makes you look like a
> trolling cunt fuckwomble who just wants to irritate everyone.
 
Well, the swearing and strong reaction to modern C++ syntax says it all.
 
 
Cheers & hth.,
 
- Alf
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)