- Looking for C++ large data learning application - 2 Updates
- "Current Proposals for C++17" - 3 Updates
- send email and socket programming - 6 Updates
- do shared_ptrs to resized vector remain valid? - 6 Updates
- Union of bitfields and larger type on ARM - 3 Updates
- asserts considered harmful - 2 Updates
- Statistics about C++ - 3 Updates
| Haddock <ffm2002@web.de>: Feb 26 02:19AM -0800 Hello, I'm a long time Java developer who long time ago in his master's thesis once wrote some application in C++. Now I got a Java job for a company that develops software for regulatory reporting for banks which involves processing large amounts of data and storing it. I saw that many banks that look for developers for their department that does regulatory reporting are looking for people with Java >and< C++ skills. So I thought this regulatory reporting stuff is some interesting domain to be in and I want to revive my C++ skills to have good job options in the future. So I'm looking for some learning application to work on that deals with processing large amounts of data and wanted to ask whether anybody out there working in this domain could give me a hint what to work on to get more into C++. What I thought of was writing a parser to parse CSV files or XML. Write something that generates optimized C++ code to parse something. But I'm not sure whether that's something good. Any ideas greatly appreciated. Regards, Haddock |
| woodbrian77@gmail.com: Feb 26 03:27PM -0800 On Friday, February 26, 2016 at 4:20:00 AM UTC-6, Haddock wrote: > Hello, > I'm a long time Java developer who long time ago in his master's thesis once wrote some application in C++. Now I got a Java job for a company that develops software for regulatory reporting for banks which involves processing large amounts of data and storing it. I saw that many banks that look for developers for their department that does regulatory reporting are looking for people with Java >and< C++ skills. > So I thought this regulatory reporting stuff is some interesting domain to be in and I want to revive my C++ skills to have good job options in the future. So I'm looking for some learning application to work on that deals with processing large amounts of data and wanted to ask whether anybody out there working in this domain could give me a hint what to work on to get more into C++. What I thought of was writing a parser to parse CSV files or XML. Write something that generates optimized C++ code to parse something. But I'm not sure whether that's something good. Any ideas greatly appreciated. Here's some software that I've been working on - http://webEbenezer.net/build_integration.html . There's a library and a couple of executables there. It uses some of the newer features of C++. The software has to do with serialization and messages. The company behind the software is small: https://thebountifulreaper.wordpress.com/2013/01/20/1-kings-1841-46-a-cloud-the-size-of-a-mans-hand/ , but we have a generous offer to help someone who is willing to use the software: http://webEbenezer.net/about.html . And yes, you can refer yourself for that offer and get both a coworker and some money. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
| Lynn McGuire <lmc@winsim.com>: Feb 26 04:40PM -0600 "Current Proposals for C++17" https://meetingcpp.com/index.php/br/items/current-proposals-for-c17.html "There is a new batch of proposals for C++17, published for next weeks ISO C++ Committee meeting in Jacksonville, Florida. With way over 100 proposals, and limited time, I will try to cover in this posting only papers which have C++17 in their title, which gives a fairly random selection with a few highlights. A first overview gives you my listing by c++ committee subgroups or the original ISO listing at open-std.org. Currently C++17 is still in the making, each committee meeting will set new trends and add features likely to the standard. But lets have a look at some of the proposals. I'll go by the order of my subgroup listing." A detailed list of proposals by paper is at: http://meetingcpp.com/index.php/id-2016-proposals-by-mailing-and-subgroup.html There is a standard 2D graphical library proposal at: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0267r0.pdf There is not a standard user interface toolkit proposal. Bummer. Lynn |
| Victor Bazarov <v.bazarov@comcast.invalid>: Feb 26 05:51PM -0500 On 2/26/2016 5:40 PM, Lynn McGuire wrote: > [...] > There is not a standard user interface toolkit proposal. > Bummer. What?!! You mean *yours* was discarded? Outrageous! V -- I do not respond to top-posted replies, please don't ask |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 26 11:21PM On 26/02/2016 22:40, Lynn McGuire wrote: > There is not a standard user interface toolkit proposal. There never will be one either as nobody will be able to agree on what one should look like. /Flibble |
| alexo <alelvb@inwind.it>: Feb 26 04:09AM +0100 > I've written for UNIX a little program [FLTK] that needs to send an > order through e-mail. As JiiPee suggested, I've found a very powerful library named curl. The one he suggested, mimetic, has a bug. I'm an absolute beginner on the field but adapting the example code, I was able to send with curl my first email from a C/C++ program. When I insert the code in my program the data transmission seems not going to an end. I use it inside a wrapper function that is called-back pressing a FLTK button. The specific failing function is curl_easy_perform() that correctly works on the toy test program. any help? thank you |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 26 07:49AM +0200 On 26.02.2016 5:09, alexo wrote: >> order through e-mail. > As JiiPee suggested, I've found a very powerful library named curl. > The one he suggested, mimetic, has a bug. Namely? > pressing a FLTK button. > The specific failing function is curl_easy_perform() that correctly > works on the toy test program. Most likely there is a bug in your program. |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 26 08:39AM +0200 On 26.02.2016 7:49, Paavo Helde wrote: >> The specific failing function is curl_easy_perform() that correctly >> works on the toy test program. > Most likely there is a bug in your program. Or alternatively, some firewall is blocking your communication attempts. |
| alexo <alelvb@inwind.it>: Feb 26 01:15PM +0100 >> Most likely there is a bug in your program. > Or alternatively, some firewall is blocking your communication attempts. The firewall seems out of discussion because the toy code sends the emails, while the same code cut and pasted in my program does not. When I press the "send" button of my program the button remains in the pushed status and wireless connection starts an endless transmission of data. |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 26 02:40PM +0200 On 26.02.2016 14:15, alexo wrote: > The firewall seems out of discussion because the toy > code sends the emails, while the same code cut and pasted in my program > does not. Well then it is simple, there is a bug in your non-toy program. My crystal ball tells me the bug is on line 247. |
| Christopher Pisz <nospam@notanaddress.com>: Feb 26 04:41PM -0600 On 2/26/2016 6:40 AM, Paavo Helde wrote: >> does not. > Well then it is simple, there is a bug in your non-toy program. My > crystal ball tells me the bug is on line 247. People are trying to tell you to use your debugger and find the source of the problem, try to deduce the cause, and then reproduce a simple minimal example that demonstrates it. Only then can you expect useful suggestions from others. Have you made attempts at debugging? Where does it fail? How does it fail? What's it doing at the time? -- I have chosen to troll filter/ignore all subthreads containing the words: "Rick C. Hodgins", "Flibble", and "Islam" So, I won't be able to see or respond to any such messages --- |
| jomarbueyes@hotmail.com: Feb 26 07:41AM -0800 Hi, I'm using a few shared pointers to a large vector that might be resized (pointers to the vector itself, not to individual elements). My question is: Do all the shared pointers still point to the vector after it is resized? Thus far, it seems that they do with g++ version 5.2.0. However, for portability I'd like to know what the standard says. Thank you in advance for any help, Jomar |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 26 06:18PM +0200 > Hi, > I'm using a few shared pointers to a large vector that might be resized (pointers to the vector itself, not to individual elements). My question is: Do all the shared pointers still point to the vector after it is resized? Thus far, it seems that they do with g++ version 5.2.0. However, for portability I'd like to know what the standard says. std::vector consists of the std::vector object itself and of a separate resizable buffer containing the elements. Once created, the std::vector object stays at the same location in memory (an object in C++ *is* an area of memory) until it is destroyed, so any smart or non-smart pointers to it remain valid during its lifetime. With the elements in the resizable buffer the things are different, their location can change during operations like resizing, so the pointers and references to the elements can become invalid - but you already know that. hth Paavo |
| legalize+jeeves@mail.xmission.com (Richard): Feb 26 04:56PM [Please do not mail me a copy of your followup] Paavo Helde <myfirstname@osa.pri.ee> spake the secret code >With the elements in the resizable buffer the things are different, >their location can change during operations like resizing, [...] I believe the standard guarantees that they remain in the same location if you resize the vector smaller. -- "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> |
| jomarbueyes@hotmail.com: Feb 26 09:00AM -0800 On Friday, February 26, 2016 at 11:18:42 AM UTC-5, Paavo Helde wrote: > already know that. > hth > Paavo Hi Paavo, Thank you very much for your response. It really helps. Thanks again, Jomar |
| jomarbueyes@hotmail.com: Feb 26 09:05AM -0800 On Friday, February 26, 2016 at 11:56:50 AM UTC-5, Richard wrote: > The Computer Graphics Museum <http://computergraphicsmuseum.org> > The Terminals Wiki <http://terminals.classiccmp.org> > Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> Hi Richard, Thank you very much for your response. My concern is mostly with growing a vector. Thank you again, Jomar |
| Juha Nieminen <nospam@thanks.invalid>: Feb 26 06:08PM > the vector after it is resized? Thus far, it seems that they do with > g++ version 5.2.0. However, for portability I'd like to know what > the standard says. Do you mean a vector of shared_ptr's, or a vector of objects (and then those separate shared_ptr's pointing to said objects)? In the latter case all pointers and iterators get invalidated if the vector is resized larger. (Although I think that if you reserved a larger size and then resize the vector to be at most that size, they probably don't get invalidated.) --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| David Brown <david.brown@hesbynett.no>: Feb 26 05:09PM +0100 On 25/02/16 19:05, Les Cargill wrote: >> } phase_accumulator; > If it doesn't, fix it. Endianness is more or less undefined behavior in > 'C' so you have to test it. No, endianness is not remotely "undefined behaviour" - it is /implementation/ defined behaviour. There is a huge difference. This means that the implementation has to document exactly what endianness is used - and in the case of ARM compilers for embedded systems, this is specified in the ARM EABI to be little endian. Being implementation-defined behaviour, this also means that you /can/ test it - sometimes that is easier than trying to find the relevant documentation! Once you have tested it, you know exactly how it works for that implementation. And while in theory it could change in later versions of the compiler, making such a change between compiler versions would be astoundingly stupid and unhelpful - especially in an embedded compiler - so it is not going to happen. (I know of only one case where this happened - and that was on MS's x86 compiler, a long time ago, where they changed the bitfield endianness.) If endianness (or bitfield endianness) really were undefined behaviour, you could not rely on it being the same between two runs of the same compiler on the same source code - testing would be useless. |
| scott@slp53.sl.home (Scott Lurndal): Feb 26 05:29PM >> 'C' so you have to test it. >No, endianness is not remotely "undefined behaviour" - it is >/implementation/ defined behaviour. There is a huge difference. We have software that is built for both big-endian and little-endian hosts (and more interestingly, it must internally simulate both big-endian and little-endian processors). We have this in one of the project header files. #include <endian.h> #ifndef __BYTE_ORDER #if defined(__BIG_ENDIAN) && !defined(__LITTLE_ENDIAN) #define __BYTE_ORDER __BIG_ENDIAN #elif !defined(__BIG_ENDIAN) && defined(__LITTLE_ENDIAN) #define __BYTE_ORDER __LITTLE_ENDIAN #define __BIG_ENDIAN 4321 #elif !defined(__BIG_ENDIAN) && !defined(__LITTLE_ENDIAN) #define __BIG_ENDIAN 4321 #define __BYTE_ORDER __BIG_ENDIAN #else #error Unable to determine Endian mode 
Subscribe to:
Post Comments (Atom)
|
No comments:
Post a Comment