Friday, December 15, 2017

Digest for comp.lang.c++@googlegroups.com - 12 updates in 3 topics

JiiPee <no@notvalid.com>: Dec 15 10:06PM

I feel like I just invented something myself nobody ever thought about!!
hehe. Just joking, am sure somebody has done similar before.
 
I have a question that is this idea good. I present it with a simple
game class example. We all know that its better to get access to data
members preferable via functions (like if parent class has private
members, then the inherited class would get access to them by protected
funtions and the variables are not in protected section but rather
privates.).
 
Ok,.. Here first the "normal" version without "my invention" :) :
 
class Board
{
    // data/functions for the board
};
 
class Game
{
public:
    void startGame() {
        if (!m_isGameOn) {
            m_board = make_unique<Board>();
            m_isGameOn = true;
        }
    }
private:
 
    void gameOver() {
        m_isGameOn = false;
        m_board.reset(nullptr); // board not needed anymore
    }
 
    bool m_isGameOn{false};
    std::unique_ptr<Board> m_board;
};
 
 
So we get access to private member directly. And because gameOn is
linked to board here, we do them together when the game starts (many
times variables are linked with each others somehow like this ... just
an example, maybe not best... but just to illustrate the point).
 
Now, ....lets see "my invention" version (which I feel might be better):
 
class Board
{
    // data/functions for the board
};
 
class GamePrivate
{
public:
    bool isGameOn() { return m_isGameOn; }
    void gameStarts() {
        if (!m_isGameOn) {
            m_board = make_unique<Board>();
            m_isGameOn = true;
        }
    }
    void gameOver() {
        m_isGameOn = false;
        m_board.reset(nullptr); // board not needed anymore
    }
private:
    bool m_isGameOn{ false };
    std::unique_ptr<Board> m_board;
    // other private variables for Game
};
 
class Game
{
private:
    void startGame() {
        m_data.gameStarts();
    }
    GamePrivate m_data;
};
 
So, all (private) data is hidden behind GamePrivate class, thus we
cannot modify any private variabe directly! Because many times I
actually want this: I dont want the *Game* class to be able to directly
modify its own private variables. Now all variables are accessed by a
(getter/setter) function from GamePrivate. So this way Game glass cannot
mess up for example the connection between m_board and m_isGameOn: like
after starding the game Game class cannot change only one of them by
accident.
 
 
Is this a good idea to have all private data hidden in another class so
that Game class cannot get direct access to its variables?
thiago.adams@gmail.com: Dec 15 03:28AM -0800

On Monday, December 11, 2017 at 4:29:35 PM UTC-2, Mr Flibble wrote:
> > performance issues.  But there is still a lot left beyond "C with
 
> There is no reason why use of the STL should result in memory
> fragmentation or unpredictable performance.
 
If you use a vector with the default allocator, and you don't use
reserve then you can create fragmentation.
For embedded systems the first option is not use dynamic allocation.
thiago.adams@gmail.com: Dec 15 03:33AM -0800

On Monday, December 11, 2017 at 5:24:02 PM UTC-2, David Brown wrote:
...
> that you get unpredictable performance. If you have a good enough
> implementation of the STL, use custom allocators, etc., and are careful
> about what you are doing, it should be okay.
 
I think trying to customize STL is more complicated than create a small
custom vector class and will requires a lot of details to be understood and
the code is prepared to be generic and solve problems that the specific
code doesn't have to solve.
Generic code can be dangerous when you try to solve problems that you
don't have.
thiago.adams@gmail.com: Dec 15 03:44AM -0800

On Monday, December 11, 2017 at 5:28:19 PM UTC-2, Ian Collins wrote:
...
> constexpr certainly is, along with enum class, atomics and all of the
> other bits that suit embedded development. C++ >=11 is a better
> language for both embedded and kernel development.
 
I haven't seen big advantages in constexpr for functions.
I can clearly see disadvantages in compilation time.
 
For instance, let's say I have a function to calculate
some value.
 
factorial(5);
 
This function will run in each compilation.
 
Comparing with C solution.
 
#define FACTORIAL_FIVE 120
 
or a better name with better meaning in the context, maybe even
better than factorial(5).
 
I am not saying that we cannot find some application for
constexpr, but I am saying that I would consider a calculate-once
solution instead of calculate in each compilation solution.
thiago.adams@gmail.com: Dec 15 04:09AM -0800

On Monday, December 11, 2017 at 6:14:05 PM UTC-2, David Brown wrote:
 
> override, final, nullptr, enum class, explicit conversion operators -
> they all make it easier to write safer code with better static error
> checking.
 
The problem I see with nullptr and enum class is that for an existing
code base or when integrating with some other library (C for instance)
the code becomes mixed in style. The same for using or typedef.
Or new style for function declaration.
 
For override/final and deleted/default especial functions this
problem is not so big but you can
have classes already updated and others not. (I think clang has a tool to
upgrade C++ code, this could be used to add override )
 
The word 'virtual' could be used optionally in the past
the show when a function was virtual. Now override has a role
and also can show that a function is virtual.
This also creates two options in style.
 
class X
{
virtual void F() override;
void F() override;
}
 
In general, when we have two options to do something the programmers
will argue in style, or they will try to find some minimal reason
to choose between one style or other creating small decision ifs
in their heads. The code can be mixed as well because each programmer
wants to use a different style or just to show that there is a new
option to use.
The same already happens with static functions x anonymous namespaces,
or tabs X spaces or the style of braces or inline in member function X none.
 
This kind of 'problem' is just drag for software development. At same
time, this is not something to blame (too much) C++ because the language needs
to be compatible with the previous versions.
JiiPee <no@notvalid.com>: Dec 15 12:51PM

On 11/12/2017 17:29, Scott Lurndal wrote:
 
> Limit yourself to C with classes
> (don't use STL, don't use Exceptions, disable RTTI for performance).
 
How about new C++ features like unique pointers and lambdas etc? shared
pointers.
 
std::string and std::vector not usable? also I understood that
std::array has no overhead, why would it be bad to use?
David Brown <david.brown@hesbynett.no>: Dec 15 02:18PM +0100


> This function will run in each compilation.
 
> Comparing with C solution.
 
> #define FACTORIAL_FIVE 120
 
That is /not/ the C equivalent. The C equivalent would be:
 
#define FACTORIAL_FIVE (5 * 4 * 3 * 2 * 1)
 
or perhaps:
 
#define FACTORIAL_ONE 1
#define FACTORIAL_TWO (2 * FACTORIAL_ONE)
#define FACTORIAL_THREE (3 * FACTORIAL_TWO)
#define FACTORIAL_FOUR (4 * FACTORIAL_THREE)
#define FACTORIAL_FIVE (5 * FACTORIAL_FOUR)
#define FACTORIAL_BAD (1 / 0)
 
#define FACTORIAL(x) (x == 1 ? FACTORIAL_ONE : x == 2 ? FACTORIAL_TWO \
: x == 3 ? FACTORIAL_THREE : x == 4 ? FACTORIAL_FOUR \
: x == 5 ? FACTORIAL_FIVE : FACTORIAL_BAD)
 
Clearly, factorial is not a great example for this sort of thing.
 
A better example would be a table of sine values for an embedded motor
controller, or a generating hashes of strings used to look up
translation files, or a table of CRC values.
 
In C++, the solution is now to use constexpr, perhaps initialising an
array. In C, the solution is to give up and write a program to generate
the data in a separate file, that you then #include in your C code. (I
have done that for these three examples.)
 
 
> I am not saying that we cannot find some application for
> constexpr, but I am saying that I would consider a calculate-once
> solution instead of calculate in each compilation solution.
 
There can be times when the compilation in C++ would be so long that
this is relevant - you would not want a constexpr Akerman function with
a multi-precision integer class. But there is a big step before you get
there. And with C++14's unrestricted constexpr functions, this sort of
thing is /much/ easier to write, and much more efficient, than the old
recursive templates from pre-C++11.
David Brown <david.brown@hesbynett.no>: Dec 15 02:23PM +0100

> code base or when integrating with some other library (C for instance)
> the code becomes mixed in style. The same for using or typedef.
> Or new style for function declaration.
 
These are new features. If you mix them with old code, things will look
a bid odd. That's life in the programming world - it is not a reason to
stop progress! You always have to make the choice - do I write this
code in the old way to be consistent with other old code, or do I take
advantage of the new features to write better code?
 
> problem is not so big but you can
> have classes already updated and others not. (I think clang has a tool to
> upgrade C++ code, this could be used to add override )
 
clang's tool can help automate updates of some features of C++. I
haven't tried it.
 
 
> This kind of 'problem' is just drag for software development. At same
> time, this is not something to blame (too much) C++ because the language needs
> to be compatible with the previous versions.
 
Yes, it is an unavoidable problem. In some cases, older styles can be
deprecated or there can be warnings added to implementations.
Ian Collins <ian-news@hotmail.com>: Dec 16 07:37AM +1300

On 12/16/2017 02:23 AM, David Brown wrote:
>> upgrade C++ code, this could be used to add override )
 
> clang's tool can help automate updates of some features of C++. I
> haven't tried it.
 
I have use clan modernise, on a large code base, and it worked
surprising well.
 
--
Ian
Paavo Helde <myfirstname@osa.pri.ee>: Dec 15 10:09PM +0200

> code base or when integrating with some other library (C for instance)
> the code becomes mixed in style. The same for using or typedef.
> Or new style for function declaration.
 
You are confusing the goal and the means. Consistent style is not a
goal, it's just a way to produce more maintainable and reliable programs
(which are also just some specific means for solving some real world
problems).
 
If mixed-style code means more reliable and maintainable code than
non-mixed old-style, then it's better, not worse.
 
Cheers
Paavo
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 15 04:22AM +0100

On 12/14/2017 11:06 PM, Jorgen Grahn wrote:
>> No.
 
> For what it's worth, I agree. I'm all for good typography on the web
> and on paper, but here it doesn't add any value.
 
If one refrains from posting source code with non-ASCII characters just
to support some very few people's archaic newsreader software, then IMHO
that's an impractical set of priorities.
 
And given that newsers therefore should use software able to read UTF-8
encoded text, which now is the default for nearly all other text
exchange on the web, there's no problem with em-dash (as opposed to
certain Chinese glyphs that require two character positions, still a
technical problem for contexts where a monospaced font is desirable).
 
There's no problem with the ordinary ASCII hyphen either, but to the
degree that em-dash is a problem, for some, there is a problem with
posting modern source code and data, for those people.
 
 
Cheers!,
 
- Alf (opinionated, for the occasion)
David Brown <david.brown@hesbynett.no>: Dec 15 08:44AM +0100

On 14/12/17 23:06, Jorgen Grahn wrote:
>> No.
 
> For what it's worth, I agree. I'm all for good typography on the web
> and on paper, but here it doesn't add any value.
 
Agreed. When something can be done in simple plain ASCII text, then
that is the format to use. UTF-8 is fine if it adds something useful
(like for Öö's name), or characters that just can't be written sensibly
in ASCII. But "quotation marks", italic _U_, etc., are fine in ASCII.
It makes life easier for people with older software, or if they are
viewing in fonts that don't have such a range of characters. And it is
/much/ easier for most people to type.
 
I've read "The TeXBook", and like to distinguish between "--" and "---"
in my documentation. But for quick emails or "readme" files, plain text
works best. (I really hate it when people use Word documents for a few
lines of text.)
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)