Thursday, April 25, 2019

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

"Öö Tiib" <ootiib@hot.ee>: Apr 25 12:07AM -0700

On Wednesday, 24 April 2019 19:31:51 UTC+3, Manfred wrote:
> Such usage of references to show use-after-free denotes lack of
> knowledge of what C++ references are meant for, and possibly confusion
> with practice of GC languages like C# and Java.
 
Most examples in article are novice errors. Exactly, one who does
not understand pointers and references and/or does not know what
responsibilities are left upon programmers in C++ may do something
like that. If static analyze does not reject it then an address sanitizer
will crash the tests. Other team members can explain to neophyte
what is wrong there, why and how it must be done instead. But with
perfectly pointless things (on so many levels) like
"std::optional<std::unique_ptr<int>>" I have no idea from where
to start. It just must be sarcasm, joke, sabotage, mental illness ... ?
What to do there? :(
Marcel Mueller <news.5.maazl@spamgourmet.org>: Apr 19 08:40PM +0200

Am 19.04.19 um 16:40 schrieb Bonita Montero:
> I often asked myself if there is something like basic_string, but with a
> template-parameter for the size of an an internal buffer which holds the
> string instead of allocating the content on the heap.
 
std::array<char,N>?
 
> could include allocating storage for strings which exceed the internal
> capaciy (otherwise the string could throw an exception if it will be
> grown beyond the limit)
 
Some string implementations have handling for fast in place storage for
short strings.
 
> When correctly used, f.e. for strings which are temporary and could
> reside on the stack anyway, this type of strings with an internal buffer
> could increase the performance of string-handling significantly.
 
Have a look at the short string optimization.
 
> On the
> other side, there are many standard-library facilities that only accept
> a basic_string so this type of string would be incompatible.
 
Exactly. And converting strings over and over (with allocations) can be
much more impact than the optimization gain.
 
As long as there is no need to pass /mutable/ strings to library
functions the use of const char* is the least common denominator. It is
quite easy to provide zero copy conversion operators to this type for
any string implementation.
 
 
Marcel
Bonita Montero <Bonita.Montero@gmail.com>: Apr 19 04:40PM +0200

I often asked myself if there is something like basic_string, but with a
template-parameter for the size of an an internal buffer which holds the
string instead of allocating the content on the heap. Optionally this
could include allocating storage for strings which exceed the internal
capaciy (otherwise the string could throw an exception if it will be
grown beyond the limit)
Such a class could have a number of non-member operator-overloads for
adding strings and whatever (thereby yieding a usual basic_string of
course). And a number of member-operators like += which operate on the
internal buffer.
When correctly used, f.e. for strings which are temporary and could
reside on the stack anyway, this type of strings with an internal buffer
could increase the performance of string-handling significantly. On the
other side, there are many standard-library facilities that only accept
a basic_string so this type of string would be incompatible.
Bonita Montero <Bonita.Montero@gmail.com>: Apr 20 11:02AM +0200

> Reserving unnecessarily large storage for every string (for fixed
> sized strings) can have a large impact as well. ...
 
Yes, but there are other cases like temporary strings on the stack where
my solution could be suitable. Or with strings that usually have a cer-
tain size. Or with strings where performance is more important than the
waste of space.
 
> You just mentioned that library functions will not be compatible to
> whatever other string implementation you use. This is an issue.
 
In this case you won't use my idea.
 
> += always requires some copying unless have a rope implementation with
> immutable fragments.
 
+= won't have any copying if the capacity of the left string would be
sufficient.
 
> You are right, std::string is not the optimum for every purpose. But
> from my point of view it does not mainly lack from an optimized allocator.
 
You can't build an allocator with internal storage to replace my idea.
I tried this and found that some runtime-libraries additionally allocate
storage for debugging-purposes. So allocator can't say which of the
allocations is for the characters of the string.
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 20 08:32PM


> Even if you end up allocating as much stack space through this kind of
> "stacticized" strings like in C this wouldn't blow up the stack to its
> maximum size.
 
Arrays on stack is always bad idea.
 
 
--
press any key to continue or any other to quit...
 
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
Marcel Mueller <news.5.maazl@spamgourmet.org>: Apr 20 11:19AM +0200

Am 20.04.19 um 11:02 schrieb Bonita Montero:
>> You just mentioned that library functions will not be compatible to
>> whatever other string implementation you use. This is an issue.
 
> In this case you won't use my idea.
 
Your idea is not compatible with std::string or did I miss something?
 
 
>> immutable fragments.
 
> += won't have any copying if the capacity of the left string would be
> sufficient.
 
If you compose a string with += /every/ content is copied at least once. ;-)
 
 
 
> I tried this and found that some runtime-libraries additionally allocate
> storage for debugging-purposes. So allocator can't say which of the
> allocations is for the characters of the string.
 
That's true. But where is the problem? If you provide a fixed size
storage it is sufficient for /some/ strings. Additional information
slightly decrease the maximum string size the storage can hold. no more
no less.
 
By the way, I never had any platform that allocated additional storage
for debugging purposes /before/ the call to operator new. Of course,
operator new does this behind the scenes.
Are you sure that the additional storage did not come from a vtable or
something like that? You should use POD types for this purpose.
 
 
Marcel
Bonita Montero <Bonita.Montero@gmail.com>: Apr 21 09:20AM +0200


>> You won't store this and everything in the size-magnitude of this on the
>> stack.
 
> And why not? The only problem is the technical limitation.
 
When you do an allocation with alloca() you do it because of the
performance. But for larger allocations the performance-difference
on the heap is negligible.
 
> Even if there is not much data on stack the issue still remains. Let's
> say I have 4 bytes local data per stack frame, and the stack is 1MB.
> This means I am limited to ca 250,000 recursions.
 
... very realistic.
 
> At the same time my machine has 16 GB of memory, meaning in principle
> I could have ca 4,000,000,000 recursions instead. Why am I limited to
> 0.006 % of the machine capabilities?
 
Because no one will do a recursion with 4e9 levels, even not with 2,5E4
levels.
Bonita Montero <Bonita.Montero@gmail.com>: Apr 20 09:16PM +0200

>> aren't allocated on construction but subtracted from the pagefile for
>> to guarantee that the stack could theoretically grow to its maximum.
 
> And that's large?
 
Yes, 1MB stack-size is very large. That would be consumend
to a significant extent only when havin massive alloca()s.
gazelle@shell.xmission.com (Kenny McCormack): Apr 22 03:13PM

In article <q9klf7$gah$1@news.albasani.net>,
> f123( i ); // shoudn't work
>}
 
>Why dows the compiler not find at least the "valid" unsigned f123?
 
Your program has undefined behavior, so anything is possible.
 
And, anything is right.
 
And, so on...
 
--
Religion is what keeps the poor from murdering the rich.
 
- Napoleon Bonaparte -
Ian Collins <ian-news@hotmail.com>: Apr 22 10:05PM +1200

>> by "constexpr". Even with optimisation disabled, a C++14 compiler must
>> calculate the CRC check here at compile time.
 
> Or not even in 2017 mode....
 
It is if you fix the spello:
 
constexpr uint8_t s[] = "Hello, world!";
 
gcc is a bit lenient on the original.
 
--
Ian.
Bonita Montero <Bonita.Montero@gmail.com>: Apr 19 07:32PM +0200

> The problem is that other namespaces may have defined 'string' as well.
 
Yes, and main() of course also! I'll bet my right hand on that.
Bart <bc@freeuk.com>: Apr 19 07:09PM +0100

On 19/04/2019 18:27, Ike Naar wrote:
 
> The problem is that other namespaces may have defined 'string' as well.
> So if you see unadorned 'string' it's not clear whether std::string,
> foo::string or bar::string was intended.
 
Why are those other modules also defining 'string'? Which is known to be
a built-in type.
 
If they are alternatives to std::string, then wouldn't it make it an
easier plug-in replacement if you don't have to go around changing all
those "std::" to "foo::"?
 
Besides I thought the IDEs that everyone uses could tell which library
any unadorned "string" belonged to.
 
(I've developed some languages with namespaces. But I hardly ever used
such a qualifier.
 
In a first version, there was a natural search order so that if 'string'
was seen, it would look first in std, next in foo (or equivalents). A
qualifier was needed to specify which one.
 
In the next version, a qualifier, ie. a module prefix, would only be
needed if 'string' was ambiguous, ie. more than one exported 'string'
was visible from that place in the code.)
Ike Naar <ike@faeroes.freeshell.org>: Apr 19 05:27PM

> than he is probably a very inexperienced C++ programmer. For most C++
> programmers, std:: adds nothing as a prefix to string in terms of
> readability.
 
The problem is that other namespaces may have defined 'string' as well.
So if you see unadorned 'string' it's not clear whether std::string,
foo::string or bar::string was intended.
Bonita Montero <Bonita.Montero@gmail.com>: Apr 21 04:19PM +0200

> I have always been of the opinion that the readability and
> undrestandability of code shouldn't be reliant on an IDE.
 
I don't see any reason for that.
Chris Sykes <chris@amtiskaw.net>: Apr 22 10:32AM +0100

On 21/04/2019 14:09, Bart wrote:
> the #include, it doesn't work (doesn't know 'std'); if I keep that
> but get rid of std::, it doesn't work either (doesn't know 'cout').
> And this is the simplest possible program.
 
Well in C++ you can always add:
 
using std::cout, std::string; // comma separated list allowed since c++17
 
To pull in precisely what you want to use from the standard library, or:
 
using std;
 
To dump everything into the local scope.
 
The biggest advantage (IMO) of C++ namespaces is that they provide a
mechanism to resolve otherwise ambiguous names; that is, even when
`using std;`, you can fully qualify references to string, cout
or whatever to resolve any ambiguity with symbols defined elsewhere.
 
Many other languages do something similar; the compiler (or interpreter)
raises an error (hopefully identifying where the conflicting symbols
are declared), and you fix it by qualifying the references with the
appropriate namespace, package, module/whatever prefix.
Ian Collins <ian-news@hotmail.com>: Apr 19 08:18AM +1200

On 19/04/2019 07:51, Rick C. Hodgin wrote:
 
> Is there an existing way in C/C++ to automatically create some value
> that would allow me to add a new test and have it inject the new
> value?
 
An enum.
 
--
Ian.
Richard Damon <Richard@Damon-Family.org>: Apr 19 12:37PM -0400

On 4/19/19 9:25 AM, Rick C. Hodgin wrote:
>> entry. This says that calling code has names for the various error
>> codes, rather than having to be littered with all the magic numbers.
 
> I am unaware of the rule of magic numbers.
 
The basic rule is that a 'magic number' should appear at most once in
any program, generally to assign it to some named constant of some sort
to be used elsewhere.
 
Basically, if you have code that does something like:
 
if(error == -2) ...
 
You have a magic number there and you need to dig into the documentation
to have any idea what that number means (there is nothing inherent in
the value -2 that tells you what the error would be).
 
A second problem with magic numbers is that if you need to change what
the value is of that magic number at its source (perhaps you started
with two distinct sets of error codes with overlapping values, and now
you need them to be distinct), you now need to go through you whole
source code and change the value, and determine if that use of the value
was this magic value, or some other magic value, or maybe something that
just happened to have that value mathematically.
 
If every use of that magic number used a symbolic name, than changing it
is easy, you just need to change the value assigned to that symbolic name.
Bart <bc@freeuk.com>: Apr 18 09:25PM +0100

On 18/04/2019 20:51, Rick C. Hodgin wrote:
> meaning once you put in the token/whatever to identify you need a
> locally scoped automatically incrementing or decrementing value, that
> it bakes it into source code during the compile.
 
Not really sure what you're getting at. But this function:
 
int test(int n) {
 
switch (n) {
enum {base=__LINE__};
 
case 1:
return base-__LINE__;
case 2:
return base-__LINE__;
case 3:
return base-__LINE__;
}
return 0;
}
 
 
Returns -3, -5, -7 when called with n = 1,2,3.
 
A new case would return a different error (ie. negative value), with no
enums to maintain (assuming it's on a different line). Alternatively
just return -__LINENO__ for an absolute line number to pinpoint where it
went wrong in the function.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 18 09:37PM +0100

> I don't particularly care what the values are, but they just need to be
> distinct and unique so that if they are returned later I can identify
> the exact cause of the error, where it failed.
<cut>
> return #autodec; // Indicate it failed at this test
 
> // If we get here, we're good
> }
 
This ties the correctness of every calling function into the order in
which these tests are written. I think it should be added to your
language ASAP.
 
<cut>
--
Ben.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 18 04:42PM -0400

On 4/18/2019 4:07 PM, Scott Lurndal wrote:
 
> There are two sides to every function call - how do the callers of that
> function know, a priori, which return code matches which (pre)condition
> failure;
 
The functions pretty much always return 0 or a positive value if
there were no errors.
 
It's contextual. how_long_is_this_text() will return a negative
value if you don't pass in a valid parameter, or 0 or a larger
value if there is content there, etc.
 
> particularly when subsequently code gets inserted into the existing set
> such that successive autogenerated return codes are shifted by one?
 
I don't have any autogenerated code in most projects. Some, but not many.
 
> Just use a #define, static const uint32_t or enum and update them as needed.
 
I write enough new code that it's becoming tedious to keep track of
all the unique values.
 
I will probably write an external tool and add a pre-build processing
step during compilation.
 
--
Rick C. Hodgin
Joe Pfeiffer <pfeiffer@cs.nmsu.edu>: Apr 19 05:16PM -0600


> I can see doing this in an external tool, but is there some way to do
> it in C/C++?
 
> And if not, does anyone have any idea for a good syntax on how to do it?
 
This really doesn't seem like a good idea to me. Not only are you using
"magic numbers", you're using magic numbers you haven't defined
yourself, and whose value will change if additional if's get added at
some later time.
 
I'd much rather use an enum and typedef
typedef enum {SUCCESS, OOPS, FATAL_ERR, ...} ReturnCode;
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 19 09:05PM +0100

On 19/04/2019 14:26, Rick C. Hodgin wrote:
> design by a couple millennials will make it more appealing:
 
> A Modern Attractive Bible
> https://www.foxnews.com/faith-values/bible-millennial-instagram-generation
 
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."
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 19 08:02AM +0200

<url:
https://alf-p-steinbach.github.io/cppx-core-DOxygen-generated-documentation/d3/d7c/macro-use_8hpp.html#a4b12dc76791ce4947182d07bd9b0ea20>
 
I wonder if there's some way to /portably/ automate copying of e.g.
image files referenced by markdown files, to the relevant place in the
Doxygen output folder?
 
For now I chose to just not add those image files manually.
 
Maybe there is some better way of using Doxygen for a GitHub project? I
just generate to a folder that I've set GIT to "ignore", and use that
folder as GitHub project on its own, presented as GitHub pages.
 
I've not yet experimented with GitHub sub-projects, could that be useful
for docs?
 
 
Cheers!,
 
- Alf
bitrex <user@example.net>: Apr 20 12:50PM -0400

Is there a cleaner way to do this, where I have a Base class
with protected or private generic pure virtual function templated on
"Param", I have an interface class with a public interface to it, and
I have any number of variadic template implementation classes (Bar, in
this case) where I can declare multiple overrides for the pure virtual
function.
 
I have used the CRTP to "inject" the interface/forwarding template
expansion function in class "Base" here. but I'd prefer the virtual
function and overrides in Bar to be private but can't figure out how to
do that.
 
#include <utility>
 
template <typename Param>
class BaseSingle {
protected:
virtual void BaseFoo(Param) = 0;
};
 
template <typename Derived, typename... Params>
class Base : public BaseSingle<Params>... {
public:
template <typename T>
void Foo(T&& x) {

static_cast<Derived*>(this)->BaseSingle<T>::BaseFoo(std::forward<T>(x));
}
};
 
template <typename... Params>
class Bar : public Base<Bar<Params...>, Params...> {
protected:
void BaseFoo(int x) override {}
void BaseFoo(char x) override {}
};
 
int main() {
Bar<int, char> bar;
bar.Foo('a');
bar.Foo(42);
}
 
On Compiler Explorer for the MSP430 this compiles to (-std=c++11 -Os
-fno-rtti -fno-threadsafe-statics):
 
Bar<int, char>::BaseFoo(int):
PUSHM.W #1, R4
MOV.W R1, R4
POPM.W #1, r4
RET
Bar<int, char>::BaseFoo(char):
PUSHM.W #1, R4
MOV.W R1, R4
POPM.W #1, r4
RET
non-virtual thunk to Bar<int, char>::BaseFoo(char):
PUSHM.W #1, R4
MOV.W R1, R4
POPM.W #1, r4
RET
main:
PUSHM.W #1, R4
MOV.W R1, R4
SUB.W #4, R1
MOV.W #vtable for Bar<int, char>+4, -4(R4)
MOV.W #vtable for Bar<int, char>+12, -2(R4)
MOV.B #97, R13
MOV.W R4, R12
ADD.W #-2, R12
CALL #_ZN10BaseSingleIcE7BaseFooEc
MOV.B #6, R13
MOV.W R4, R12
ADD.W #-4, R12
CALL #_ZN10BaseSingleIiE7BaseFooEi
MOV.B #0, R12
ADD.W #4, R1
POPM.W #1, r4
RET
vtable for Bar<int, char>:
.short 0
.short 0
.short Bar<int, char>::BaseFoo(int)
.short Bar<int, char>::BaseFoo(char)
.short -2
.short 0
.short non-virtual thunk to Bar<int, char>::BaseFoo(char)
vhegde@cs.stonybrook.edu: Apr 24 05:33PM -0700

|-DeclStmt 0x5564560 <line:33:6, col:24>
| `-VarDecl 0x55644e0 <col:6, col:22> col:17 used dest 'int' static cinit
| `-IntegerLiteral 0x5564540 <col:22> 'int' 10
 
 
| |-ImplicitCastExpr 0x5564718 <col:15, col:16> 'void *' <BitCast>
| | `-UnaryOperator 0x55645c8 <col:15, col:16> 'int *' prefix '&' cannot overflow
| | `-DeclRefExpr 0x55645a0 <col:16> 'int' lvalue Var 0x55644e0 'dest' 'int'
 
In the above AST, what do hex values 0x55644e0 represent? Addresses of the variable? If so is there is anyway to extract it while parsing the AST?
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)