Friday, January 25, 2019

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

woodbrian77@gmail.com: Jan 25 10:38AM -0800

Shalom
 
Are you using C++ in a pioneering way? Would you
like help with your project? I have an offer:
http://webEbenezer.net/about.html
 
to help someone who is willing to use this software:
https://github.com/Ebenezer-group/onwards
 
as part of their project.
 
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
JiiPee <no@notvalid.com>: Jan 25 05:27PM

In this example I am animating movements to 4 directions.
 
First the code:
 
// handles one animation:
 
struct Animation
{
    Animation(const std::string& textureFileName) :
        m_textureFileName{ textureFileName }
    {}
    // stuff for animation
    // ...
private:
    std::string m_textureFileName;
};
 
// contains all animations for the player
class PlayerAnimate
{
    void addAnimation(const std::string& textureFileName) {
        m_animation.emplace_back(textureFileName);
    }
    Animation& getAnimation(int index) {
        return m_animation[index];
    }
private:
    std::vector<Animation> m_animation;
};
 
int program()
{
    // first add all animations:
    PlayerAnimate playerAnimation;
    playerAnimation.addAnimation("WalkingLeft.png");
    playerAnimation.addAnimation("WalkingRight.png");
    playerAnimation.addAnimation("WalkingUp.png");
    playerAnimation.addAnimation("WalkingDown.png");
 
    // other code...
    // ...
    // then after, maybe in another function we want to animate right-
    // movement:
    Animation& animationRight = playerAnimation.getAnimation(1);
    draw(animationRight); // do the drawing
}
 
But I would like to make the call using an enum something like:
    Animation & animationRight =
playerAnimation.getAnimation(Direction::Right);
 
The problem is that it's not really good to put that enum in
PlayerAnimate (or Animation) class/file
because this class is a re-usable class and animation Direction is not
something
which is general and re-usable (I do not want to pollute PlayerAnimate
with Direction
because its not something all future usage of it needs.. maybe in the
next program direction
is not needed...).
 
Because here Direction is only a name for the animation. Many in next
animation I need "Jump"-type.. and so on.
 
I could use template:
 
template<typename AnimateType>
class PlayerAnimate
{
    void addAnimation(const std::string& textureFileName, AnimateType
type) {
        m_animation.emplace_back(textureFileName, type);
    }
};
 
(and store that type into the Animation class, or map it somehow to
indexes in PlayerAnimate) and then call like this:
 
enum class Direction {Right};
PlayerAnimate<Direction> playerAnimation;
Animation& animationRight = playerAnimation.getAnimation(Direction::Right);
 
But that makes it quite "heavy" because then other classes who use
PlayerAnimate
(there are couple of other classes using it) they would also then be
changed to
template classes (I think?).
 
So how to do this so that I don't need to put that enum class Direction in
PlayerAnimate or Animation class?
Do I need to create some kind of polymorhism pointer and then inherit a
class which
contains  my enum class Direction? Was a little thinking about that.
 
I could have the type as a std::string, and then it would always work,
but prefer using
 
enums rather than strings....
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 25 05:44PM

On 25/01/2019 17:27, JiiPee wrote:
 
> I could have the type as a std::string, and then it would always work, but
> prefer using
 
> enums rather than strings....
 
No need to use either.
 
Use a vector (mathematical not std::vector) of arity 2 (assuming 2D not
3D) to represent velocity and map the vector's direction to an animation.
The vector will also allow you to update position too.
 
/Flibble
 
--
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who
doesn't believe in any God the most. Oh, no..wait.. that never happens." –
Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 25 12:06AM

On Thu, 24 Jan 2019 15:21:28 -0800 (PST)
> which is dated 1997, so his contributions in JAVA came before that,
> and we're talking about some of the reasons programming moved from
> C++ to JAVA in the 1990's ...
 
You may be right, but I doubt that that was such a big issue at the
time. C and C++ programmers had Butenhof's (also 1997) book Programming
with POSIX threads (which have formed the basis of C11 and C++11
threads), and Windows threads were sort-of getting established by then
also.
 
As far as concerns the future, Oracle seem to be ceding anything
desktop related to C# with their ejection of JavaFX from the JDK (which
I think is a shame) and the soon to be ejected Swing/AWT. It looks as
if they are concentrating on the enterprise with a view to getting out
of Java what they can while they can.
 
None of this alters that java is a horrible language to program in IMO
(encapsulating the worst of the 1990s in my opinion), and that you
appear to like it. À chacun son goût. There are in my view much
better languages for the JVM.
Cholo Lennon <chololennon@hotmail.com>: Jan 24 09:58PM -0300

On 1/24/19 1:54 PM, Bonita Montero wrote:
>>> Java-code.
 
>> Wow... how about you? show us your Java credentials please.
 
> I'm using Java on HPC-systems since the beginning of the first JIT-VM.
 
So... Bonita, you are Jux und Tollerei (?) :-O
 
P.S. It is not rocket science to write performant code in Java.
 
--
Cholo Lennon
Bs.As.
ARG
Cholo Lennon <chololennon@hotmail.com>: Jan 24 10:15PM -0300

On 1/24/19 4:11 PM, Chris Vine wrote:
 
> Java is a horrible language to write code in. It's like being locked
> in an Austin Powers movie, with its massive inheritance heirarchies and
> 1990's style OO.
 
I don't know what kind of code base you worked on, but it's not my case
(contention, IoC, generics, etc it's the way to go with Java, no massive
inheritance hierarchies). I really enjoy writing code in both, Java and
C++, especially Java 8 or later and C++ 17.
 
And... you can say the same of C++ if you have the bad luck to work
with, for example, MFC related code (just for citing one of many old
school libraries still in use nowadays)
 
To sum-up: Don't blame the languages... blame the bad programmers who
use them.
 
 
--
Cholo Lennon
Bs.As.
ARG
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 24 09:16PM

On Thu, 24 Jan 2019 12:43:37 -0800 (PST)
> software once written in C++, including financial trading systems and
> computationally intensive risk systems, moved to JAVA, and later C#. There
> were reasons for this. Do you understand why?
 
It looks as if you do, but that was not my point.
 
On your (not my) point, garbage collection and automatic memory
management probably had a lot to do with. Not everyone wants the
fastest code; fast enough with memory safety may be ... enough[1]. As
far as being a horrible language is concerned, Java is a product of its
time and the OOP craze, which it has locked itself into in a way which
C++ has not needed to. And you don't have to write java code to use the
JVM.
 
What's your version of an answer to your question?
 
Anyway the future of java and those using it will be determined by
Oracle, who have decided that they will monetize java through the
GPL2+CE. We will see how that goes for them.
 
[1] Rust with its linear/affine type system has obtained memory safety
without garbage collection. In practice C++ has largely ameliorated
memory management issues if you stick to the correct C++ (as opposed to
C) idioms for writing good code.
Daniel <danielaparker@gmail.com>: Jan 24 09:17PM -0800

On Thursday, January 24, 2019 at 6:05:37 PM UTC-5, Mr Flibble wrote:
 
> It isn't standalone; it is part of my C++ utility library "neolib":
 
> https://github.com/i42output/neolib/blob/master/include/neolib/json.hpp
 
If I could offer a few comments.
 
You write very nice code, which would benefit from having more users. To
that end, I would suggest
 
(1) Pick a standard licensing agreement, such as boost or MIT. People will
feel more comfortable with that. You should have a subset of your work that
you're willing to license that way.
 
(2) It looks like you're developing primarily with vs. I do to, but from the
beginning most of my users were on linux or OSX or Android, and using gnu
and clang. I think your project would benefit a lot if you could set up
travis builds for the different environments, so you could claim support
for more environments.
 
(3) A lot of people won't use an open source project if it has a dependency
on boost. If you could at least have a subset of your work with no
dependencies, perhaps a part including your json work, I think more
people would try it out.
 
(4) Perhaps before setting up travis builds, set up appveyor builds for
the various configurations of visual studio.
 
(5) When you're ready, announce it on reddit rather than (or in addition to)
here, I believe you'll find a more receptive audience there.
 
Just my thoughts,
Daniel
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 25 07:12AM

On Thu, 2019-01-24, Thiago Adams wrote:
...
> members. This implies that structures may not be assigned to or
> copied as a unit, and that they can not be passed to or returned
> from functions. (These restrictions will be removed in forthcoming
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> "
 
> In other words struct had to be passed as pointer and it was the only
> way.
 
The way I read the quote, even back then (the 1970s) the authors
didn't think this was a good thing.
 
But yes, I'm aware that a lot of C programmers rarely pass structs by
value.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
"Öö Tiib" <ootiib@hot.ee>: Jan 25 12:29AM -0800

On Thursday, 24 January 2019 17:57:16 UTC+2, Jux und Tollerei wrote:
> > but it is not speed.
 
> You're wrong because you're not skilled enough to write performant
> Java-code.
 
Non sequitur. You argument was about physics not Java. This universe
is certainly not written in Java. :D
I don't need to have all skills myself. There are about 30 senior or
expert level Java programmers in mine company.
"Öö Tiib" <ootiib@hot.ee>: Jan 25 01:17AM -0800

> > C++ and that is paid with inefficiency. So it has benefits,
> > but it is not speed.
 
> I disagree with your assertion that Java is simpler than C++ to use. C++ is more complex than Java sure but it doesn't follow that that makes Java easier to use: the complexity of the C++ language and library implementation actually pulls complexity out of the C++ programs you write. The simplest programming language of all is arguably assembly but try writing anything non-trivial in assembly.
 
I was talking about average programmers.
For less advanced programmers everything in C++ is with
bear traps attached. Java and C++ standard libraries are
not comparable with straight face.
 
Need to use tools for detecting misusages and variety
of third party libraries is making development quite
complex and complicated for average programmer.
 
C++ is quite advanced/expert friendly language. Experts
know tools, operating systems and libraries and avoid
undefined behaviors by habit. For them it is easy.
"Öö Tiib" <ootiib@hot.ee>: Jan 25 03:18AM -0800

On Thursday, 24 January 2019 18:43:12 UTC+2, Daniel wrote:
> and C library functions for string/number conversions and supplying their own
> (as RapidJson does), can only get close to the Java implementations, but that
> C++ can provide opportunities for new and faster techniques :-)
 
I first saw it from microsoft.
https://www.microsoft.com/en-us/research/wp-content/uploads/2017/05/mison-vldb17.pdf
 
It felt odd. Data transfer has two sides: one who produces and other who
consumes. Therefore I usually look at round-trip tests first when considering
data transfer formats/libraries. The paper seemingly wrote only about parsing.
 
In my experience JSON should be used for transferring tiny amounts of data.
When vast majority of messages are under 1476 bytes of JSON then it is
doing good in competition since compressing those further gives nothing in
ethernet and readability is definite advantage.
The article authors did concentrate more on large blobs of JSON.
 
GB/s parsing of large blobs is odd measurement. One who has
GBs of data and transfers it as JSON is order of magnitude slower than
competitors who use more suitable formats for such a task, also people
can't read such walls of text anyway. So parsing is only fraction of issue
in it; majority of time goes to data transfer over whatever media there
and special tools are needed for humans to orient in it on any case.
 
Other important aspects are correctness and reliability. Correctness is tricky
since vanilla C++ does not contain support for UTF and full precision numbers.
Again I did not see any indications how correct their Mison was in article nor
anything about reliability.
 
So ... I sort of dismissed the study, it felt interesting in sense of insightful but
I would not use their test results to conclude anything about anything, since
those seemed to o far from perspective of practicality. ;-)
 
 
 
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 25 01:41PM

On 25/01/2019 05:17, Daniel wrote:
 
> (1) Pick a standard licensing agreement, such as boost or MIT. People will
> feel more comfortable with that. You should have a subset of your work that
> you're willing to license that way.
 
What's wrong with BSD Licence?
 
> and clang. I think your project would benefit a lot if you could set up
> travis builds for the different environments, so you could claim support
> for more environments.
 
Other OS support will come when I make the library CMakeable; it is
already cross platform and I do build parts of it on Linux.
 
> on boost. If you could at least have a subset of your work with no
> dependencies, perhaps a part including your json work, I think more
> people would try it out.
 
I do not support people who do not want a dependency on Boost.
 
 
> (4) Perhaps before setting up travis builds, set up appveyor builds for
> the various configurations of visual studio.
 
No idea what you are talking about there but I suspect it is something I
am not interested in given I am moving to CMake.
 
 
> (5) When you're ready, announce it on reddit rather than (or in addition to)
> here, I believe you'll find a more receptive audience there.
 
I already make announcements as and when required.
 
 
> Just my thoughts,
> Daniel
 
Thanks for the input.
 
/Flibble
 
--
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who
doesn't believe in any God the most. Oh, no..wait.. that never happens." –
Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
Daniel <danielaparker@gmail.com>: Jan 25 06:18AM -0800

On Friday, January 25, 2019 at 6:18:17 AM UTC-5, Öö Tiib wrote:
> doing good in competition since compressing those further gives nothing in
> ethernet and readability is definite advantage.
> The article authors did concentrate more on large blobs of JSON.
 
In the financial industry, massive amounts of XML for every trade on the
book are transferred everyday, including from New York to/from London.
Sure there would be more efficient techniques, but the tooling can handle
it and nobody cares. I think you would also see very large JSON files.
In the case of JSON there is very easy decode from/encode to JSON-like
binary formats such as CBOR, but I think you'd still see a lot of JSON on
the wire.
 
> competitors who use more suitable formats for such a task, also people
> can't read such walls of text anyway. So parsing is only fraction of issue
> in it
 
Of course, but it's a research project that's focussed on parsing, exploiting data parallelism while parsing text, which I think is
interesting.
 
> Other important aspects are correctness and reliability.
 
There are of course popular test suites that projects use for testing correctness, including https://github.com/nst/JSONTestSuite and http://www.json.org/JSON_checker/, but I think mison is just narrowly
focused on parsing research, to make its contribution.
 
Daniel
scott@slp53.sl.home (Scott Lurndal): Jan 25 02:24PM

>that's true of most people.
 
>But if you want one...
 
><https://en.wikipedia.org/wiki/List_of_C%2B%2B_multiple_precision_arithmetic_libraries>
 
Indeed. I've used libgmp in a couple of projects that require big numbers. Works
just fine.
Daniel <danielaparker@gmail.com>: Jan 25 06:41AM -0800

On Friday, January 25, 2019 at 8:41:22 AM UTC-5, Mr Flibble wrote:
 
> What's wrong with BSD Licence?
 
Nothing's wrong with the BSD License, if that's what you want to use. But
it's hard to tell that's what you're using, because the text "BSD" doesn't
appear in your copyright notice. I think you should follow the format from (BSD 2-Clause)
 
https://choosealicense.com/licenses/bsd-2-clause/
 
or (BSD 3-Clause)
 
https://choosealicense.com/licenses/bsd-3-clause/
 
and then github would probably pick up the text "BSD 3-Clause" or "BSD 2-
Clause" and tag that on your site.
 
> > the various configurations of visual studio.
 
> No idea what you are talking about there but I suspect it is something I
> am not interested in given I am moving to CMake.
 
appveyor supports integration builds for vs and all projects I follow use it
in addition to travis. Appveyor will use the same CMake files as your travis
builds.
 
Daniel
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 25 02:52PM

On 25/01/2019 14:41, Daniel wrote:
 
> https://choosealicense.com/licenses/bsd-3-clause/
 
> and then github would probably pick up the text "BSD 3-Clause" or "BSD 2-
> Clause" and tag that on your site.
 
I copied the licence text from Wikipedia not some random website.
 
[snip]
 
/Flibble
 
--
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who
doesn't believe in any God the most. Oh, no..wait.. that never happens." –
Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
Daniel <danielaparker@gmail.com>: Jan 25 06:57AM -0800

On Friday, January 25, 2019 at 9:24:26 AM UTC-5, Scott Lurndal wrote:

 
> I've used libgmp in a couple of projects that require big numbers. Works
> just fine.
 
Given all the prior experience, I think it's a shame things like big number
and date/time didn't make it into the standard. It's inhibited the
development of good C++ API's to data resources. C++ lost a lot of
ground to other languages, and I don't think it will ever get it back.
 
Best regards,
Daniel
Daniel <danielaparker@gmail.com>: Jan 25 07:09AM -0800

On Friday, January 25, 2019 at 9:52:25 AM UTC-5, Mr Flibble wrote:
 
> I copied the licence text from Wikipedia not some random website.
 
Not so random, those are github links. If you use the format as shown in those
templates, github will tag the license on your site, so people will see that
it's BSD 2-Clause or BSD 3-Clause.
 
Best regards,
Daniel
"Öö Tiib" <ootiib@hot.ee>: Jan 25 07:15AM -0800

On Friday, 25 January 2019 16:18:53 UTC+2, Daniel wrote:
> > The article authors did concentrate more on large blobs of JSON.
 
> In the financial industry, massive amounts of XML for every trade on the
> book are transferred everyday, including from New York to/from London.
 
With that kind of information the focus is ultimately on correctness and
accuracy.
 
> In the case of JSON there is very easy decode from/encode to JSON-like
> binary formats such as CBOR, but I think you'd still see a lot of JSON on
> the wire.
 
Note that 30 times less efficient is efficient enough on lot of cases.
Lot of programs are written in Python or PHP.
 
Parsing takes fraction of time there and so one could happily use
nlohmann instead of rapidJSON that is about 4 times slower but
its interface and functionality is somewhat more sophisticated and
easier to read.
 
> > in it
 
> Of course, but it's a research project that's focussed on parsing, exploiting
> data parallelism while parsing text, which I think is interesting.
 
I also think that it is interesting but the clearly skewed focus made
it likely that also the tests were skewed and so the impact
is unknown from perspective of usefulness in practice (that I am
mostly interested in).
 
 
> > Other important aspects are correctness and reliability.
 
> There are of course popular test suites that projects use for testing correctness, including https://github.com/nst/JSONTestSuite and http://www.json.org/JSON_checker/, but I think mison is just narrowly
> focused on parsing research, to make its contribution.
 
Indeed. I suspect that it even accepts malformed JSON
messages.
scott@slp53.sl.home (Scott Lurndal): Jan 25 04:48PM

>and date/time didn't make it into the standard. It's inhibited the
>development of good C++ API's to data resources. C++ lost a lot of
>ground to other languages, and I don't think it will ever get it back.
 
I don't understand. I've used GMP in C++ for years.
 
And, for that matter, it's not a contest. Use whatever language floats
your boat.
Daniel <danielaparker@gmail.com>: Jan 25 08:57AM -0800

On Friday, January 25, 2019 at 11:48:51 AM UTC-5, Scott Lurndal wrote:
 
 
> I don't understand. I've used GMP in C++ for years.
 
Clearly :-) And vice versa. Your second sentence is irrelevant to my point.
But it is not important.
 
Best regards,
Daniel
Jux und Tollerei <Jux.und.Tollerei@gmail.com>: Jan 25 06:17PM +0100

> number and date/time didn't make it into the standard. It's inhibited
> the development of good C++ API's to data resources. C++ lost a lot of
> ground to other languages, and I don't think it will ever get it back.
 
While the C++-commmittee is debating about slight language-changes for
the next C++-release for years Java gets hundreds of new useful APIs
from release to release.
scott@slp53.sl.home (Scott Lurndal): Jan 25 05:30PM


>> I don't understand. I've used GMP in C++ for years.
 
>Clearly :-) And vice versa. Your second sentence is irrelevant to my point.
>But it is not important.
 
The point is that there is already a portable api for big
numbers available for C++, which is, after all, a superset of C.
 
I'd rather have a choice of API's rather than be forced to use
some syntactic sugar added to the language definition, which is
already become too complicated, and is getting worse with the
future addition of introspection capabilities.
"Chris M. Thomasson " <ahh_f_it@crap.nothing>: Jan 24 06:34PM -0800

On 1/24/2019 9:15 AM, Juha Nieminen wrote:
 
> I just want to make sure: Is it ok to use std::thread and the
> other multithreading standard utilities in the constructors of
> these objects?
 
Just be careful. I have seen nightmares where people create a thread in
the ctor, that calls a member of the object currently being constructed!
The damn thread calls the member _before_ the object is fully
constructed. This IS BADDDDD! I have had nightmares about fixing some
others code before.
 
 
 
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)