Sunday, March 6, 2016

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

Juha Nieminen <nospam@thanks.invalid>: Mar 06 10:56PM

> {
> panic("pure virtual function called\n");
> }
 
What's wrong with pure virtual functions? They don't cause dynamic
memory allocation. (And why *pure* virtual functions only? They are
no different from normal virtual functions. The only difference
between them happens at compile time. At runtime there's no difference.)
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Ian Collins <ian-news@hotmail.com>: Mar 07 11:59AM +1300

On 03/07/16 11:56, Juha Nieminen wrote:
> memory allocation. (And why *pure* virtual functions only? They are
> no different from normal virtual functions. The only difference
> between them happens at compile time. At runtime there's no difference.)
 
Calling a pure virtual functions usually ends in tears...
 
--
Ian Collins
Juha Nieminen <nospam@thanks.invalid>: Mar 06 11:09PM

> Calling a pure virtual functions usually ends in tears...
 
Why? It's just a normal virtual function call.
 
Unless you mean circumvent somehow the compiler checks and call it
on an object of the base class type? You would really need to do it
deliberately, so you would be asking for it.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Ian Collins <ian-news@hotmail.com>: Mar 07 12:13PM +1300

On 03/07/16 12:09, Juha Nieminen wrote:
 
> Unless you mean circumvent somehow the compiler checks and call it
> on an object of the base class type? You would really need to do it
> deliberately, so you would be asking for it.
 
The usual route to tears is to accidentally call a virtual function in a
constructor.
 
--
Ian Collins
luser.droog@gmail.com: Mar 06 03:09AM -0800

I asked about this in comp.lang.c and the most useful response so
far was "use C++". So what would be the most idiomatic C++ way to
interface a naïve Fibonacci function with a memoization mapping?
 
int fib(int n){
return n>1? fib(n-1) + fib(n-2): 0;
}
 
Assume `int` is a stand-in for some appropriate bignum type.
Paavo Helde <myfirstname@osa.pri.ee>: Mar 06 03:00PM +0200

> return n>1? fib(n-1) + fib(n-2): 0;
> }
 
> Assume `int` is a stand-in for some appropriate bignum type.
 
If the argument is a compile-time constant:
 
constexpr int fib(int n) {
return n>1 ? fib(n-1) + fib(n-2) : 0;
}
 
The computation would be done at compile time, so there would be no need
to memoize anything.
 
If the argument is not known at compile time and the speed is important,
then the first step would be to use an iterative algorithm instead of
recursive, as recursion tends to be pretty slow in C++. Only then, IF
the performance is not sufficient AND the profiler shows a bottleneck in
fib() one could try memoizing.
 
At this step it becomes complicated. The best solution depends very much
on the real usage pattern and other aspects like multithreading support,
so I guess there is no single 'idiomatic' way in C++. The only idiomatic
piece would probably be std::unordered_map for storing the remembered
results.
 
hth
Paavo
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 06 03:25PM +0100

On 06.03.2016 14:00, Paavo Helde wrote:
> }
 
> The computation would be done at compile time, so there would be no need
> to memoize anything.
 
This brings up the question of implementation limits, formal and
in-practice?
 
 
> If the argument is not known at compile time and the speed is important,
> then the first step would be to use an iterative algorithm instead of
> recursive, as recursion tends to be pretty slow in C++.
 
I agree with the conclusion but the argument "pretty slow in C++" is
irrelevant, whether that premise is true or not, which is a different
discussion. The improvement has nothing to do with the speed of
recursion in C++, and all to do with the big-O behavior. The exact form
is not very apparent; it was analyzed by [1]Donald Knuth in volume 1 of
"The Art of Computer Programming". But if you consider
 
return (n == 0? 0 : foo(n-1) + foo(n-1))
 
as a rough approximation, then you see that O(f(n)) ~= 2*O(f(n-1)),
which gives O(f) ~= 2^n, which is rather ungood. Compared to O(n) for
iterative, or (but lacking the precision implied by bignum ints) O(1)
for using the golden ratio formula to compute the numbers directly.
 
 
> so I guess there is no single 'idiomatic' way in C++. The only idiomatic
> piece would probably be std::unordered_map for storing the remembered
> results.
 
Yes, I agree for the general case of "any function".
 
 
Cheers!,
 
- Alf
 
Notes:
[1] Or rather, by whomever it was that did the most of the math for him.
This little thing has been troubling me. I don't know who it was.
bartekltg <bartekltg@gmail.com>: Mar 06 09:43PM +0100

> return n>1? fib(n-1) + fib(n-2): 0;
> }
 
> Assume `int` is a stand-in for some appropriate bignum type.
 
Something like this:
 
template <typename bignum>
class fib
{
private:
map <uint64_t,bignum> M; //or unordered_map
 
public:
fib() {
M[0]=0;
M[1]=1;
}
bignum operator () (uint64_t x) {
auto it = M.find(x);
if (it!=M.end())
return (it)->second;
else {
// always x >= 2 because M[0] and M[1] created in the
constructor.
M[x] = this->operator ()(x-1) + this->operator ()(x-2);
return M[x];
}
}
};
 
 
int main(){
fib<uint64_t> f;
for (int i=0;i<50;i++)
cout<<f(i)<<endl;
return 0;
}
 
For a general function, but for Fibonacci sequence is a poor idea.
 
template <typename bignum>
class sane_fib
{
private:
vector <bignum> M;
public:
sane_fib()
{
M.push_back(0);
M.push_back(1);
}
bignum operator () (uint64_t x)
{
while (x >= M.size())
M.push_back( M[M.size()-1] + M[M.size()-2] );
return M[x];
}
};
 
BTW My favorite way to compute fib numbers (in O(log(n)
multiplications)):
 
Powers of a matrix [1,1;1,0] contains fib numbers.
[1,1;1,0]^k = [Fb_{k+1},Fb_k ; Fb_k, Fb_{k-1} ].
Coputing a power of anything thac can be multiplied is easy:
 
template <typename T >
T power(T a, uint64_t ex){
T r;
if (ex==0) {
T r(1);
return r;
}
else {
if (ex%2==1) return a*power(a,ex-1);
else {
T t=power(a,ex/2);
return t*t;
}
}
}
 
Now we need a symetric matrix. A matrix library is an overkill
template <typename bignum>
class symetric_matrix
{
public:
bignum d1,d2,c;
symetric_matrix (bignum d1_,bignum d2_, bignum c_ ):
d1(d1_),d2(d2_),c(c_) {};
symetric_matrix (int x): d1(x),d2(x),c(0) {};
symetric_matrix (): d1(1),d2(1),c(0) {};
 
friend symetric_matrix operator * (const symetric_matrix& A, const
symetric_matrix& B) {
return symetric_matrix<bignum> { A.d1*B.d1 + A.c*B.c,A.d2*B.d2
+ A.c*B.c, A.d1*B.c + A.c*B.d2 };
}
};
 
 
 
int main()
{
sane_fib<uint64_t> fs;
fib<uint64_t> f;
symetric_matrix<uint64_t> A(1,0,1) ;
 
for (int i=0;i<50;i++)
cout<<f(i)<<" "<<fs(i)<< " "<< power(A,i).c <<endl;
 
return 0;
}
 
bartekltg
Juha Nieminen <nospam@thanks.invalid>: Mar 06 11:06PM

> I asked about this in comp.lang.c and the most useful response so
> far was "use C++". So what would be the most idiomatic C++ way to
> interface a naïve Fibonacci function with a memoization mapping?
 
Wouldn't it be easier to just implement it with a loop?
 
Recursive fibonacci is fancy but inefficient. Just do it iteratively.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Andre Zunino <neyzunino@hotmail.com>: Mar 05 11:45PM -0300

Hello.
 
Some years ago, when I was first experimenting with C++11's new
features, I remember feeling excited about the possibility of directly
initializing containers from a literal list of values. I also remember
being bit by the fact that compilers will always favor constructor
overloads that take std::initializer_list. I felt disappointed and
wondered how that could have been overlooked or accepted by the
committee. Why did they not choose a syntax which would not lead to
ambiguity? Wouldn't having braces around list elements (in addition to
the braces for the uniform initialization syntax) take care of it?
 
a) std::vector<int> v{ {4, 1} };
b) std::vector<int> w( {4, 1} };
c) std::vector<int> x{4, 1};
d) std::vector<int> y(4, 1);
 
a) and b) should produce vector objects with 2 elements, 4 and 1. c) and
d) should produce vectors with 4 elements, all of them equal to 1.
 
Here is a discussion on Stack Overflow:
http://stackoverflow.com/questions/22501368/why-wasnt-a-double-curly-braces-syntax-preferred-for-constructors-taking-a-std
 
And here's a post by Scott Meyers on different, but related issues:
http://scottmeyers.blogspot.com.br/2015/09/thoughts-on-vagaries-of-c-initialization.html
 
Does anybody know if there's any work being done to mend this situation?
 
Thank you.
Paavo Helde <myfirstname@osa.pri.ee>: Mar 06 11:35AM +0200

On 6.03.2016 4:45, Andre Zunino wrote:
> http://stackoverflow.com/questions/22501368/why-wasnt-a-double-curly-braces-syntax-preferred-for-constructors-taking-a-std
 
> And here's a post by Scott Meyers on different, but related issues:
> http://scottmeyers.blogspot.com.br/2015/09/thoughts-on-vagaries-of-c-initialization.html
 
What I do not understand is the desire to express everything with the
same symbol. Of course you can encode everything by repeating the symbol
arbitrary number of times ("unary numeral system"), but this does not
make it a good idea.
 
Why couldn't the braces used uniformly for initializer lists (i.e. data
values) and parens for other kind of constructors?
 
a) std::vector<int> v{ {4, 1} }; // 2 elements or syntax error
b) std::vector<int> w( {4, 1} ); // 2 elements (calling suitable ctor)
c) std::vector<int> x{4, 1}; // 2 elements
d) std::vector<int> y(4, 1); // 4 elements
 
Fur curiosity, I ran this through the compilers and it appears that's
exactly how it works! It's nice to see C++11 actually matches my
intuition ;-) (I have not used initializer lists so far so should not be
biased).
Juha Nieminen <nospam@thanks.invalid>: Mar 06 11:04PM

> What I do not understand is the desire to express everything with the
> same symbol.
 
I suppose that the purpose is to unify struct and class initialization.
 
This is valid in both C and C++:
 
struct S { int a, b; };
S s = S { 1, 2 };
 
The problem with that is, of course, that if in C++ you would now want
to replace that compiler-generated initialization in the struct with
your own constructor, it won't work in C++98. With the new unified
construction you can add a constructor to S taking two ints, and that
syntax will still work, and call the new constructor.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Dombo <dombo@disposable.invalid>: Mar 06 08:10PM +0100

Op 28-Feb-16 om 23:27 schreef Öö Tiib:
 
> What are the better ways? I sometimes suggest separate processes for
> UI and business logic but that makes interfacing even harsher so I
> don't think you meant that.
 
1. Communication; make sure everyone in the team understands the design
and understands what should go where and the rationale behind your
design decisions.
 
2. Staffing; if there are people on your team that are unable to
understand that business logic should not go into the UI code, or lack
the discipline to keep them separate, fire them. They are gonna cause
problems in other areas as well so you are better of without them.
 
3. Code reviews; make sure that there is more than one person that has
seen the code before it is committed.
 
4. Namespaces; keep the UI code in a separate namespace from the
business logic and don't allow the use of "using namespace" with a wide
scope. This makes it obvious were you are in the code and when you are
crossing boundaries without having to write error-prone/no-added-value
glue code.
 
5. Keep UI and business logic separate by using separate
projects/libraries and/or processes for UI and business logic. Separate
process can be a bit more of a pain (though there several interprocess
communication solutions that alleviate this), but there are other
reasons why you want to have the UI in a separate process, such as
reducing the impact of a bug in the UI code.
 
> shareholders since there is prospect to put business logic into
> "cloud", UI into "web" or "apps" or whatever the current buzzwords
> are.
 
No argument here, like I said before I'm all for keeping a clear
separation between UI and business logic.
 
>> from various sources. Not a good thing in my book.
 
> That is very same with other languages as well. Everybody wants to
> have some personal "style". More like samurais than engineers.
 
I don't see this in Java, I don't see this in C#, and hell even in
Python libraries often smoothly work together. Of all the programming
language I have dealt with the last 20 years (more than I care to
remember) C++ is the worst offender in this area.
woodbrian77@gmail.com: Mar 06 11:59AM -0800

On Sunday, March 6, 2016 at 1:10:11 PM UTC-6, Dombo wrote:
> communication solutions that alleviate this), but there are other
> reasons why you want to have the UI in a separate process, such as
> reducing the impact of a bug in the UI code.
 
I think there are some benefits to minimizing your libraries:
 
1. You get more familiar with the libraries you use that way.
2. Smaller executable size and no need for fruitless copies,
e.g. between different string classes.
 
 
> >> from various sources. Not a good thing in my book.
 
> > That is very same with other languages as well. Everybody wants to
> > have some personal "style". More like samurais than engineers.
 
"There are rules behind the rules and a unity that is
deeper than uniformity." C.S. Lewis
 
 
> I don't see this in Java, I don't see this in C#,
 
Please don't swear here.
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
Dombo <dombo@disposable.invalid>: Mar 06 09:03PM +0100

Op 01-Mar-16 om 7:55 schreef Richard:
> that wxWidgets is constrained by the underlying GUI toolkit of the
> environment (Win32, Cocoa, Tcl/Tk, whatever). There isn't always a
> good mapping from modern C++ to these underlying systems.
 
wxWidgets is clearly inspired by MFC; not my favorite to put it mildly.
In the defense of MFC one can argue that when it was conceived in the
early nineties the Microsoft compiler supported little more than "C with
classes"; no exceptions, no templates, no standard library (thus no
standard string and container classes) and slow processors and a not
terribly clever compiler. No such excuses for wxWidgets.
 
As far the underlying GUI toolkit and modern C++ features are concerned;
those are mostly orthogonal aspects.
 
> bridge to existing GUI technologies or API is a complete waste of
> time. Existing defacto standards have momentum and pretending that
> your library is better without that momentum on your side is silly.
 
The problem in the C++ world is that there is no defacto standard as far
as UI toolkits are concerned, there are god know how many C++ UI
libraries out there. Qt being arguably the best one if you can live with
the bloat, but still far from ideal as far as I'm concerned.
 
And by the way I don't have my own UI library, and have zero intention
to create one. Those are the kind of things I rather buy than build myself.
 
>> It can't be 10% or even 50% better if you're proposing an entirely new
>> library, it has to be 5000% better to convince people it's worth
>> learning/switching from what they already know.
 
You are missing the point. I find building UI applications in C++ rather
unproductive compared to most other programming languages I know of. One
reason is that they don't take advantage of modern C++ features (they
added those to the language for reason you know) but instead rely on on
their own kludges to implement features C++ compliers didn't have back
in the nineties. Another being that C++ UI libraries tend to have their
own types for string and containers. Now I'm not a big fan of the
standard library, but it is a _standard_ supported by all compilers. The
problem with a library having its own types is you have to write glue
code (which is error prone and doesn't add value) unless the library
does every you will ever need, which is probably the reason why Qt
attempts to provide everything but the kitchen sink.
 
> only specifies the language and not any pile of libraries on top). C#
> standard doesn't specify the .NET Framework, which is a pile of libraries
> from Microsoft. And so-on.
 
Strawman argument. I'm not arguing for having a C++ UI library in the
standard. I'm arguing for a UI library that smoothly interfaces with the
types provided by the standard library.
 
> My point is that these other languages are doing just fine,
> thank you, without "standardizing" a GUI toolkit.
 
Unlike C++ many programming languages, like C#, have one or only a very
few "defacto" UI libraries that do interface smoothly with the types in
standard library that comes with the language.
 
> So is C++.
 
If you just need an UI, C++ is rarely the best option IMO.
 
> There is no need for a GUI toolkit in the C++ standard because we
> already have defacto standards that are serving the need just fine.
 
Notice the words "defacto" and "standards" . Now think about that for a
moment (hint: the latter word is plural).
 
> C++ GUI toolkit libraries since 1988 when InterViews was described
> and that was done straight on top of Xlib, which was a C API.
> <http://www.cs.tufts.edu/~nr/cs257/archive/mark-linton/interviews.pdf>
 
Again strawman argument. No one is claiming there are no UI toolkits for
C++, if anything there are rather too many which is an indication that
there are apparently more people not too satisfied with the UI libraries
that already existed.
Dombo <dombo@disposable.invalid>: Mar 06 09:57PM +0100

> On Sunday, March 6, 2016 at 1:10:11 PM UTC-6, Dombo wrote:
 
>> I don't see this in Java, I don't see this in C#,
 
> Please don't swear here.
 
Are you a programming language bigot as well?
woodbrian77@gmail.com: Mar 06 01:49PM -0800

On Sunday, March 6, 2016 at 2:56:38 PM UTC-6, Dombo wrote:
 
> >> I don't see this in Java, I don't see this in C#,
 
> > Please don't swear here.
 
> Are you a programming language bigot
 
I'm free to choose what language(s) I like.
C++ is my favorite. Java sucks IMO.
 
> as well?
 
That sort of anti-religious bigotry has worked in
some places, but won't work here.
 
Brian
Ebenezer Enterprises - "Free at last; free at last.
Thank G-d Almighty we are free at last." ML King Jr.
 
http://webEbenezer.net
woodbrian77@gmail.com: Mar 06 10:44AM -0800

http://meetingcpp.com/index.php/newsreader/items/c-user-group-meetings-in-march-2016.html
 
Some have said that some of those "meetings" are on
autopilot and may not still be taking place.
 
https://groups.google.com/forum/#!topic/comp.lang.c++/PKsxQHaE7Ng
 
Specifically, the meetings in Washington, DC and Sacramento
were thought to be no longer happening.
 
If others are interested in a C++ meeting in the St. Paul,
Minnesota area, please let me know. By the grace of G-d,
I'm able to provide a meeting area in a conference room in
the office building where Ebenezer Enterprises is, and I
would be happy to give a talk or two.
 
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
woodbrian77@gmail.com: Mar 06 09:54AM -0800

On Thursday, March 3, 2016 at 8:53:44 AM UTC-6, Alf P. Steinbach wrote:
 
> Presumably the Boost small vector doesn't claim to conform to the full
> `std::vector` requirements. Thanks for pointing me in that direction! :)
> I didn't know about it.
 
I think calling that "small" when it can become huge is
goofy. Maybe it should be called array_vector. And like
std::list, whatever that thing is called, it's rarely needed.
 
This reminds me of my rabbi's teaching to "chew the meat
and spit the bones." Some of Boost is great, but other
parts are lame.
 
Brian
Ebenezer Enterprises - "Real development is not leaving
things behind, as on a road, but drawing life from
them, as from a root." G. K. Chesterton
I'd add the word "software" before the word "development."
 
http://webEbenezer.net
ram@zedat.fu-berlin.de (Stefan Ram): Mar 06 04:50AM

>Does anybody know if there's any work being done to mend this situation?
 
Changes in this directions could change the meaning of
existing programs. IIRC,
 
::std::vector< int >x{ 4, 1 };
 
creates a vector object with 2 elements, 4 and 1, now, while
you suggest it to produce a vector with 4 elements, all of
them equal to 1.
 
IIRC, Sutter said that new standard classes will avoid
constructors that are »ambiguous« in this regard, while then
someone else observed that even new standard classes have
those issues.
 
However, AFAIK, C++17 will allow
 
auto cpp{ 17 };
 
to define an int variable »cpp«.
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)