Wednesday, October 1, 2014

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

comp.lang.c++@googlegroups.com Google Groups
Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.lang.c+++unsubscribe@googlegroups.com.
"Öö Tiib" <ootiib@hot.ee>: Sep 30 05:01PM -0700

> > or even better than the boost solution?
 
> I don't really know Boost.Units,
> but here are some apparent differences.
 
You know it far better than most C++ developers.
 
> Boost.Units supports 12-year-old compilers, while Cpp-Measures
> requires, and takes advantage of, the parts of C++11 available
> in GCC and VC++ 2012.
 
Yes boost maybe supports too exotic compilers and that makes
sometimes its code hard to follow. OTOH the development
tools for most electronic devices around us catch up slowly
so supporting only few latest compilers may narrow target
audience down too lot.
 
> in the library, while Cpp-Measures requires that the application
> programmer defines the needed magnitudes and the units,
> although many examples will be available in documentation.
 
Maybe it makes sense to do like boost, standardized systems of
dimensions like SI or CGS do not change too often.
 
> and less than 1 MB with all tests and documentation.
> It is not clear to me how to install only the Boost.Units library
> and its dependencies instead of all Boost.
 
That is odd floppy-drive era argument I read so often.
Size of good quality movie file is like 17-40 gigabytes.
Just erase one and you can install another 34-80
versions of Boost. :)
 
> T1p(32.0*absolute<fahrenheit::temperature>());
 
> corresponds to the following Cpp-Measures expression
 
> point1<fahrenheit> T1p(32);
 
Names like "quantity absolute" and "quantity" feel bit
more intuitive than "point1" and "vec1" but YMMV.
If "point1" makes more sense in some problem domain then
one can likely alias that:
 
template<class T> using point1 = quantity<absolute<T>>;
 
> when compiled using GCC for Windows, with stripping and optimization,
> takes 3 times the time to compile the equivalent code
> using Cpp-Measures, and generates an executable 7 times as large.
 
That is most important plus to you if it actually holds. I mean
efficiency and performance benchmarking is tricky work.
 
> Cpp-Measures supports 2-dimensional and 3-dimensional measures,
> with algebraic operations, dot product and cross product,
> while I couldn't find such features in Boost.Units.
 
I suspect that the existing linear algebra libraries
(like Eigen, MTL4, boost.uBLAS or Armadillo) do not integrate
neither with your cpp-measures nor with boost.units too well.
OTOH it is likely hard to beat performance and quality of such
libraries.
 
So instead of building linear algebra into your dimensioned
values library it might be worth considering seeking
interoperability with one of those. Two good things that
play together often result with great outcome.
Wouter van Ooijen <wouter@voti.nl>: Oct 01 08:25AM +0200

>> or even better than the boost solution?
 
> I don't really know Boost.Units,
> but here are some apparent differences.
 
Eh, you really don't know B.U yet at the same time you are not satisfied
by it??
 
> Boost.Units supports 12-year-old compilers, while Cpp-Measures
> requires, and takes advantage of, the parts of C++11 available
> in GCC and VC++ 2012.
 
Does that mean anything for me as user of either package?
 
> and less than 1 MB with all tests and documentation.
> It is not clear to me how to install only the Boost.Units library
> and its dependencies instead of all Boost.
 
IMO that is totally irrelevant.
 
> T1p(32.0*absolute<fahrenheit::temperature>());
 
> corresponds to the following Cpp-Measures expression
 
> point1<fahrenheit> T1p(32);
 
Now that IS relevant.
 
> Application code using Cpp-Measures is compiled faster
> and produces less machine code.
 
Faster compilation is not that interesting, but samll code certainly is
(from my point of view: working with very small microcontrollers).
 
> when compiled using GCC for Windows, with stripping and optimization,
> takes 3 times the time to compile the equivalent code
> using Cpp-Measures, and generates an executable 7 times as large.
 
But it makes me wonder what makes B.U generate more code: just
clumsiness, or does it do other (more) usefull things?
 
 
> While a variable representing a relative length measured
> in inches, is defined as:
 
> vect1<inches> variable_name;
 
Nice. I assume that adding points is not possible, substracting points
yields a vect, etc?
 
> Not tested yet, and probably not working properly yet
> fixed-point, rational, multiple-precision,
> and arbitrary-precision types.
 
That last sentence is interesting. After testing that many types
already, why would one of those yet-some-other-types not work out of the
box? That means that a numeric type that I write will likly suffer the
same fate.
 
>> - can you work with mixed base types (for instance fixed-point types
>> based on integers of various size and scaling)?
 
> Automatic conversion between fixed-point types is not supported yet,
 
If you mean conversion by implicit conversion operators: keep that
unsupported!
 
> and it has value 3.5.
> --
 
> Carlo Milanesi
 
If I can find the time I will have a closer look at your work.
 
Wouter van Ooijen
Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 01 11:30AM

On Wed, 2014-10-01, Wouter van Ooijen wrote:
>> but here are some apparent differences.
 
> Eh, you really don't know B.U yet at the same time you are not satisfied
> by it??
 
There is no rule which says you have to know Foo in and out before
you're allowed to write Bar which does roughly the same thing.
 
(Not that I have any opinion on either Boost.Unit or this one.)
 
[snip more detailed criticism]
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Wouter van Ooijen <wouter@voti.nl>: Oct 01 06:40PM +0200

Jorgen Grahn schreef op 01-Oct-14 1:30 PM:
>> by it??
 
> There is no rule which says you have to know Foo in and out before
> you're allowed to write Bar which does roughly the same thing.
 
But it would be peculiar if you state both
- that you don't know Bar
- that the reason for writing Foo is that you are dissatisfied with Bar
 
Wouter
Chairman Mao <maotse30million@gmail.com>: Oct 01 02:32AM -0700

I don't understand how this code compiles. For me, the function should be defined as `void f(const A::B& b)`, but g++ says that A::B is not a type.
 
struct A
{
struct B* p;
};
 
void f(const B& b )
{
}
 
int main()
{
A a;
f(*a.p);
}
Ian Collins <ian-news@hotmail.com>: Oct 01 11:46PM +1300

Chairman Mao wrote:
 
> struct A { struct B* p; };
 
> void f(const B& b ) { }
 
> int main() { A a; f(*a.p); }
 
Where is B declared?
 
--
Ian Collins
Chairman Mao <maotse30million@gmail.com>: Oct 01 03:57AM -0700

On Wednesday, October 1, 2014 7:47:12 AM UTC-3, Ian Collins wrote:
 
> Where is B declared?
 
> --
 
> Ian Collins
 
I don't know. That's exactly the reason for my question.
Louis Krupp <lkrupp@nospam.pssw.com.invalid>: Oct 01 05:52AM -0600

On Wed, 01 Oct 2014 23:46:57 +1300, Ian Collins <ian-news@hotmail.com>
wrote:
 
 
>> void f(const B& b ) { }
 
>> int main() { A a; f(*a.p); }
 
>Where is B declared?
 
As far as I can tell, B is *declared* on the third line, when A.p is
defined as type struct B*, but B is never completely *defined*.
 
 
f(const B& b) is OK because it never actually *does* anything with its
argument.
 
Louis
Chairman Mao <maotse30million@gmail.com>: Oct 01 05:45AM -0700

On Wednesday, October 1, 2014 8:52:41 AM UTC-3, Louis Krupp wrote:
 
> f(const B& b) is OK because it never actually *does* anything with its
 
> argument.
 
> Louis
 
I believe this has to with §3.3.2/6, but I can't see the exact relation between this paragraph and the code.
 
§3.3.2/6:
 
"The point of declaration of a class first declared in an elaborated-type-specifier is as follows:
-- for a declaration of the form class-key attribute-specifier-seqopt identifier;
the identifier is declared to be a class-name in the scope that contains the declaration, otherwise
-- for an elaborated-type-specifier of the form class-key identifier if the elaborated-type-specifier is used in the decl-specifier-seq or parameter-declaration-clause of a function defined in namespace scope, the identifier is declared as a class-name in the namespace that
contains the declaration; otherwise, except as a friend declaration, the identifier is declared in the smallest namespace or block scope that contains the declaration. [ Note: These rules also apply within templates. --end note ] [ Note: Other forms of elaborated-type-specifier do not declare a new name,
and therefore must refer to an existing type-name. See 3.4.4 and 7.1.6.3. --end note ]
"Tobias Müller" <troplin@bluewin.ch>: Oct 01 12:47PM

> {
> struct B* p;
> };
 
B is only declared here, not defined.
That means you can define B* and B& variables but not variables of type B.
 
> void f(const B& b )
> {
> }
 
I didn't actually try this out but I'd say that B is not even visible at
that point. I'm not absolutely sure though.
const A::B& b would be clear.
 
> A a;
> f(*a.p);
> }
 
Here you dereference a B*, the result would have type B. This is not
allowed since B is only declared, but not defined.
 
Tobi
"Tobias Müller" <troplin@bluewin.ch>: Oct 01 12:57PM


> Here you dereference a B*, the result would have type B. This is not
> allowed since B is only declared, but not defined.
 
> Tobi
 
Rereading the question, it seems that I completely missed the point.
 
Just speculating but could it be that 'struct B' is just a C-Style struct
label and does not actally declare a type A::B?
 
Tobi
Victor Bazarov <v.bazarov@comcast.invalid>: Oct 01 09:30AM -0400

On 10/1/2014 8:57 AM, Tobias Müller wrote:
 
> Rereading the question, it seems that I completely missed the point.
 
> Just speculating but could it be that 'struct B' is just a C-Style struct
> label and does not actally declare a type A::B?
 
By a brief examination of the relevant sections of the Standard I
couldn't divine whether an elaborate type specifier in a member
declaration would declare the type as a member of the class in which
such a declaration appears or as a member of the namespace... I am
guessing that the compiler implementers had similar difficulty and
decided that a type declaration in a member declaration creates a name
that is injected in the namespace scope (like a friend declaration would
do, for instance).
 
V
--
I do not respond to top-posted replies, please don't ask
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 01 07:01AM -0700

On Wednesday, October 1, 2014 5:32:17 AM UTC-4, Chairman Mao wrote:
> A a;
> f(*a.p);
> }
 
Because struct B is not referenced by member anywhere, it is ignored
because it does not break the code anywhere. If you try to do something
with b in f(), or with a.p->..., then it will give you an error.
 
The only impact "struct B* p" will have in this is that it will occupy
4 bytes in the struct A allocation.
 
Best regards,
Rick C. Hodgin
Chairman Mao <maotse30million@gmail.com>: Oct 01 07:16AM -0700

On Wednesday, October 1, 2014 10:30:24 AM UTC-3, Victor Bazarov wrote:
 
> V
 
> --
 
> I do not respond to top-posted replies, please don't ask
 
I think that's the answer. But when you say "the compiler implementers had similar difficulty" what are you talking about here? In other word, what would be the problem had the type, i.e., the elaborated-type-specifier been defined as a member of the class, instead of in the surrounding namespace?
Chairman Mao <maotse30million@gmail.com>: Oct 01 07:22AM -0700

On Wednesday, October 1, 2014 11:17:09 AM UTC-3, Chairman Mao wrote:
Victor Bazarov <v.bazarov@comcast.invalid>: Oct 01 10:55AM -0400

On 10/1/2014 10:16 AM, Chairman Mao wrote:
 
>> I do not respond to top-posted replies, please don't ask
 
> I think that's the answer. But when you say "the compiler
> implementers had similar difficulty" what are you talking about here?
 
I meant the difficulty understanding the requirements of the Standard.
 
> In other word, what would be the problem had the type, i.e., the
> elaborated-type-specifier been defined as a member of the class,
> instead of in the surrounding namespace?
 
If the compiler were required to inject the name 'B' into the scope of
the class where it was first encountered, then the declaration of the
argument of the function 'f' would contain an unknown symbol 'B', making
your code ill-formed.
 
V
--
I do not respond to top-posted replies, please don't ask
Paavo Helde <myfirstname@osa.pri.ee>: Oct 01 11:22AM -0500

Chairman Mao <maotse30million@gmail.com> wrote in
> {
> struct B* p;
> };
 
This code also compiles in C, which has two consequences:
 
1. The code must compile in C++, for C compatibility.
 
2. Struct B cannot be A::B, because C does not have such a concept.
 
Thus, p here is bound to define a pointer to a top-level struct B. Probably
this is specified in some obscure back-alley in the standard.
 
Cheers
Paavo
peter koch <peter.koch.larsen@gmail.com>: Oct 01 03:26AM -0700

Den mandag den 29. september 2014 11.33.35 UTC+2 skrev Jorgen Grahn:
> AFAICT both MikeCopeland or Andreas Dehmel make the same assumption?
> I admit that I didn't read the full thread.
 
> /Jorgen
 
Well, I just reread Mike Copelands original post and I see that there was no mention of pointers, so I do not know how that idea got stuck in my head. Perhaps because Mike wrote something like "delete object from a vector"?
Sorry about the noise.
 
/Peter
Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 01 11:21AM

On Wed, 2014-10-01, peter koch wrote:
> so I do not know how that idea got stuck in my head.
> Perhaps because Mike wrote something like "delete object from a vector"?
> Sorry about the noise.
 
If it was noise, it was of a useful kind. Never hurts to remind
people what std::remove_if() does and doesn't do!
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Geoff <geoff@invalid.invalid>: Sep 30 07:48PM -0700

On Tue, 30 Sep 2014 12:27:31 +0000 (UTC), drew@furrfu.invalid (Drew
Lawson) wrote:
 
 
>Somewhat, this is for legal convenience. How do you prove that
>your project was done on your home computer, rather than on the
>company's dime?
 
Quite simply, the evidence of the work will be on your personal
computer and not on the company computer. In case law, the burden of
proof is on the plaintiff, not the respondent. They can, of course,
use an army of lawyers to intimidate the respondent and attempt to
bankrupt him but if they don't prevail, the counter-suit would make
the former employee very rich indeed.
 
If a company claims ownership of intellectual property they must prove
they paid for it to be done, it was assigned to you to be done, it was
done on their equipment or on their premises or on company time. If
they fail to prove one or more of those elements then they don't own
the work.
 
Blanket, "we own everything that exists or may exist in your head or
was made by your hands for all time and times to come" clauses are
simply not enforceable and this has been adjudicated in the U.S.
several times.
 
Additionally, non-competition clauses are illegal and unenforceable in
California and some other jurisdictions. A non-key employee is
perfectly safe _independently_ developing his own IP on his own time
using non-company tools and resources in his basement and starting his
own business. That's the whole point of free enterprise, isn't it?
Stuart <DerTopper@web.de>: Oct 01 08:09AM +0200

On 9/30/2014, Stuart wrote:
>> rates that are offered in most freelancer websites, I'd say that
>> McDonalds employees are only slighly less paid.
> SNIP
 
 
On 09/30/14, Christopher Pisz:
> everything you do. i.e No, you cannot create a video game on your own
> while working for a game studio. You can however invent the best flap
> jack recipe.
 
 
I'm totally fine with an intellectual property clause. It was the claim
on everything that bothered me (like Osmium's friend, who was not even
allowed to publish a novel that he wrote in his spare time). If my boss
forbade me to make contributions to Open Transport Tycoon I'd be
seriously mad ;-)
 
 
> know the details of how that works, only that it results in a
> maintenance nightmare. Perhaps that's what you are referring to when you
> compare salaries.
 
I was referring to the salaries offered on the free-lancers websites.
Most job offers boil down to 1$/hr, which is probably the average salary
in India.
 
> around $80,000 and seniors typically make $100,000+ last I checked. It
> varies with your niche and city though.
 
> Are Europeans making less? Their money is worth more, so perhaps. I dunno.
 
I can only tell about the German rates, which are 30K € for a beginner
and 40K € to 60K € for senior programmers (this applies to the former
Eastern Germany, you'll probably get a 1.3 to 1.5 higher salary in the
Western part of Germany). Apparently that is a lot less than what
American software engineers are getting, which is probably the reason
why Germany has very little to offer with regard to software products
(except for SAP, I guess).
 
Thanks for your numbers,
Stuart
David Brown <david.brown@hesbynett.no>: Oct 01 09:48AM +0200

On 30/09/14 22:14, Stuart wrote:
> closer and closer to the status of a McDonald employee. If I look at the
> rates that are offered in most freelancer websites, I'd say that
> McDonalds employees are only slighly less paid.
 
It is not just an "American" thing - it is common world-wide for an
employer to have rights to related things you do outside work. But
there will be significant differences in defining "related" here. In
Europe, "related" might mean "any sort of programming" - while in
America it could easily mean "anything making money". There will also
be significant differences in the attitudes taken by companies in
enforcing such policies and contracts. In Europe, companies are allowed
to take ethics and common sense into account, and they are allowed to
consider the rights and feelings of their employees. In America,
publicly traded companies are primarily responsible to their
shareholders - their main legal obligation is to maximise profits, and
everything else is secondary. So if you write a best-seller in your
freetime, and the company thinks they could claim the rights to it, then
they have no legal choice but to try to take it off you.
 
Also, employers the world over have a right and a duty to protect their
reputation, and that can place restrictions on what you do and how you
act outside work hours. Rules for that sort of thing, and how they are
enforced, will vary between the USA and Europe (and between countries in
Europe). If you - as a male programmer - like to go clubbing wearing
drag and fishnet tights in the weekends, you will quickly find yourself
out of a job in most of the USA - while in northern Europe no one would
bat an eyelid.
Stuart <DerTopper@web.de>: Oct 01 10:52AM +0200

On 09/30/14, Osmium wrote:
>>> those constraints in the USA are real close to zero. Unless you are Very
>>> Special the company is not going to be willing to even enter negotiations
>>> with you regarding the basics. It also displays an "attitude".
 
On 30/09/14, Stuart wrote:
>> closer and closer to the status of a McDonald employee. If I look at the
>> rates that are offered in most freelancer websites, I'd say that
>> McDonalds employees are only slighly less paid.
 
 
On 10/01/14, David Brown wrote:
> there will be significant differences in defining "related" here. In
> Europe, "related" might mean "any sort of programming" - while in
> America it could easily mean "anything making money".
 
In Germany this would be "anything that is related to the companies line
of work". So writing novels in your spare time is OK (as long as it does
not interfere with your work performance), and programming in a totally
different field is also OK (hobby programmer that wants to improve Open
Transport Tycoon). If you want to make money in your spare time, you
have to get a permission from your employer, but if your employee denies
you a permission he must state a good reason for this.
 
> There will also
> be significant differences in the attitudes taken by companies in
> enforcing such policies and contracts. In Europe, companies are allowed
 
Make that "allowed and required".
 
> everything else is secondary. So if you write a best-seller in your
> freetime, and the company thinks they could claim the rights to it, then
> they have no legal choice but to try to take it off you.
 
I doubt that. I think that Geoff's posting else-thread contains a more
concise description of how things are done in America. After all,
America defines itself as the country that gives the most freedom to
everyone, and right now I cannot see any country in the world (not even
Germany) that comes closer to this dream than America. Of course, some
companies might think that this means that they can force any contracts
on their employees, but apparently the US jurisdiction thinks otherwise.
 
> drag and fishnet tights in the weekends, you will quickly find yourself
> out of a job in most of the USA - while in northern Europe no one would
> bat an eyelid.
 
That's sad to hear. I think America has come a long way (a black
President would have been unthinkable in the 50's), but in some regards
they still have a long way ahead. In some parts they are even ahead of
Germany: if I understand it right, employers are not allowed to see the
name or the photo of the job applicant. That would be unthinkable here
in Germany.
 
Regards,
Stuart
woodbrian77@gmail.com: Sep 30 06:39PM -0700

On Tuesday, September 30, 2014 4:29:26 PM UTC-5, Öö Tiib wrote:
> library named "libuv" (part of "node.js" but may be used separately)
> that is somewhat similar to boost.asio and that people use for
> networking quite finely.
 
I have some code in my library that's similar to the asio
library. I hope to keep developing this code.
 
It shouldn't be too hard to make C++ Middleware Writer
code work with asio, but I haven't ever tried it.
 
My approach is kind of similar to libuv except that I've
used C++.
 
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
woodbrian77@gmail.com: Sep 30 07:06PM -0700

On Tuesday, September 30, 2014 12:33:56 PM UTC-5, Mr Flibble wrote:
> not serialization.
 
> Rule of thumb for modern software development: as much as your code as
> possible should be portable
 
I have two things: a library, and a 3-tier system.
Each of the tiers links with the library. The back
tier isn't meant to be very portable. Currently
it's running on BSD. The middle tier is portable
to a number of platforms, and the front tier, which
is the smallest, is meant to be very portable. The
library, front tier and generated code are meant to
be highly portable, and I believe they are.
 
 
Brian
Ebenezer Enterprises - So far G-d has helped us.
http://webEbenezer.net
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.

No comments: