Saturday, November 9, 2019

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

Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Nov 09 03:10PM

On Thu, 7 Nov 2019 14:47:55 -0800
> This damn error still persists. MSVC needs to fix it. Have not checked
> the 2019 version yet. It has to do with reporting the size of an
> allocated array using overloaded new and delete. Here is the code:
 
Microsoft have said they are not going to the fix the two argument
version of operator delete[]. They recognize their compiler is not
standard compliant, but to fix it would break code (including their
own).
 
The best thing with windows is not to customize operator new[]/delete[],
or if you do to allocate a block of memory four bytes larger than the
request, store the size of the array as the first four bytes of the
allocation and use that to obtain the size of the memory block
for operator delete[] (which also means operator new[] returning memory
offset by four bytes, which may have alignment consequences - make it
larger if need be).
Manfred <noname@invalid.add>: Nov 09 07:19PM +0100

On 11/9/19 4:10 PM, Chris Vine wrote:
> for operator delete[] (which also means operator new[] returning memory
> offset by four bytes, which may have alignment consequences - make it
> larger if need be).
 
Could you give any reference?
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Nov 09 10:29PM

On Sat, 9 Nov 2019 19:19:02 +0100
> > offset by four bytes, which may have alignment consequences - make it
> > larger if need be).
 
> Could you give any reference?
 
Ten or so years ago I could have. There was a visual studio problem
report in which that answer was given. At that time the problem was
fairly widely discussed.
 
If you use visual studio and want to be told again (or can't find the
earlier PR, I now can't but I can't say I have looked that hard) then
make another problem report and be told again. It is straightforward
to come up with a code example to illustrate the defect.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 09 05:52AM -0800

> language or the invisible unicorn in my garage must behave, in the
> case someone happens to incorporate them into their C++
> implementation.
 
These analogies are pretty much meaningless, because the terms
are not in the universe of discourse for the C++ language. The
term "reference" is in the C++ universe of discourse, and every
C++ programmer understands what "null reference" means, in that
context, by analogy with "null pointer". In fact the term "null
reference" appears in the C++ standard, as you point out.
 
> well-defined program, because the only way to create such a reference
> would be to bind it to the ?object? obtained by indirection through a
> null pointer, which causes undefined behavior. ]"
 
Saying "a null reference cannot exist in a well-defined program"
is a circular statement; it has no information content, because
of what is meant by well-defined. Also, just because a construct
has undefined behavior doesn't mean the result can't exist.
Obviously it can exist, because the implementation is free to
define the meaning.
 
> "behavior is undefined" and then go on and discuss in another place
> what happens if a program violates this "shall", thus defining the
> behavior.
 
There is no contradiction. What would (hypothetically) be being
defined is not declaring/initializing a null reference, but using
a null reference. Do you not understand the distinction?
 
 
(Sorry to be so long in responding, life has been unusually
chaotic of late.)
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 09 07:15PM +0100

On 18.09.2019 20:06, Paavo Helde wrote:
> well-defined program, because the only way to create such a reference
> would be to bind it to the "object" obtained by indirection through a
> null pointer, which causes undefined behavior. ]"
 
 
Well, dereferencing a nullpointer is explicitly supported in a
typeid-expression.
 
So for a short time there is a nullreference in a valid program.
 
Happily notes in ISO standards are non-normative, as I recall, but the
wording in the sentence before that note is arguably defective. ;-)
 
 
> reference shall be initialized to refer to a valid object" and "behavior
> is undefined" and then go on and discuss in another place what happens
> if a program violates this "shall", thus defining the behavior.
 
I think that holds even taking into account the typeid special case.
 
- Alf
Bonita Montero <Bonita.Montero@gmail.com>: Nov 09 05:28AM +0100

> memory_order. ...
> std::atomic<int> a = 123;
> std::atomic<int> b = a; // implied seq_cst!
 
That's what is specified.
Bonita Montero <Bonita.Montero@gmail.com>: Nov 09 05:31AM +0100

>> if there's a ::resize() before or not.
 
> I'm stupid? If you use std::vector::reserve() you can then use
> std::vector::emplace_back without reallocations being made, you fucktard.
 
Yes you're stupid. There might never be a call to the move- or copy
-constructor at runtime, but the call is generated for that inside the
::resize-method at compile-time!
Daniel <danielaparker@gmail.com>: Nov 09 03:06AM -0800

On Friday, November 8, 2019 at 10:49:42 AM UTC-5, Mr Flibble wrote:
 
> I'm stupid? ... you fucktard.
 
It's too bad that name calling doesn't work on the internet. It's legacy is honourable conflict among civilized children in school yards, but on the internet, the words are the same, but the sense of menace is not the same.
 
Best regards,
Daniel
Bonita Montero <Bonita.Montero@gmail.com>: Nov 09 01:45PM +0100

SO for the first time I'm able to differentiate between integrals
and the rest:
 
#include <atomic>
#include <type_traits>
 
template<typename T, bool isIntegral = std::is_integral<T>::value>
struct xatomic : public std::atomic<T>
{
xatomic() = default;
xatomic( xatomic const &xa );
 
using std::atomic<T>::operator =;
using std::atomic<T>::is_lock_free;
using std::atomic<T>::store;
using std::atomic<T>::load;
using std::atomic<T>::operator T;
using std::atomic<T>::exchange;
using std::atomic<T>::compare_exchange_weak;
using std::atomic<T>::compare_exchange_strong;
using std::atomic<T>::fetch_add;
using std::atomic<T>::fetch_sub;
using std::atomic<T>::operator ++;
using std::atomic<T>::operator --;
using std::atomic<T>::operator +=;
using std::atomic<T>::operator -=;
using std::atomic<T>::fetch_and;
using std::atomic<T>::fetch_or;
using std::atomic<T>::fetch_xor;
using std::atomic<T>::operator &=;
using std::atomic<T>::operator |=;
using std::atomic<T>::operator ^=;
};
 
template<typename T, bool IsIntegral>
inline
xatomic<T, IsIntegral>::xatomic( xatomic const &xa )
{
*this = (T)xa;
}
 
template<typename T>
struct xatomic<T, false> : public std::atomic<T>
{
xatomic() = default;
xatomic( xatomic const &xa );
 
using std::atomic<T>::operator =;
using std::atomic<T>::is_lock_free;
using std::atomic<T>::store;
using std::atomic<T>::load;
using std::atomic<T>::operator T;
using std::atomic<T>::exchange;
using std::atomic<T>::compare_exchange_weak;
using std::atomic<T>::compare_exchange_strong;
};
 
struct S
{
};
 
xatomic<S> xas;
xatomic<int> xai;
Bonita Montero <Bonita.Montero@gmail.com>: Nov 09 04:38PM +0100

Wow, finally I've got it:
 
#include <atomic>
#include <type_traits>
 
template<typename T, bool isIntegral = std::is_integral<T>::value, bool
isNotPointer = !std::is_pointer<T>::value>
struct xatomic : public std::atomic<T>
{
xatomic() = default;
xatomic( xatomic const &xa );
 
using std::atomic<T>::operator =;
using std::atomic<T>::is_lock_free;
using std::atomic<T>::store;
using std::atomic<T>::load;
using std::atomic<T>::operator T;
using std::atomic<T>::exchange;
using std::atomic<T>::compare_exchange_weak;
using std::atomic<T>::compare_exchange_strong;
using std::atomic<T>::fetch_add;
using std::atomic<T>::fetch_sub;
using std::atomic<T>::operator ++;
using std::atomic<T>::operator --;
using std::atomic<T>::operator +=;
using std::atomic<T>::operator -=;
using std::atomic<T>::fetch_and;
using std::atomic<T>::fetch_or;
using std::atomic<T>::fetch_xor;
using std::atomic<T>::operator &=;
using std::atomic<T>::operator |=;
using std::atomic<T>::operator ^=;
};
 
template<typename T, bool isIntegral, bool isNotPointer>
inline
xatomic<T, isIntegral, isNotPointer>::xatomic( xatomic const &xa )
{
*this = (T)xa;
}
 
template<typename T>
struct xatomic<T, false, true> : public std::atomic<T>
{
xatomic() = default;
xatomic( xatomic const &xa );
 
using std::atomic<T>::operator =;
using std::atomic<T>::is_lock_free;
using std::atomic<T>::store;
using std::atomic<T>::load;
using std::atomic<T>::operator T;
using std::atomic<T>::exchange;
using std::atomic<T>::compare_exchange_weak;
using std::atomic<T>::compare_exchange_strong;
};
 
template<typename T>
inline
xatomic<T, false, true>::xatomic( xatomic const &xa )
{
*this = (T)xa;
}
 
template<typename T>
struct xatomic<T *, false, false> : public std::atomic<T>
{
xatomic() = default;
xatomic( xatomic const &xa );
 
using std::atomic<T>::operator =;
using std::atomic<T>::is_lock_free;
using std::atomic<T>::store;
using std::atomic<T>::load;
using std::atomic<T>::operator T;
using std::atomic<T>::exchange;
using std::atomic<T>::compare_exchange_weak;
using std::atomic<T>::compare_exchange_strong;
using std::atomic<T>::operator ++;
using std::atomic<T>::operator --;
using std::atomic<T>::operator +=;
using std::atomic<T>::operator -=;
};
 
template<typename T>
inline
xatomic<T *, false, false>::xatomic( xatomic const &xa )
{
*this = (T)xa;
}
struct S
{
};
 
xatomic<S> xas;
xatomic<int> xai;
xatomic<int *> xap;
 
Don't know why I had to invert is_pointer<T>::value to isNotPointer.
melzzzzz <melzzzzz@zzzzz.com>: Nov 09 06:18PM +0100

Bonita Montero :
"Don't know why I had to invert is_pointer<T>::value to isNotPointer."
 
your idea is stupid...
Bonita Montero <Bonita.Montero@gmail.com>: Nov 09 06:57PM +0100

> Bonita Montero :
> "Don't know why I had to invert is_pointer<T>::value to isNotPointer."
> your idea is stupid...
 
Then show me a better one.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 09 05:55AM -0800


> But please use `constexpr` or `const` declarations, not macros.
 
> Using macros conveys the idea that macros are a reasonable solution to
> the problem of naming a compile time constant.
 
Why do C++ fans hate the C preprocessor so much?
Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 09 06:13AM -0800

> overflow is a programming error: even if this is true I think that
> unsigned overflow should have defined behavior (and wrap) rather
> than being handled as an error by the compiler.
 
I absolutely concur. Your other comments in the thread also are
right on the money. Frankly I am rather baffled by the comments
of those on the other side of what you've been saying.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 09 06:24AM -0800


> IMO, wrapping integers (signed or unsigned) are an example of
> "optimization which nobody asked for", and they are there basically
> only because the hardware happened to support such operations.
 
Apparently you think how the hardware behaves (specifically, for
unsigned or two's complement operands) is some sort of accident
of history. It isn't. It was a deliberate choice, made by smart
people. It isn't just a coincidence that the semantics of
wrapping works nicely in a variety of applications.
Siri Cruise <chine.bleu@yahoo.com>: Nov 09 06:33AM -0700

In article <86tv7dcfxr.fsf@linuxsc.com>,
 
> > Using macros conveys the idea that macros are a reasonable solution to
> > the problem of naming a compile time constant.
 
> Why do C++ fans hate the C preprocessor so much?
 
Because C++ is dedicated to new, obscure, ambiguous syntax everytime anyone has
a hangnail.
 
Do you to ensure a variable is defined before first use? Well, you could
dedicate years of effort to synchronise loaders and compilers with new object
file tables, or
 
#define variable (*variable_())
type_t* variable_ () {
static lock_t lock = unlocked;
static bool defined = false;
static type_t v;
if (!defined) {
if (!try_lock(lock)) error("circular initialisation");
if (!defined) {
defined = true;
v = (initialisation());
}
unlock(lock);
}
return &v;
}
 
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
The first law of discordiamism: The more energy This post / \
to make order is nore energy made into entropy. insults Islam. Mohammed
"Öö Tiib" <ootiib@hot.ee>: Nov 09 06:46AM -0800

On Saturday, 9 November 2019 15:55:38 UTC+2, Tim Rentsch wrote:
 
> > Using macros conveys the idea that macros are a reasonable solution to
> > the problem of naming a compile time constant.
 
> Why do C++ fans hate the C preprocessor so much?
 
It is not hate. We prefer to use macros when what these do can not
be done as simply by using inline functions, templates or constants.
 
Reasons are that macros are names that ignore scope and work on
textual substitutions. Macros are harder to debug and cause
unanticipated effects and confusion in clumsy hands. However for
teams that manage to hire members with godly hands macros are
fine. :D
Siri Cruise <chine.bleu@yahoo.com>: Nov 09 07:14AM -0700

In article <86lfspcekw.fsf@linuxsc.com>,
> of history. It isn't. It was a deliberate choice, made by smart
> people. It isn't just a coincidence that the semantics of
> wrapping works nicely in a variety of applications.
 
CPUs with an overflow flag note additions that overflow the register. A compiler
can implement integer overflow exceptions on such CPUs.
 
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
The first law of discordiamism: The more energy This post / \
to make order is nore energy made into entropy. insults Islam. Mohammed
"Öö Tiib" <ootiib@hot.ee>: Nov 09 07:46AM -0800

On Saturday, 9 November 2019 16:34:28 UTC+2, Siri Cruise wrote:
> }
> return &v;
> }
 
Since C++11 such singletons can be written like:
 
type_t* variable_ () {
static type_t v = (initialisation());
return &v;
}
It possibly results with deadlock when (initialisation())
contains recursive calls to variable_() but that does
not make sense so possibly has to be fixed by programming
anyway.
Bonita Montero <Bonita.Montero@gmail.com>: Nov 09 05:03PM +0100

>> Using macros conveys the idea that macros are a reasonable solution to
>> the problem of naming a compile time constant.
 
> Why do C++ fans hate the C preprocessor so much?
 
Because most of the times you use macros you can use inline-functions,
templated or not, as well; and the advantage over macros is, that they
can be debugged. And substituting larger templated functions via macros
is a mess.
Soviet_Mario <SovietMario@CCCP.MIR>: Nov 09 12:42AM +0100

On 08/11/2019 18:58, Keith Thompson wrote:
 
>> You must search setup.h, not SETUP.H
 
> It depends. If the OP is on Windows, setup.h and SETUP.H are the
> same file.
 
I am on linux, but extensive system-wide search did not
discover any such file alas :(
 
 
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)
Soviet_Mario <SovietMario@CCCP.MIR>: Nov 09 12:44AM +0100

On 08/11/2019 19:09, Miguel Giménez wrote:
> The setup.h is copied during wxWidgets compilation, but the
> original for your system should be still at
> /usr/include/wx-3.0/include/wx/gtk
 
maybe the problem arose as I installed everything from repo
package and did not compile anything manually ... dunno :(
 
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)
Paavo Helde <myfirstname@osa.pri.ee>: Nov 09 09:21AM +0200

On 9.11.2019 1:44, Soviet_Mario wrote:
>> for your system should be still at /usr/include/wx-3.0/include/wx/gtk
 
> maybe the problem arose as I installed everything from repo package and
> did not compile anything manually ... dunno :(
 
Then you probably failed to install the needed *-dev or *-devel packages.
Soviet_Mario <SovietMario@CCCP.MIR>: Nov 09 11:33AM +0100

On 09/11/2019 08:21, Paavo Helde wrote:
>> did not compile anything manually ... dunno :(
 
> Then you probably failed to install the needed *-dev or
> *-devel packages.
 
mmm, I'll look for missing dev packages
I normally don't install them as a general rule of thumb, in
the particular case I can't remember, but I'll try to add them !
Tnx
 
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)
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)