Tuesday, October 27, 2015

Digest for comp.lang.c++@googlegroups.com - 23 updates in 6 topics

Juha Nieminen <nospam@thanks.invalid>: Oct 27 11:08AM

Consider this:
 
//--------------------------------------------------
namespace
{
class Foo
{
public:
void bar();
};
}
 
void Foo::bar() { std::cout << "Hello"; }
//--------------------------------------------------
 
The class 'Foo' is declared as local to the current compilation unit,
but the Foo::bar() is seemingly defined in global namespace (because
it's outside the nameless namespace block.)
 
What happens here? Is Foo::bar() local to the current compilation unit?
 
(I would hope so. This way I can avoid an extra indentation level.)
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Victor Bazarov <v.bazarov@comcast.invalid>: Oct 27 08:08AM -0400

On 10/27/2015 7:08 AM, Juha Nieminen wrote:
> it's outside the nameless namespace block.)
 
> What happens here? Is Foo::bar() local to the current compilation unit?
 
> (I would hope so. This way I can avoid an extra indentation level.)
 
The name 'Foo' in the member function declaration/definition is actually
resolved during compilation to something like
'<UniqueToThisSourceFileNamespace>::Foo', where that name is generated
by the compiler, so there should be no worries of its being visible from
outside.
 
V
--
I do not respond to top-posted replies, please don't ask
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 28 12:24AM +0100

On 10/27/2015 12:08 PM, Juha Nieminen wrote:
> but the Foo::bar() is seemingly defined in global namespace (because
> it's outside the nameless namespace block.)
 
> What happens here? Is Foo::bar() local to the current compilation unit?
 
No, it has external linkage, but it's declared in an anonymous namespace
whose linkage level name will probably be some statistically unique
sequence of letters and digits.
 
So, in practice it can't be called directly from other translation units.
 
As for why and how the above code compiles, consider that the following
code is equivalent except for the namespace name:
 
namespace my {
struct S
{
void foo();
};
} // namespace my
 
#include <iostream>
using namespace my;
 
void S::foo() { std::cout << "Oh!\n"; }
 
auto main() -> int
{
S().foo();
}
 
Cheers & hth.,
 
- Alf
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 27 09:35PM

On Sun, 25 Oct 2015 10:05:42 -0700 (PDT)
woodbrian77@gmail.com wrote:
snip]
> That's from a comment to a question on Stackoverflow.
> Are there some cases where std::list::splice makes list a
> good choice?
 
Using std::list::splice for removing and inserting elements offers the
closest to lock-free performance you can get for a standard container
under contention from multiple threads. That is because it only swaps
pointers: you only need lock a mutex for the pointer swap, not for the
construction, destruction and copying of nodes. Depending on the
container element you may of course get better performance under
contention by using a truly lock-free solution, but that doesn't suit
all cases.
 
There might also be a case for using std::list where the container
element is not a built-in type, is large and does not have an efficient
move assignment operator, and you need both to have an ordered
container and to make many insertions and deletions throughout the
container. But you would need convincing evidence with profiling first.
 
Chris
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 27 11:09PM

On 27/10/2015 21:35, Chris Vine wrote:
> move assignment operator, and you need both to have an ordered
> container and to make many insertions and deletions throughout the
> container. But you would need convincing evidence with profiling first.
 
There are plenty of reasons for using std::list.
 
/Flibble
asetofsymbols@gmail.com: Oct 27 01:00PM -0700

ρι6
Why one can not define
in C++
a set
of operators as
int operatorρ(Matrix<T>& a)
?
Why not add 1/2 of new 16 bit
character
set as definable as operators
(points) and other 1/2 as
letter for names?
Wouter van Ooijen <wouter@voti.nl>: Oct 27 10:54PM +0100

> set as definable as operators
> (points) and other 1/2 as
> letter for names?
 
Which 'why' are you asking about?
- because the standard says that you can't
- because it is a bad idea to define new operators
- because Soustroup did not like it
- because that operator was not available in C
- because it would not merge well with the set of precedences
- because we generally prefer to use ASCII in modern programming langauges
- etc
 
Wouter
"Öö Tiib" <ootiib@hot.ee>: Oct 27 04:30AM -0700

On Monday, 26 October 2015 13:00:40 UTC+2, Rosario19 wrote:
> and all type in my classes are public
> and in every part of the code i can change them
> [admit rarely chage them out the classes function]
 
By my measurements the C++ standard libraries provide excellent
performance. Non-naive usage of those is quite hard to beat with
explicit C code.
 
All C++ standard library containers have 'size()' member
function in interface so we do not need to dig in their implementation
details every time. We can replace one container with other with
minimum changes needed and that saves time. Compiler will inline
and optimize these well. Manual optimizations are almost never needed.
 
Let's go to details? Implementation of 'vector::size()' may be something
like that:
 
return static_cast<size_type>( end_ - begin_ );
 
Likelihood of 'size()' being calculated instead of stored is because
majority of algorithms and range based 'for' use 'begin' and 'end'
more often than 'size' and storing all 3 is waste of space.
 
The 'size' of 'std::string' can be taken from some data member,
but when it uses small string optimization then it may be
conditionally stored as 7 bits and when not then in 32. Again it is
not your business, you are supposed to call 'size()'.
 
So it is you who are in error here. In general better do some real
benchmarks and post results (don't do these with debug build like
noob). Groundless uneducated whining is uninteresting.
woodbrian77@gmail.com: Oct 27 10:36AM -0700

On Tuesday, October 27, 2015 at 6:30:50 AM UTC-5, Öö Tiib wrote:
> details every time. We can replace one container with other with
> minimum changes needed and that saves time. Compiler will inline
> and optimize these well. Manual optimizations are almost never needed.
 
I'm not sure if foward_list has a size member function:
 
http://www.cplusplus.com/reference/forward_list/forward_list/
 
 
Brian
Ebenezer Enterprises - We few, we happy few; we band of brothers.
http://webEbenezer.net
bartekltg <bartekltg@gmail.com>: Oct 27 08:25PM +0100

>> and optimize these well. Manual optimizations are almost never needed.
 
> I'm not sure if foward_list has a size member function:
 
> http://www.cplusplus.com/reference/forward_list/forward_list/
 
You are right, but also you do not use [] operator on forward_list
(list doesn't have that operator:) and rather base for loop would
on iterators.
 
 
bartekltg
FredK <fred.l.kleinschmidt@gmail.com>: Oct 27 07:47AM -0700

On Sunday, October 25, 2015 at 11:43:48 PM UTC-7, Paavo Helde wrote:
> values (and char is signed in common implementations), so if you are not
> 100% sure your texts are ASCII-only one should better check for that or
> at least cast cz to unsigned char before passing to toupper.
 
Note the important disclaimer that MikeCopeland added: "Assuming ASCII".
There is no guarantee that the letters are in sequential order; there are many character sets where 'a'+2 might not be 'c'.
legalize+jeeves@mail.xmission.com (Richard): Oct 27 05:37PM

[Please do not mail me a copy of your followup]
 
MikeCopeland <mrc2323@cox.net> spake the secret code
 
> The following code doesn't work (as I want it to). Specifically, it
>produces "20367c", whereas I want it to yield "203Cc". For some reason,
>the "toupper(char(cz))" is yeilding 67, not C. What am I doing wrong?
 
toupper returns an int, not a char.
 
<http://en.cppreference.com/w/cpp/string/byte/toupper>
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Paavo Helde <myfirstname@osa.pri.ee>: Oct 27 02:25PM -0500

FredK <fred.l.kleinschmidt@gmail.com> wrote in
>> that or at least cast cz to unsigned char before passing to toupper.
 
> Note the important disclaimer that MikeCopeland added: "Assuming
> ASCII".
 
This was added by Stefan Ram.
 
> There is no guarantee that the letters are in sequential
> order; there are many character sets where 'a'+2 might not be 'c'.
 
I bet Mike Copeland will never get in touch with those character sets. On
the other hand, no common systems are using plain ASCII nowadays, they
are all extended ASCII-based charsets like iso-latin-1 or UTF-8. In this
case 'a'+2 will still equal 'c', but passing a char representing e.g. a-
umlaut to toupper() may easily crash the program.
 
Cheers
Paavo
bartekltg <bartekltg@gmail.com>: Oct 27 02:47AM +0100

On 26.10.2015 17: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.
 
I clearly remember 16bit int around 1995 on PC ;-)
 
int32_t would be better. And longer ;-)
 
best
bartekltg
bartekltg <bartekltg@gmail.com>: Oct 27 02:54AM +0100

On 26.10.2015 18:47, Geoff wrote:
 
>>> #define ooo cout
 
>> WTF? ;-)
 
> That should be std::cout. ;)
 
Yes, you are right. And Scott is even more right.
The more scope operators the better is the code...
or at least have more dots...::...
 
But why ::ooo::?
Obviously obfuscated output?
 
best
bartekltg
Geoff <geoff@invalid.invalid>: Oct 26 09:30PM -0700

On Tue, 27 Oct 2015 02:54:01 +0100, bartekltg <bartekltg@gmail.com>
wrote:
 
>or at least have more dots...::...
 
>But why ::ooo::?
>Obviously obfuscated output?
 
Good one, and probably correct.
 
I don't know why I bothered to respond to Rosario19 at all. He seems
to think posting this kind of code is cute. Then he finds bugs,
reposts, finds more bugs, reposts and asks questions when he outsmarts
himself and can't grok his own code.
Rosario19 <Ros@invalid.invalid>: Oct 27 07:56AM +0100

On Mon, 26 Oct 2015 11:20:03 +0100, Rosario19 <Ros@invalid.invalid>
wrote:
 
>do you like my first try to the code golf problem:
>http://codegolf.stackexchange.com/questions/61684/calculate-the-bounded-cumulative-sum-of-a-vector
>?
 
#include <iostream.h>
#include <stdlib.h>
 
#define u8 unsigned char
#define i8 signed char
#define u16 unsigned short
#define i16 signed short
#define u32 unsigned
#define i32 int
#define f64 double
 
#define P printf
#define R return
#define F for
#define GG(a,b) if(a)goto b
#define G goto
#define S sizeof
#define SA(a) (sizeof(a)/(sizeof a[0]))
#define ooo cout
#define FE(a,b) for(a=0; a<(b).len; ++a)
#define FC(b) for(unsigned indiceloc=0; indiceloc<(b).len;
++indiceloc)
 
#define MM malloc
#define FF free
 
template<class T> class V{
public:
 
V()
{size=0; len =0; ele=0;
va =(T*)MM(10*S(T));
if(va==0){ele=1; e=1; R;}
size=10;
}
 
V(u32 s)
{size=0; len =0; ele=0;
va =(T*)MM(s*S(T));
if(va==0){ele=1; e=1; R;}
size=s;
}
 
V(T* s, u32 sz)
{u32 i;
size=0; len =0; ele=0;
va =(T*)MM(sz*S(T));
if(va==0){ele=1; e=1; R;}
F(i=0; i<sz; ++i)
va[i]=s[i];
len =sz;
size=sz;
}
 
V(T& o)
{u32 i;
size=0; len =0; ele=0; va=0;
i=o.ele? o.len: 10;
va =(T*)MM(i*S(T));
if(va==0){ele=1; e=1; R;}
if(i!=o.len)
{size=10;
ele =1; e=1;
R;
}
F(i=0; i<o.len; ++i)
va[i]=o.va[i];
len =o.len;
size=o.len;
}
 
~V(){FF(va);}
 
T& operator[](u32 i)
{T *p;
 
if(i>=size)
{if(i>=0xFFFFFE00)
R meno1;
p=(T*) realloc(va, (i+256)*S(T));
if(p==0) R meno1;
va=p; size=i+256;
}
if(i>=len) len=i+1; // i>len assign that element
R va[i];
}
 
V<T>& operator=(V<T>& a)
{u32 i;
T *p;
 
ele=0;
if(a.ele!=0)
{
l0: ele=1; G z; /* errore trovato e riportato */
}
if(a.len>size)
{p=(T*) realloc(va, a.len*S(T));
GG(p==0, l0); va=p; size=a.len;
}
FE(i,a) va[i]=a.va[i];
len=i;
z: R *this;
}
 
u32 assign(T* a, u32 c)
{u32 j;
T *p;
if(c>=size)
{if(c>=0xFFFFFE00)
R -1;
p=(T*) realloc(va, c*S(T));
if(p==0) R -1;
va=p; size=c;
}
F(j=0; j<c; ++j) va[j]=a[j];
len=c;
R 0;
}
 
friend ostream& operator<<(ostream& ost, V<T>& m)
{u32 c;
if(m.ele) ost<<"{vector error}";
else FE(c,m){if(c==0) ost<<"{";
ost<<m[c]<< (c+1!= m.len? ", ": "}");
}
R ost;
}
 
u32 size;
u32 len;
T *va;
u32 ele; // element error
static T meno1; // element error1
static u32 e; // class error
};
template<class T> u32 V<T>::e=0;
template<class T> T V<T>::meno1=(T)-1;
 
//81
f(V<i32>*a,i32 m,i32 b){i32
r=0,*p=a->va;FC(*a){r+=*p;*p++=r=(r<m?m:(r>b?b:r));}}
 
int main(void)
{i32 v1[]={1, 4, 3, -10, 3, 2, 2, 5, -4},
v2[]={1, 1, 1, 1, 1, 1},
v3[]={10, -4, -3, 2},
v4[]={3, 5, -2, 1},
v5[]={1, 4, 6};
i32 upper_lim;
i32 lower_lim;
V<i32> org;
 
upper_lim = 6;
lower_lim = -2;
org.assign(v1, SA(v1));
ooo<<"input ="<<org<<"\n";
f(&org, lower_lim, upper_lim);
ooo<<"output="<<org<<"\n";
ooo<<"result=[1 5 6 -2 1 3 5 6 2]\n";
 
 
upper_lim = 100;
lower_lim = -100;
org.assign(v2, SA(v2));
ooo<<"input ="<<org<<"\n";
f(&org, lower_lim, upper_lim);
ooo<<"output="<<org<<"\n";
ooo<<"result=[1 2 3 4 5 6]\n";
 
upper_lim = 5;
lower_lim = 0;
org.assign(v3, SA(v3));
ooo<<"input ="<<org<<"\n";
f(&org, lower_lim, upper_lim);
ooo<<"output="<<org<<"\n";
ooo<<"result=[5 1 0 2]\n";
 
upper_lim = 0;
lower_lim = 0;
org.assign(v4, SA(v4));
ooo<<"input ="<<org<<"\n";
f(&org, lower_lim, upper_lim);
ooo<<"output="<<org<<"\n";
ooo<<"result=[0 0 0 0]\n";

upper_lim = 10;
lower_lim = 5;
org.assign(v5, SA(v5));
ooo<<"input ="<<org<<"\n";
f(&org, lower_lim, upper_lim);
ooo<<"output="<<org<<"\n";
ooo<<"result=[5 9 10]\n";

R 0;
}
---------
 
input ={1, 4, 3, -10, 3, 2, 2, 5, -4}
output={1, 5, 6, -2, 1, 3, 5, 6, 2}
result=[1 5 6 -2 1 3 5 6 2]
input ={1, 1, 1, 1, 1, 1}
output={1, 2, 3, 4, 5, 6}
result=[1 2 3 4 5 6]
input ={10, -4, -3, 2}
output={5, 1, 0, 2}
result=[5 1 0 2]
input ={3, 5, -2, 1}
output={0, 0, 0, 0}
result=[0 0 0 0]
input ={1, 4, 6}
output={5, 9, 10}
result=[5 9 10]
Christian Gollwitzer <auriocus@gmx.de>: Oct 27 08:30AM +0100

Am 27.10.15 um 07:56 schrieb Rosario19:
 
> #include <iostream.h>
> #include <stdlib.h>
> [....]
 
Ah, you invented a new discipline: Anti-golf. That's why you use .h
include files
 
Christian
David Brown <david.brown@hesbynett.no>: Oct 27 09:49AM +0100

On 26/10/15 23:59, Jorgen Grahn wrote:
> 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.
 
The original 68k was almost twice as fast at handling 16-bit values,
since it had a 16-bit ALU and internal datapath. The design was for
16-bit cpu, since that was the standard at the time and a "real" 32-bit
implementation would have been far too costly, but with a clear and
fully-supported 32-bit path towards future versions. It was one of the
very few designs which was made flexible for forward compatibility,
rather than (like the x86 line) crippled by backward compatibility.
 
David Brown <david.brown@hesbynett.no>: Oct 27 09:52AM +0100

On 27/10/15 02:54, bartekltg wrote:
> or at least have more dots...::...
 
> But why ::ooo::?
> Obviously obfuscated output?
 
That's how Rosario19 writes his code - at least in newsgroups
(presumably he does not write code like that for a living). He is
usually to be found in comp.lang.c, rather than here, and he writes this
kind of line noise regularly. I have no idea why. People in c.l.c.
usually just ignore him.
asetofsymbols@gmail.com: Oct 27 02:50AM -0700

Ah, you invented a new discipline: Anti-golf. That's why you use .h
include files
 
Christian
_______
My target is not win that
competition with C++
it is write a C++ library + macro def
that allow C++ compete with
their languages Apl in the middle
scott@slp53.sl.home (Scott Lurndal): Oct 27 12:58PM


>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++).
 
I've seen systems with 64-bit "long int", but I've not seen
systems with 64-bit "int" - do you have any references?
 
The only oddball systems left in production are 48-bit (Unisys Clearpath Libra/Burroughs)
and 36-bit (Unisys Clearpath Dorado/Univac), and they're both emulated nowadays.
 
I believe the libra (formerly burroughs large systems) systems have a C
compiler, but I'm not sure about C++.
David Brown <david.brown@hesbynett.no>: Oct 27 03:02PM +0100

On 27/10/15 13:58, Scott Lurndal wrote:
>> still in use today (though perhaps not with C++).
 
> I've seen systems with 64-bit "long int", but I've not seen
> systems with 64-bit "int" - do you have any references?
 
I think Crays used 64-bit int, and there were some Sparc64 systems with
64-bit int. I don't know of any that would be considered common or
mainstream - I merely point out that such systems exist.
 
64-bit long is, of course, extremely common - it is standard in 64-bit
*nix systems. Windows is unusual in having 32-bit longs in their 64-bit OS.
 
 
> The only oddball systems left in production are 48-bit (Unisys Clearpath Libra/Burroughs)
> and 36-bit (Unisys Clearpath Dorado/Univac), and they're both emulated nowadays.
 
I wasn't thinking of new systems in production, but old oddball systems
that are still running - some of these old mainframes never seem to die.
 
Of course, there are very, very few, if any, systems around where it is
likely that one would be writing new code in C++ (or even C) that has an
int size other than 32-bit or 16-bit.
 
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)