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. |
- Announcement of new C++11 library to handle measures - 4 Updates
- I don't understand how this code compiles. - 13 Updates
- Deleting std::vector Item(s) - 2 Updates
- Is it OK to OCCASIONALLY submit C++ code for comments in this group, like RFC? - 4 Updates
- Onwards and upwards - 2 Updates
"Öö 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:
Post a Comment