Sunday, December 13, 2015

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

Vir Campestris <vir.campestris@invalid.invalid>: Dec 13 09:37PM

On 10/12/2015 23:07, Paavo Helde wrote:
> 32-bit platforms are something in the past, aren't
> they?
 
Certainly not in the embedded world.
 
Though we're finding it difficult to find anything with memory between
128k and a gigabyte... 128k is just too small. A gigabyte removes most
of our constraints, but it costs.
 
Andy
David Brown <david.brown@hesbynett.no>: Dec 14 12:18AM +0100

On 13/12/15 22:37, Vir Campestris wrote:
>> 32-bit platforms are something in the past, aren't
>> they?
 
> Certainly not in the embedded world.
 
32-bit is by far the dominant choice in embedded programming (at least
for C++ - there are still 8-bit and 16-bit devices around, but these are
mostly programmed in plain C).
 
 
> Though we're finding it difficult to find anything with memory between
> 128k and a gigabyte... 128k is just too small. A gigabyte removes most
> of our constraints, but it costs.
 
There are plenty of Cortex M3/M4 devices with 256K ram (and 1MB or more
flash). There are only a few devices around with more than 256K ram on
board. But there are also plenty of chips with DDR interfaces of some
sort giving pretty cheap support for 16+ MB ram.
"Lőrinczy Zsigmond" <nospam@for.me>: Dec 13 07:21PM +0100

constructor is the right way, especially if you can use named arguments:
 
Person (given_name=>"Zsigmond", family_name=>"Lorinczy",
name_order=>eastern);
 
Person (given_name=>"Barack", family_name=>"Obama",
name_order=>western);
JiiPee <no@notvalid.com>: Dec 13 06:33PM

Here they actually seem to give a lot of ways to do it...although they
do not seem all very practical:
 
https://marcoarena.wordpress.com/2014/12/16/bring-named-parameters-in-modern-cpp/
JiiPee <no@notvalid.com>: Dec 13 06:43PM

On 13/12/2015 18:33, JiiPee wrote:
> Here they actually seem to give a lot of ways to do it...although they
> do not seem all very practical:
 
> https://marcoarena.wordpress.com/2014/12/16/bring-named-parameters-in-modern-cpp/
 
yes, I would like this one to come on c++:
 
|createArray(length=10, capacity=20);
 
thats how it should be
|
"Öö Tiib" <ootiib@hot.ee>: Dec 13 11:25AM -0800

On Sunday, 13 December 2015 14:39:09 UTC+2, JiiPee wrote:
> code its very clear that John is passed as a first name
> (because in 1) that is not clear really)?
 
> This is what i have been struggled many times.
 
There are always some sort of special operations with any variable (add
title to "surname" or hide it, show a "length" with or without unit) or
constraint checks (does "name" start with capital letter, is "length"
positive value). Also some operations available to fundamental or library
types typically do not make sense (for example assigning "temperature"
to "length" or doing bitwise operations with either).
 
We can always make little classes that enwrap the fundamental or
library types for to add special operations and checks and remove
availability of redundant operations. Usage of such classes results with
bigger type-safety and clarity and with very little code generated. We
can avoid making non-explicit conversion constructors and conversion
operators and our code will be slightly more verbose but utterly
clear what is what.
 
class FirstName;
class Surname;
 
class Person
{
public:
Person(FirstName f, Surname s);
...
// data members....
};
 
...
 
Person driver(FirstName("John"), Surname("Smith"));
 
Other possibility is that we are ourselves keeping track of various
constraints and orders and using the fundamental or library types
directly. With good memory it is possible, but then we don't have your
problem anyway.
 
Person driver("John", "Smith");
 
Empty constructor + setters of single properties are bad thing since
those do not enforce compile-time that all mandatory properties are
set and if values of properties are interrelated then it may enforce
caller to use particular order of setters. So as result author has to
write and caller has to read even more documentation.
JiiPee <no@notvalid.com>: Dec 13 07:30PM

On 13/12/2015 18:54, Stefan Ram wrote:
> { double x; double y;
> ::std::cout << ::std::pow( x = 2, y = 3 )<< '\n'; }
 
> 8
 
oh but this is not we are talking about. We are talking about:
we have a function:
 
void createArray(int length, int capacity);
and it is called:
createArray(length=10, capacity=20);
 
so this:
createArray(len=10, capacity=20);
 
would give a compiler error because the first must be
length
JiiPee <no@notvalid.com>: Dec 13 07:34PM

On 13/12/2015 19:25, Öö Tiib wrote:
> };
 
> ...
 
> Person driver(FirstName("John"), Surname("Smith"));
 
yes, this is one solution, and quite simple one as well. Just needs to
find a way to quickly make those classes :). But surely that is
possible, there are tools for that. If you have right tools, creating a
small class like that takes only 5 seconds
David Brown <david.brown@hesbynett.no>: Dec 13 08:50PM +0100

On 13/12/15 16:11, Paavo Helde wrote:
> int f(int y, int x); // a legal redeclaration (currently)
 
> f(1,2); // no ambiguity
> f(x => 1, y => 2); // ???
 
There is currently a proposal to add named parameters to C++17, and it
would simply be illegal to use them if there were contradictory
declarations in scope. (The proposed syntax is slightly different, "f(x
: 1, y : 2);", but the principle is the same.)
 
I would like compilers to have such legal but contradictory
redeclarations as a common warning - there is no reason for them except
to confuse people using the code.
David Brown <david.brown@hesbynett.no>: Dec 13 09:15PM +0100

On 13/12/15 14:58, JiiPee wrote:
> argument.... you cannot see it from the code.
 
> So we do not know whether the first name should be the first argument or
> the second, that is the problem.
 
The problem with this is that there is no distinction between FirstName
and SecondName - these need to be separate classes in order to make
everything safe:
 
class Person {
public:
class FirstName {
public:
FirstName(string firstName) :
fname(firstName)
{}
string fname;
};
class SecondName {
public:
SecondName(string secondName) :
sname(secondName)
{}
string sname;
};
 
Person(FirstName firstName, SecondName secondName) :
fname(firstName.fname), sname(secondName.sname)
{}
Person(SecondName secondName, FirstName firstName) :
PersonB(firstName, secondName)
{}
private:
string fname;
string sname;
};
 
void foo2(void) {
// This is an error
Person("John", "Smith");
}
 
void foo3(void) {
Person(Person::FirstName("John"), Person::SecondName("Smith"));
}
 
void foo4(void) {
Person(Person::SecondName("Smith"), Person::FirstName("John"));
}
 
Some templates (or at least some macros) could be used to make the
overhead of the extra classes smaller in the source code (the optimiser
should remove all run-time overhead), and "using" could make the calls
to Person() neater - but at least it will accept the parameters in any
order, and always be safe.
JiiPee <no@notvalid.com>: Dec 13 10:17PM

On 13/12/2015 20:15, David Brown wrote:
> The problem with this is that there is no distinction between
> FirstName and SecondName - these need to be separate classes in order
> to make everything safe:
 
 
thanks, a good code example
ram@zedat.fu-berlin.de (Stefan Ram): Dec 13 06:54PM

>yes, I would like this one to come on c++:
>|createArray(length=10, capacity=20);
 
#include <iostream>
#include <ostream>
#include <cmath>
 
int main()
{ double x; double y;
::std::cout << ::std::pow( x = 2, y = 3 )<< '\n'; }
 
8
scott@slp53.sl.home (Scott Lurndal): Dec 03 09:10PM

>maybe 15 or even 20 years after that. Though I suppose it depends on
>what you mean by production too - this was OS internals, device drivers,
>H/W test code and such.
 
Indeed, that is where there still is some machine level
programming going on.
 
However, by 1966 most applications were written using COBOL
and FORTRAN.
 
>I'm mostly working on ARM systems these days, and it still annoys me
>that I can't really understand the assembly language. Not enough to go
>and learn it though...
 
Just wait until you try the ARMv8 version - they've simplified things
a bit from the ARMv7 (no more predicated instructions, no Thumb and
no Jazelle for example).
 
scott
Lynn McGuire <lmc@winsim.com>: Dec 03 03:42PM -0600

On 12/3/2015 3:10 PM, Scott Lurndal wrote:
> a bit from the ARMv7 (no more predicated instructions, no Thumb and
> no Jazelle for example).
 
> scott
 
Ok, now you are scaring me. Thumb and Jazelle instructions?
http://www.keil.com/support/man/docs/armasm/armasm_dom1359731126163.htm
https://en.wikipedia.org/wiki/Jazelle
 
Lynn
David Brown <david.brown@hesbynett.no>: Dec 04 10:39AM +0100

On 03/12/15 22:45, Vir Campestris wrote:
 
> We've got some little chips, so Thumb (Thumb2) is firmly on the radar.
> I've never had to decode it though. Jazelle I hadn't heard of, and I
> guess has been killed by precompiling the Java.
 
Thumb and Thumb2 are significantly different. Thumb supported only
16-bit instructions, with a number of serious limitations - on ARM's
with Thumb, you regularly had to switch between Thumb mode (for compact
code) to ARM mode (for fast code, interrupts, or more features).
 
Thumb2 has most common instructions in 16-bit format (with a fair
overlap with Thumb, but also plenty of differences), and 32-bit format
for other instructions. This means you get very close to full 32-bit
ARM ISA speed, but reduce code size by about a third. Newer devices
(Cortex) support Thumb2 - Thumb only exists on older devices. And
Cortex-M microcontrollers support /only/ Thumb2 - there is no "ARM" mode.
 
As for Jazelle, it was for accelerating Java, and was only marginally
successful. It has been dropped now - Cortex A devices have an
alternative ThumbEE mode. This is very like Thumb2, but with a few
instructions dropped (to free up instruction code space) and
instructions to support range checking, null pointer checks, etc. In
theory, this mode could be used in normal compilation too, but it is
primarily targeted at JIT execution environments (not just Java, but
also Python, dotnet, etc.)
"Chris M. Thomasson" <nospam@nospam.nospam>: Dec 03 01:13PM -0800


> > What a piece of shi% move on their part. As%holes!
 
> Yeah. How dare they offer an upgrade for free. They should be ashamed
> of themselves.
 
The problem is that the icon freaked me out for I instantly thought I had a
virus.
 
The fact that I can get Win10 for free is pretty nice.
"Chris M. Thomasson" <nospam@nospam.nospam>: Dec 03 01:15PM -0800

> "Chris M. Thomasson" wrote in message
> news:n3qb9r$eep$1@speranza.aioe.org...
 
[...]
 
> The problem is that the icon freaked me out for I instantly thought I had
> a virus.
 
> The fact that I can get Win10 for free is pretty nice.
 
BTW, do you know how to get the damn annoying icon off the screen for good?
 
I am not sure I want Win10 yet. I am missing an option to get rid of that
little shi%!
Chris in Makati <mail@nospam.com>: Dec 04 11:22AM +0800

On Thu, 3 Dec 2015 09:16:32 +0000 (UTC), Juha Nieminen
>If they determine that it wasn't your fault, they will not punish the
>innocent.
 
>Besides, how would they even know what's in your computer?
 
If you do a Google search for <child porn arrested> you will find
literally thousands of cases where raids have taken place and people
have been found with this material on their computers.
 
In many of these cases the authorities have traced the IP addresses of
people whose computers have made connections to known sites that host
child porn. It's no use trying to claim that a bot you weren't aware
of downloaded it without your knowledge. If you could get off the hook
that easily everybody who was interested in the stuff would
deliberately install such a bot and use that as an excuse.
Paavo Helde <myfirstname@osa.pri.ee>: Dec 13 10:27AM -0600

ram@zedat.fu-berlin.de (Stefan Ram) wrote in news:slow-vector-
> ntdll.dll!RtlUserThreadStart
 
> What's this? My program spends most of its time to »wait
> for multiple objects«??
 
This stack looks like some auxiliary service thread possibly created by
gcc itself. Find your actual working thread and study it instead.
 
Note also that it is not guaranteed at all that a "stack monitor" is able
to display correct stacks, especially for optimized compilations. In my
experience they are often at least partially garbage.
 
Cheers
Paavo
"Öö Tiib" <ootiib@hot.ee>: Dec 12 04:33PM -0800

On Saturday, 12 December 2015 19:09:52 UTC+2, Daniel wrote:
> alignof(A)>::type storage_type;
 
> char* storage = new char [sizeof(storage_type)];
> A* pa = new(storage)A();
 
Seems that you pointlessly manufacture that 'storage_type' there.
 
// that looks better and works
storage_type* storage = new storage_type;
A* pa = new(storage)A();
 
// that also works since new provides maximally aligned storage
char* storage = new char [sizeof(A)];
A* pa = new(storage)A();
 
The likes of that 'storage_type' are typically used to reserve space
in automatic storage or as a data member of class:
 
// in automatic storage
storage_type storage;
A* pa = new(&storage) A();
 
> char* storage = new char [sizeof(storage_type)+length*sizeof(int)];
> B* pb = new(storage)B();
 
> pb->p = new(storage + sizeof(storage_type))int[length];
 
It isn't guaranteed that alignment requirements for 'int' are not stricter
than alignment requirements for that 'B'. It is unlikely that you can find
any C++11 compiler where these are stricter but world may change.
 
Also if there was 'long double' instead of 'int' then alignment requirements for it are often stricter than for the 'B' of yours and then your program
would not work correctly.
 
Following code is bit more paranoid about that possible padding. When
padding is zero then compiler will likely figure it out and optimize
away:
 
constexpr size_t padding = (alignof(int) - (sizeof(B) % alignof(int))) % alignof(int);
 
size_t length = 10;
char* storage = new char [sizeof(B) + padding + sizeof(int)*length];
 
B* pb = new(storage) B();
 
pb->length = length;
pb->p = new(storage + sizeof(B) + padding) int[length];
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)