Monday, October 26, 2015

Digest for comp.lang.c++@googlegroups.com - 13 updates in 4 topics

Rosario19 <Ros@invalid.invalid>: Oct 26 07:37PM +0100

On Mon, 26 Oct 2015 18:03:21 +0100, Rosario19 <Ros@invalid.invalid>
wrote:
 
>f(V<i32>* a, V<i32> o, i32 m, i32 b)
>that goes in seg fault due to double free of address
>org.va (for me)
 
f is traslated as
 
;
; f(V<i32>* a, V<i32> o, i32 m, i32 b)
;
push ebp
mov ebp,esp
add esp,-36
push ebx
push esi
push edi
mov edi,dword ptr [ebp+28]
@1:
mov eax,offset @@_$ECTVFB$@f$qp5%V$i%5%V$i%ii
call @__InitExceptBlockLDTC
mov dword ptr [ebp-8],1
;
; {i32 k,r=0,i;
;
?live16385@16: ; EDI = m
mov word ptr [ebp-20],8
xor ebx,ebx
;
; FE(i,o){r+=o[i];
;
?live16385@32: ; EBX = r, EDI = m
xor esi,esi
jmp short @3
@2:
push esi
lea eax,dword ptr [ebp+12]
push eax
call @@%V$i%@$bsubs$qui
add esp,8
add ebx,dword ptr [eax]
;
; (*a)[i]=r=(r<m?m:(r>b?b:r));
;
?live16385@48: ; EBX = r, ESI = i, EDI = m
push esi
push dword ptr [ebp+8]
call @@%V$i%@$bsubs$qui
add esp,8
cmp edi,ebx
jle short @4
mov edx,edi
jmp short @5
@4:
cmp ebx,dword ptr [ebp+32]
jle short @6
mov edx,dword ptr [ebp+32]
jmp short @7
@6:
mov edx,ebx
@7:
@5:
mov ebx,edx
mov dword ptr [eax],edx
inc esi
@3:
cmp esi,dword ptr [ebp+16]
jb short @2
;
; }
; }
;
?live16385@64: ;
dec dword ptr [ebp-8]
push dword ptr [ebp+20]
call @_free
pop ecx
mov word ptr [ebp-20],8
mov eax,dword ptr [ebp-36]
mov dword ptr fs:[0],eax
@9:
pop edi
pop esi
pop ebx
mov esp,ebp
pop ebp
ret
@@f$qp5%V$i%5%V$i%ii endp
@f$qp5%V$i%5%V$i%ii ends
 
as you see how smarter they are to make inline so nobody understand
what happen...
it happen that correctly the destructor is called for argument o
in f() function
 
but
here:
; f(&res, org, 5, 10);
;
push 10
push 5
add esp,-16
mov word ptr [ebx+16],56
mov ecx,dword ptr [ebp-32]
mov dword ptr [esp],ecx
mov eax,dword ptr [ebp-28]
mov dword ptr [esp+4],eax
mov edx,dword ptr [ebp-24]
mov dword ptr [esp+8],edx
mov ecx,dword ptr [ebp-20]
mov dword ptr [esp+12],ecx
inc dword ptr [ebx+28]
lea eax,dword ptr [ebp-16]
push eax
mov word ptr [ebx+16],44
dec dword ptr [ebx+28]
call @@f$qp5%V$i%5%V$i%ii
add esp,28

it is inline a constructor i don't know who wrote...
and what does...
[i understand that because in all constructor i have i call malloc...]
David Brown <david.brown@hesbynett.no>: Oct 26 09:39PM +0100

On 26/10/15 19:13, Wouter van Ooijen wrote:
> Atmel AVR
> MSP430
> ...
 
These are becoming less common, as they are pushed out by ARM Cortex-M,
but are still common. It is quite possible to program in C++ on the AVR
(an 8-bit microcontroller) and the msp430 (a 16-bit microcontroller).
There are a range of other 8-bit and 16-bit microcontrollers still in
use, but those ones are the most common - and only the AVR and msp430
are likely to be used with C++ rather than plain C.
 
And of course there are a few systems with 64-bit integers, and plenty
with weirder sizes like 36 that may have roots back to 1979 but are
still in use today (though perhaps not with C++).
Vir Campestris <vir.campestris@invalid.invalid>: Oct 26 09:39PM

On 26/10/2015 16:42, Scott Lurndal wrote:
> In the vast majority of cases, yes. PDP-11 had a 16-bit
> int; but there haven't been many systems using 16-bit int
> since 1979.
 
IBM PC.
That should be enough systems for anyone.
 
IIRC the Windows int didn't become 32 bit until NT came out in <fx
googles> '93 and didn't become rare until the death of Windows 3.1, a
few years after '95 came out.
 
Andy
Paavo Helde <myfirstname@osa.pri.ee>: Oct 26 04:59PM -0500

Rosario19 <Ros@invalid.invalid> wrote in
> http://codegolf.stackexchange.com/questions/61684/calculate-the-bounded
> -cumulative-sum-of-a-vector ?
> my OS tel me they are 800 bytes...
 
No, I don't like it. Here is a straightforward C++ solution. Most
certainly this can be improved upon e.g. by replacing min/max with ?:,
but then it would not be in full C++ spirit any more.
 
#include <vector>
#include <algorithm>
void c(std::vector<int>&v,int l,int h)
{int s=0;for(int& i:v)i=s=std::min(h,std::max(l,s+i));}
 
 
Below is the demo/test program:
 
 
#include <iostream>
#include <iterator> // for ostream_iterator
int main() {
int upper_lim = 6;
int lower_lim = -2;
std::vector<int> vec = {1, 4, 3, -10, 3, 2, 2, 5, -4};
c(vec, lower_lim, upper_lim);
std::copy(vec.begin(), vec.end(), std::ostream_iterator<int>
(std::cout, " "));
std::cout << "\n";
// cum_vec = [1 5 6 -2 1 3 5 6 2]
 
upper_lim = 100;
lower_lim = -100;
vec = {1, 1, 1, 1, 1, 1};
c(vec, lower_lim, upper_lim);
std::copy(vec.begin(), vec.end(), std::ostream_iterator<int>
(std::cout, " "));
std::cout << "\n";
// cum_vec = [1 2 3 4 5 6]
 
upper_lim = 5;
lower_lim = 0;
vec = {10, -4, -3, 2};
c(vec, lower_lim, upper_lim);
std::copy(vec.begin(), vec.end(), std::ostream_iterator<int>
(std::cout, " "));
std::cout << "\n";
// cum_vec = [5 1 0 2]
 
upper_lim = 0;
lower_lim = 0;
vec = {3, 5, -2, 1};
c(vec, lower_lim, upper_lim);
std::copy(vec.begin(), vec.end(), std::ostream_iterator<int>
(std::cout, " "));
std::cout << "\n";
//cum_vec = [0 0 0 0]
 
upper_lim = 10;
lower_lim = 5;
vec = {1, 4, 6};
c(vec, lower_lim, upper_lim);
std::copy(vec.begin(), vec.end(), std::ostream_iterator<int>
(std::cout, " "));
std::cout << "\n";
// cum_vec = [5 9 10]
}
Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 26 10:59PM

On Mon, 2015-10-26, Vir Campestris wrote:
 
> IIRC the Windows int didn't become 32 bit until NT came out in
> <fx googles> '93 and didn't become rare until the death of Windows 3.1,
> a few years after '95 came out.
 
When I bought my Commodore-Amiga in 1991, IIRC one of the two popular
C compilers there (Aztec C) had 16-bit int by default. That was with
the Motorola 68000, which had 32-bit registers, but was a little bit
better at handling 16-bit values.
 
Of course, a lot of programmers never had to think about the micros
until later.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Victor Bazarov <v.bazarov@comcast.invalid>: Oct 26 02:44PM -0400

On 10/26/2015 1:09 PM, Stefan Ram wrote:
> { struct S { int a; const char* b; int c; int d; };
> S ss = { 1, "asdf" }; }
 
> .
 
Which element in the brace-enclosed initializer corresponds to the 'c'
member?
 
V
--
I do not respond to top-posted replies, please don't ask
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 26 08:13PM +0100

On 10/26/2015 7:44 PM, Victor Bazarov wrote:
 
>> .
 
> Which element in the brace-enclosed initializer corresponds to the 'c'
> member?
 
In C++03 items following the last value in a brace initializer list are
zero-initialized. I guess that's so also for C++14. However, g++ warns
about the 'c' member being uninitialized, which is a weird warning if my
gut feeling about it is correct.
 
Cheers,
 
- Alf
mark <mark@invalid.invalid>: Oct 26 09:49PM +0100

On 2015-10-26 18:09, Stefan Ram wrote:
> ^
 
> . Is it possible that this compiler does not consider
> classes with member initializers to be aggregates?
 
This was changed with C++14 / n3653:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3653.html
 
n3653 requires GCC 5:
https://gcc.gnu.org/projects/cxx1y.html
Victor Bazarov <v.bazarov@comcast.invalid>: Oct 26 05:02PM -0400

On 10/26/2015 2:54 PM, Stefan Ram wrote:
>> member?
 
> No element in the brace-enclosed initializer list
> corresponds to the data member c.
 
Sorry, I was running on half-the-cylinders. Yours is an aggregate, at
least according to the latest draft I got, and I think you already
received a conclusive response from mark that you need the next version
of the compiler.
 
V
--
I do not respond to top-posted replies, please don't ask
Vir Campestris <vir.campestris@invalid.invalid>: Oct 26 09:34PM

On 26/10/2015 19:13, Alf P. Steinbach wrote:
> zero-initialized. I guess that's so also for C++14. However, g++ warns
> about the 'c' member being uninitialized, which is a weird warning if my
> gut feeling about it is correct.
 
It annoys me intensely. I've got structures being initialised from
lists, and it warns me about any where the last fields are left to their
default constructors. The compiler people don't seem to see it as a problem.
 
Andy
woodbrian77@gmail.com: Oct 26 03:38PM -0700

On Monday, October 26, 2015 at 3:35:04 PM UTC-6, Vir Campestris wrote:
> lists, and it warns me about any where the last fields are left to their
> default constructors. The compiler people don't seem to see it as a problem.
 
> Andy
 
Clang warns about it too:
 
warning: missing field 'revents' initializer
[-Wmissing-field-initializers]
 
 
I find it a little annoying, but add the extra stuff
inside the braces and then forget about it.
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
ram@zedat.fu-berlin.de (Stefan Ram): Oct 26 06:54PM

>>S ss = { 1, "asdf" }; }
>Which element in the brace-enclosed initializer corresponds to the 'c'
>member?
 
No element in the brace-enclosed initializer list
corresponds to the data member c.
Ian Collins <ian-news@hotmail.com>: Oct 26 02:13PM +1300

Norman J. Goldstein wrote:
> be allocated, anyway, so just code up the release code in the
> destructor, and, then, no program-specific BOOST_SCOPE_EXIT is
> needed.
 
That's generally how I do it. Some types of resource may have specific
requirements around copying and sharing.
 
> use namespaces, .... Any other suggestions on this? I have
> used the "_mgr" suffix for the resource classes, like the "_ptr"
> suffix on the smart pointers.
 
I would consider those to be clutter in this context.
 
> a pointer, whichever is appropriate for the particualr resource.
> */
 
> PS I was not able to send the header file as an attachment.
 
Welcome to Usenet!
 
> struct IntFD_mgr {
> int fd_;
> IntFD_mgr( int fd = -1 ) : fd_( fd ) {}
 
I'm not a big fan of default parameters in constructors, I would have
written
 
int fd_ {-1};
 
IntFD() = default;
IntFD( int fd ) : fd_ {fd} {}
 
> int get( void ) const { return fd_; }
 
It's better to avoid C's use of void here, get() is idiomatic C++.
 
I would also add the full set of constructors and assignment operators
with the appropriate = default or = delete to make it clear which ones
are legal for this type of object.
 
--
Ian Collins
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)