Thursday, May 26, 2016

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

ram@zedat.fu-berlin.de (Stefan Ram): May 26 01:33AM

>std::is_pointer<T>::value;
 
Ew, »::value«, that is sooo C++11!
 
(No, seriously, »::value« is ok. Since C++14, there also is
an »operator()«.)
ram@zedat.fu-berlin.de (Stefan Ram): May 26 10:39PM

>Good principles for software development:
>DRY Don't Repeat Yourself (i.e. avoid redundancy)
 
I only learned yesterday that this comes from the
book »The Pragmatic Programmer« IIRC.
 
>KISS Keep It Simple, Stupid! (i.e. avoid complexity)
 
I really hate it, when people try to soften this into
»Keep it simply stupid!« - It's gotta be »Stupid!«!
Otherwise it loses its charm.
 
>YAGNI You Ain't Gonna Need It (i.e. avoid over-generalization)
 
I tend to modify it in this way: »Hide the decision behind
an interface!«.

For example: You want to write an editor in C++.
You could use ::std::string to hold the buffer, but
a rope would be much better - however it might take
time to implement ropes.
 
In such a case, I hide the edit buffer behind an interface,
and implement it with ::std::string. Now I know that I can
easily change this implementation into an implementation
that uses ropes should the need ever arise. No need to
implement the rope /now/.
 
What else can I find in my notebook?
 
- Open/Closed principle (Uncle Bob, 1996)
- High Cohesion
- Low Coupling
- Protected Variations (Alistair Cockburn, 1996), Encapsulate Change
- Don't talk to strangers! (Demeter's Law)
- Tell, don't ask!
- Design by contract (Bertand Meyer, 1988)
- Single Responsibility Principle
- Principle of Least Astonishment/Surprise
- God class (God object) (an antipattern)
- Dependency Inversion Principle
- Information Hiding (David Parnas, 1972)
- Liskov Substitution Principle (Barbara Liskov)
- Test Driven Development
- Composition Over Inheritance
 
Maybe what i described with the edit buffer is
a variation on »Encapsulate Change«.
 
So, how can one actually a text editor in C++?
 
Here's my code (from my C++ course):
 
#include <iostream>
#include <ostream>
#include <istream>
#include <cstdlib>
 
int arg( ::std::string & s ){ return stoi( s.substr( 1 )); }
 
int main()
{ ::std::cout << "i1 insert \"1\"\n+1 move cursor right\n "
::std::string s{ "alpha" }, command; int pos = 0; while( 1 )
{ ::std::cout << s << '\n' << ::std::string( pos, ' ' ) << '^' << '\n';
::std::cin >> command; switch( command.at( 0 ))
{ case '+': pos += arg( command ); break;
case 'i': s.insert( pos, command.substr( 1 )); break; }}}
 
It starts by printing its manual. You can use the command »i«
to insert some text, or the command »+« to move the cursor.
The editor is pre-filled with the text »alpha«.
An example session:
 
i1 insert "1"
+1 move cursor right
alpha
^
+2
alpha
^
i__
al__pha
^
 
If you miss any function, that's an exercise!
 
For example, try to add a command »-« to move to the left
or »d« to delete a number of characters. So, this is even
an editor that can easily be extended with custom commands
by the user!
ram@zedat.fu-berlin.de (Stefan Ram): May 26 10:57PM

>But for a pendulum T ~ 2 pi sqrt( L / g ), so the time
>changes with the /square root/ of the length L.
 
The quoted text is literally true, but still I believe
I might have been wrong, because I used this in the context
of a hypothetical change of more lengths than of just »L«,
and such changes also might possibly change »g«, and I
failed to take this into account. But since this is off topic
here anyways, I will not write more about this.
Thomas David Rivers <rivers@dignus.com>: May 26 11:19AM -0400

Jerry Stuckle wrote:
 
 
>You haven't worked on very big projects, then. I've seen compiles take
>overnight on a mainframe.
 
Which is why we provide a cross-compiler for the mainframe;
we can fix that problem... very often this is a side-effect of
an overloaded mainframe.
 
- Dave Rivers -
 
--
rivers@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
"Öö Tiib" <ootiib@hot.ee>: May 26 08:44AM -0700

On Monday, 23 May 2016 09:57:53 UTC+3, Wouter van Ooijen wrote:
 
> > https://www.linkedin.com/pulse/why-i-dont-spend-time-modern-c-anymore-henrique-bucher-phd
 
> Why did that article raise such a sorm? There is hardly any real
> argument in it.
 
The storm is because they hate that C++ is really just a programming
tool. One can make good programs with it or bad programs with it.
However neither is what they want to do. They don't want to do *any*
engineering work whatsoever. So they do not need things like C++.
Maximum that they may be fine with is to configure some framework.
 
> would have a good point, but now he is in effect complaining that them
> other people did not write the papers he would like to see. He dude, if
> you want something done, do it!
 
That is not what they expect to do. They expect that language designers
make the work and they are consumers. So for (possibly slightly stretched)
example they need to translate ABNF rules into regular expressions.
What function they have to call for that? No such functions? That means
C++ committee did bad work, did not add feature they happen to need
and instead there are complexities they don't need.
 
> and hence almost un-used. Unless someone creates a realy good
> alternative (there are attempts) I stick with what I can use now on
> almost every micro-controller I need to program.
 
C++ is too universal tool. Most complex software what average human uses
(web browser) is programmed in C++, biggest servers human contacts
(Facebook, YouTube etc) are programmed in C++ and also software of smallest
micro-controllers is often programmed in C++. So it is universal and it
can't be most convenient for every context that it is usable in.
 
> some of those fancy new features (constexpr! templates, even some form
> of lambda's) help me a lot to make my programs smaller and faster.
> Especially templates.
 
I still feel that the author just does not want such tools at all. Does
not want to consider what is done compile time or run-time, does not
want to care if some value is reused by move or copied, likes tight
intrusive coupling with abstract base classes (not lambdas) and so on.
 
All those optimizations were achievable in C++03. The effect of 'constexpr'
was achievable with template meta-programming gibberish, move had example
implementation ('std::auto_ptr' was quite tricky) and typical usage of
lambda was achievable with tricks done within 'boost::bind'.
Jerry Stuckle <jstucklex@attglobal.net>: May 26 05:46PM -0400

On 5/26/2016 11:19 AM, Thomas David Rivers wrote:
> we can fix that problem... very often this is a side-effect of
> an overloaded mainframe.
 
> - Dave Rivers -
 
Not when it's the only thing running on the mainframe. That's why it's
run overnight.
 
A cross-compiler on a non-mainframe would take much longer.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Christian Gollwitzer <auriocus@gmx.de>: May 26 11:03PM +0200

Am 25.05.16 um 04:46 schrieb Rick C. Hodgin:
> Mr. Flibble, Jesus did come to the Earth. He is God. He stepped out of
> Heaven,....
 
Matthew 5, 3
 
Christian
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 26 04:32PM +0200

Good principles for software development:
 
• DRY – Don't Repeat Yourself (i.e. avoid redundancy)
• KISS – Keep It Simple, Stupid! (i.e. avoid complexity)
• YAGNI – You Ain't Gonna Need It (i.e. avoid over-generalization)
 
And of course, AHA! – Avoid Hare-brained Abbreviations!
 
 
- Alf
forwarding his own Facebook-posting to a wider audience
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 26 05:32PM +0100

On 26/05/2016 15:32, Alf P. Steinbach wrote:
> • KISS – Keep It Simple, Stupid! (i.e. avoid complexity)
> • YAGNI – You Ain't Gonna Need It (i.e. avoid over-generalization)
 
> And of course, AHA! – Avoid Hare-brained Abbreviations!
 
KISS is both obvious common sense but also not always achievable as
complexity cannot always be avoided. One can often break complex things
down into simpler parts though.
 
/Flibble
"K. Frank" <kfrank29.c@gmail.com>: May 26 09:50AM -0700

Hello Group!
 
On Thursday, May 26, 2016 at 12:33:05 PM UTC-4, Mr Flibble wrote:
 
> KISS is both obvious common sense but also not always achievable as
> complexity cannot always be avoided. One can often break complex things
> down into simpler parts though.
 
I'm with Leigh S.S. on this one. I've learned the hard
way over the years that trying to find a simple solution
to an inherently complex problem is a fool's errand.
 
Many of the problems we address with programming are
complex, and I've come to believe that much of the art
is figuring out how to manage that complexity. There
are so many times I've had writer's block (programmer's
block?) that just disappeared as soon as I admitted
to myself the the problem I was working on wasn't as
simple as I wanted to pretend.
 
> /Flibble
 
 
Happy Hacking!
 
 
K. Frank
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 26 10:06AM -0700

On Thursday, May 26, 2016 at 10:33:52 AM UTC-4, Alf P. Steinbach wrote:
> • KISS – Keep It Simple, Stupid! (i.e. avoid complexity)
> • YAGNI – You Ain't Gonna Need It (i.e. avoid over-generalization)
 
> And of course, AHA! – Avoid Hare-brained Abbreviations!
 
:-)
 
My best advice to software developers looking to improve their coding
standards and general development skills is to go out and read over
lots of available software, especially from the larger projects like
the Linux kernel, LibreOffice, and Blender.
 
It's very interesting to see how the various developers write code, and
how the various projects require certain styles. There are good and bad
things to be learned from all of them.
 
And in my case, since I have dyslexia that's pretty bad at times, I've
learned to introduce extra spacing, coloring, and special formatting which,
I'm told, many other people dislike extensively. :-) But, it really does
help me read the source code more easily ... so sometimes there are those
considerations beyond mere source code requirements, as there are also
people requirements.
 
Best regards,
Rick C. Hodgin
"Öö Tiib" <ootiib@hot.ee>: May 26 10:24AM -0700

On Thursday, 26 May 2016 19:51:02 UTC+3, K. Frank wrote:
> block?) that just disappeared as soon as I admitted
> to myself the the problem I was working on wasn't as
> simple as I wanted to pretend.
 
Your block was because you attempted to do impossible. It is futile.
Even Einstein taught that "Everything should be made as simple as
possible, but not simpler".
 
About kissing he taught that ... "Any man who can drive safely while
kissing a pretty girl is simply not giving the kiss the attention it
deserves." So he was wise guy. ;)
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 26 06:28PM +0100

On 26/05/2016 18:06, Rick C. Hodgin wrote:
> help me read the source code more easily ... so sometimes there are those
> considerations beyond mere source code requirements, as there are also
> people requirements.
 
Was this post just a temporary lull in the usual god bothering noise?
 
/Flibble
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 26 11:37AM -0700

On Thursday, May 26, 2016 at 1:28:21 PM UTC-4, Mr Flibble wrote:
> Was this post just a temporary lull in the usual god bothering noise?
 
My usual posts comprise of things related to my job, personal project,
personal interests, and all of them involve God in one way or another.
 
From time to time I post specific and explicit posts about God so as to
teach those who don't have the opportunity to otherwise hear the same
from the normal things they do in this world, but the things I do in this
world are those things I do, and because I'm a Christian they relate to
God:
 
XBase program called Visual FreePro, Jr:
 
https://github.com/RickCHodgin/libsf/tree/master/source/vjr/source
 
32-bit operating system called Exodus (named that way eight years before
I became a Christian, as it was simply supposed to be a "mass departure
from evil," which was Microsoft at the time (1996)):
 
https://github.com/RickCHodgin/libsf/tree/master/exodus/source
 
Hardware design for a microprocessor called Arxoda, a 40-bit extension
to the 80836 (which I call LibSF 386-x40), instead of the 64-bit extension
we have in AMD64. 40-bits gets to you 1TB of physical address space:
 
https://github.com/RickCHodgin/libsf/tree/master/li386
 
And my current project is a C/C++ compiler called CAlive, that is
basically a C compiler which has the class and several new features
that neither language supports:
 
https://github.com/RickCHodgin/libsf/tree/master/books/rdc
https://groups.google.com/forum/#!forum/caliveprogramminglanguage
 
-----
I have regular things I do in my life, Mr. Flibble. I just happen to be a
born again Christian who seeks to honor God with the skills I possess in my
life.
 
I also like welding, tennis, woodwork in general, working on cars, and am
interested in building a wooden boat similar to this (Devlin Godzilla 25
Tugboat, though the version I would build would be closer to the build style
of that seen in the second video):
 
https://www.youtube.com/watch?v=WNRaSanZrlU
https://www.youtube.com/watch?v=sWIs-9wlaV4&t=15m23s
 
My family and I are planning to build a 1/8th scale model of the boat we'd
like to build this summer. If we all agree we'll begin building it with a
plan to complete it over several years.
 
Best regards,
Rick C. Hodgin
"K. Frank" <kfrank29.c@gmail.com>: May 25 06:00PM -0700

Hello Heinz-Mario!
 
On Wednesday, May 25, 2016 at 2:09:58 PM UTC-4, Heinz-Mario Frühbeis wrote:
> c_IDAMap <c_Member> mMap; // w/o pointer
 
> How can I get in c_IDAMap an info about the template if it is a pointer
> or not?
 
If I understand correctly, you are asking how to determine
whether or not the type t_MapMember is a pointer (in a specific
instantiation of c_IDAMap).
 
You could use std::is_pointer in type_traits. See, e.g.:
 
http://www.cplusplus.com/reference/type_traits/is_pointer/
 
To be concrete:
 
#include <iostream>
using std::cout;
using std::endl;
 
#include <type_traits>
 
template <typename T> class A {
public:
static bool isPointer() { return std::is_pointer<T>::value; }
private:
T t;
};
 
int main (int argc, char* argv[]) {
A<int> aInt;
A<int*> aPInt;
cout << "aInt.isPointer() = " << aInt.isPointer() << endl;
cout << "aPInt.isPointer() = " << aPInt.isPointer() << endl;
}
 
Here, class A is a baby version of your c_IDAMap. You can
tell whether type T (the analog of your t_MapMember) is a
pointer.
 
(My example might not be the slickest way to package this,
but it's a straightforward illustration of the is_pointer
feature.)
 
> Regards
> Heinz-Mario Frühbeis
 
 
Good luck.
 
 
K. Frank
"Heinz-Mario Frühbeis" <Div@Earlybite.individcore.de>: May 26 10:06AM +0200

Am 26.05.2016 um 03:33 schrieb Stefan Ram:
 
> Ew, »::value«, that is sooo C++11!
 
> (No, seriously, »::value« is ok. Since C++14, there also is
> an »operator()«.)
 
Hi!
 
Thank you both very<!> much! It is working perfectly!
 
But now I have a further question...
 
template < class t_MapMember >
class c_IDAMap{
typedef std::pair < std::string, t_MapMember > tPair;
typedef std::vector < tPair > tVec;
t_MapMember *nMember = NULL; // I'm using it currently [1]
// ...
}
 
template < typename t_ItemGet >
t_MapMember& operator [] (t_ItemGet vKey){
typename tVec::iterator itrTVec;
int nPos = -1;
nPos = GetPos(vKey);
if(nPos == -1){
return *nMember; // <-- [1]
} else{
itrTVec = vecMembers.begin();
advance(itrTVec, nPos);
}
return itrTVec->second;
}
 
[1]:
At this point there is no match found...
E.g.:
class A{
public:
std::string mString;
...
A(){mString = Hallo;}
}
c_IDAMap <A*> mMap;
Now adding e.g. "Hallo" and "Hi" (as Key!) ...
And than calling:
cout << mMap["Hallo"]; // Output is "Hallo"
 
But calling...
cout << mMap["Halo"];
raises an error, which I currently cannot handle really good and the
program crashes. The really problem is if the template is a pointer,
because I'm not able to return NULL.
Maybe because of 't_MapMember& operator [] (t_ItemGet vKey){' and the
'&' after 't_MapMember'.
It always returns a value other than NULL, so I cannot "ask" (if the
template contains pointer)...
 
if(mMap["Halo") == NULL) return; // E.g. ...
 
Do someone have a suggestion how I can return NULL in case of a mismatch?
 
Regards
Heinz-Mario Frühbeis
"K. Frank" <kfrank29.c@gmail.com>: May 26 09:35AM -0700

Hi Heinz-Mario!
 
On Thursday, May 26, 2016 at 4:06:56 AM UTC-4, Heinz-Mario Frühbeis wrote:
> template contains pointer)...
 
> if(mMap["Halo") == NULL) return; // E.g. ...
 
> Do someone have a suggestion how I can return NULL in case of a mismatch?
 
The general question you are asking is how to signal
that a key is not found when looking it up in a
collection, for example, in a key-value map.
 
Three approaches are common:
 
You can return a sentinel value -- a special value
not otherwise used that is deemed to mean "key not
found."
 
(In your specific case where you have a collection
of pointers, "c_IDAMap <A*> mMap;", if you know that
you will never store nullptr as a valid value in
your collection, then returning nullptr as the "key
not found" value could, indeed, work. If nullptr
could be a valid value, then this approach won't
work. Also, because you've made your collection
a class template whose stored type is not required
to be a pointer, you would need extra handling to
make your template code work sensibly for both pointer
and non-pointer types.)
 
You can return a default value. (See, for example,
how std::map::operator[] behaves when the key is not
found.)
 
You can throw an exception.
 
All of these work and can make sense depending on the
details of what you are trying to do. I would suggest
that you think about your use case, decide which of
these strategies makes the most sense for you, and then
drill down into the implementation details.
 
> Regards
> Heinz-Mario Frühbeis
 
 
Good luck.
 
 
K. Frank
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)