C++11/C++14 appreciation thread

[JiiPee]

In this thread/post you can tell what you like in C++11/C++14. How it
made things nicer, how you use it and how it made those things easier.
Why you like C++11/C++14 more than the old C++?

[JiiPee]

I used many times lambda in functions where I need to repeat some code
but I do not want to create a function for it (because it reallly belong
to that function, so I do not like to create an outside function which
others can access, it only belong to this function). I like this.
Example from one of my class (handling windows messages):

LRESULT GDIHandler::WindowProcedureHandler(HWND hwnd, UINT message,
WPARAM wParam, LPARAM lParam)
{
...
auto sendMouseMessage = [this] (World::MouseMessage msg, int x, int y)
{
for(auto game : getGames())
game->onMouseMessage(msg, x, y);
};
int x{LOWORD(lParam)}
int y{HIWORD(lParam)}
switch (message)
{
case WM_LBUTTONDOWN:
sendMouseMessage(World::LBUTTON_DOWN, x, y);
break;
case WM_LBUTTONUP:
sendMouseMessage(World::LBUTTON_UP, x, y);
break;
.............
}
}
(maybe WM_ messages could be mapped also somehow, but anyway if I want
to do with switch then this is good)

I know some maybe dont like it but I like this :). Like above, I do not
want to create a function "sendMouseMessage ", becouse then other
functions can also access it. Now only WindowProcedureHandler can get
access to it. Also I heard this can possibly be optimized better by
compiler than normal functions.

[JiiPee]

"enum class" solved my long term problems... becouse before I had to
create long names like:
enum Animal {AN_DOG, AN_CAT}
becouse somewhere surely I had another DOG.... so now I can:
enum class Animal {DOG, CAT}
no more AN_ kind of adding but just DOG, which it really should be imo.

"auto" nice..... because am a bit lazy, so helps me :). also good to
know it finds the best type, so reduces mistakes. so started using it.

[Jorgen Grahn]

So far, ranged-for and auto. 'auto' for "trust me, the exact type
here is not interesting in any way" -- not everywhere.

I'm also fairly impressed by Boost.Asio, and how you can use lambdas
there.

But the best part is that it includes all of C++98. IMO, that's when
C++ became useful. Without the standard containers and without people
used to using templates, the language sucked. I'm still dealing with
the fallout from that, 15+ years later.

The C++98 compatibility might seem obvious, but look at Python 3.x
which chose to break all old code. I'm so happy we're not going in
that direction: it's a tempting stratey for a language person, but in
practice it means a world of pain for a lot of real users.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Paavo Helde]

Apart other things like ranged-for and auto I would like to point out
rvalue references and std::move(). Earlier I had to emulate such things
with swap, but this was cumbersome, error-prone and leaked
implementation details over interface borders. Rvalue references solve
this nicely and bring C++ to its stated goal of zero-overhead
abstractions (in a specific area).

This is not important for everybody, but for some it is very important.

Cheers
Paavo

[Alf P. Steinbach]

C++11 got rid of `std::auto_ptr` (especially the Visual C++
implementation was unreliable and buggy) and put `std::shared_ptr` and
`std::function` in the standard library.

That was nice.

Also the removal of the requirement that a container item had to be
assignable.

Most people will probably mention rvalue references and support for move
semantics as a real improvement, especially considering how Andrei
Alexandrescu's “Mojo” demonstrated that C++03 was not up to the task.
However, rvalue references are a kind of hack and they were not well
understood when they were adopted. We don't have perfect forwarding,
which was a goal (e.g. literal 0 can't be forwarded as such, and try
forwarding e.g. `std::endl`), and e.g. `&&` can mean either an rvalue
reference or a universal reference, depending on the context. It's a
mess. So I'm happy that there's SOMETHING, but unhappy with the number
of warts and imperfections, which IMHO is needlessly far too great.

I like `using` aliases. They brought a much needed notational
simplification. Lately I've started to use aliases such as `In_` to
specify the type of a formal in-argument, `Ref_` to specify a reference
type, and so on, and this makes the code more readable and easier to
figure out, at the cost of ungood verbosity: not yet sure if it's worth
it, but it looks OK so far, and for teaching it avoids confronting a
learner up-front with the (according to Kernighan and Stroustrup) failed
syntax experiment of C and early C++, which can be a barrier.


Cheers & hth.,

- Alf

[JiiPee]

yes I also like that we now just return the object itself from a
function if there is move semantics for that class. no need to hassle
with pointers or references. Makes coding also faster.

[Öö Tiib]

On Saturday, 23 January 2016 04:17:45 UTC+2, JiiPee wrote:
> "enum class" solved my long term problems... becouse before I had to
> create long names like:
> enum Animal {AN_DOG, AN_CAT}
> becouse somewhere surely I had another DOG.... so now I can:
> enum class Animal {DOG, CAT}
> no more AN_ kind of adding but just DOG, which it really should be imo.

The syntax sugar (if we write 'Animal_Dog' or 'Animal::Dog') feels of
low importance about 'enum class' to me. The improved type safety of it
feels more important improvement.

Other thing about syntax. IMHO code that screams HERE_IS_MACRO is fine,
because macros should be avoided and if not avoided then readers should
be warned about these. The DOG and CAT are not macros so why you suggest
to scream there?

[JiiPee]

On 23/01/2016 12:00, Öö Tiib wrote:
> Other thing about syntax. IMHO code that screams HERE_IS_MACRO is fine,
> because macros should be avoided and if not avoided then readers should
> be warned about these. The DOG and CAT are not macros so why you suggest
> to scream there?

I think its because it seems to be the way many do it. Like here:
http://www.cprogramming.com/c++11/c++11-nullptr-strongly-typed-enum-class.html
enum Color {RED, GREEN, BLUE};

http://www.learncpp.com/cpp-tutorial/45-enumerated-types/
enum Color
{
RED,
BLUE, // BLUE is put into the global namespace
GREEN
};

#########################

So many use that syntax. But am still not sure which one to use

[JiiPee]

On 23/01/2016 12:00, Öö Tiib wrote:

> 'Animal_Dog' or 'Animal::Dog'

hmm, i prefer that latter one. There is a type separation there, but in
the first there is a name separation, so its not exatclly the same.

[Öö Tiib]

I really like most language and library improvements by C++11/C++14.

I somewhat dislike only few things like the syntactic looseness of
initialization and rvalue references and move. Something had to be done
there and how C++11/C++14 added those is maybe not best but certainly
not worst anyway.

[David Brown]

On 23/01/16 13:23, JiiPee wrote:
> On 23/01/2016 12:00, Öö Tiib wrote:
>> Other thing about syntax. IMHO code that screams HERE_IS_MACRO is fine,
>> because macros should be avoided and if not avoided then readers should
>> be warned about these. The DOG and CAT are not macros so why you suggest
>> to scream there?

Macros should not be avoided, nor are they something to panic about and
warn people "HERE BE DRAGONS". They are a tool in the toolbox - if you
use them properly and appropriately, they are perfect safe, functional
and useful - and they don't need special treatment.

>
> I think its because it seems to be the way many do it. Like here:
> http://www.cprogramming.com/c++11/c++11-nullptr-strongly-typed-enum-class.html
>
> enum Color {RED, GREEN, BLUE};
>
> http://www.learncpp.com/cpp-tutorial/45-enumerated-types/
> enum Color
> {
> RED,
> BLUE, // BLUE is put into the global namespace
> GREEN
> };
>
> #########################
>
> So many use that syntax. But am still not sure which one to use

My advice is don't scream - I don't even do it for macros. The only
time I use all-caps is for macros that get defined on the command line
(such as "gcc -DDEBUG=1").

[Öö Tiib]

Yes, I have also noticed that many use screaming caps for constants
and enumerators but I do not understand what is the reason. I would feel
like Loud Howard from Dilbert when screaming GREEN and that is not
good feeling. Therefore I capitalize just the first letter of types
and constants. Syntax highlighting of code editor typically can color
types and constants differently so there are no ambiguity.

[Öö Tiib]

On Saturday, 23 January 2016 14:32:36 UTC+2, David Brown wrote:
> On 23/01/16 13:23, JiiPee wrote:
> > On 23/01/2016 12:00, Öö Tiib wrote:
> >> Other thing about syntax. IMHO code that screams HERE_IS_MACRO is fine,
> >> because macros should be avoided and if not avoided then readers should
> >> be warned about these. The DOG and CAT are not macros so why you suggest
> >> to scream there?
>
> Macros should not be avoided, nor are they something to panic about and
> warn people "HERE BE DRAGONS". They are a tool in the toolbox - if you
> use them properly and appropriately, they are perfect safe, functional
> and useful - and they don't need special treatment.

Macros have numerous weaknesses compared to functions or constants.
C++11/C++14 added features (like 'constexpr' functions) to further reduce
the scope of usefulness of macros in C++ and I consider it good thing.
There are indeed nothing to panic about those weaknesses but ... macros
may have hard to realize effects, do not have namespace or scope, are
difficult to debug etc. So if there is alternative to macro then it is
usually cheaper to make, to use and to maintain. That is plenty of reason
to avoid macros where possible and to warn readers that such weak text
substitution thing was used where it isn't possible.

[Jorgen Grahn]

On Sat, 2016-01-23, JiiPee wrote:

Or maybe if there isn't move semantics we do it anyway, because it's
now the normal way to do things, not just something which happens to
be efficient for small objects.

[Jorgen Grahn]

On Sat, 2016-01-23, 嘱 Tiib wrote:
...

> Other thing about syntax. IMHO code that screams HERE_IS_MACRO is fine,
> because macros should be avoided and if not avoided then readers should
> be warned about these. The DOG and CAT are not macros so why you suggest
> to scream there?

People interpret the all-caps thing differently. To you it says
HERE_IS_MACRO; for others (like me) it says HERE_IS_A_CONSTANT. That
split probably happened (without anyone noticing) in C in the 1980s.

I concede that your view won in some sense ... but personally I still
haven't made the switch, and I suspect there are a lot of people like
me. One of the many obstacles in our line of work ...

[JiiPee]

sure , especially if the returned object is small and there is no need
to maximize speed there. I personally do not see any reason to optimize
such small things (unless there is a real need for speed). Also, there
is also an option to add the move semantics later on if speed is needed
I guess. so returning by value is fixable later on easily like that if
speed is needed.

[David Brown]

On 23/01/16 14:32, 嘱 Tiib wrote:
> On Saturday, 23 January 2016 14:32:36 UTC+2, David Brown wrote:
>> On 23/01/16 13:23, JiiPee wrote:

>>> On 23/01/2016 12:00, 嘱 Tiib wrote:
>>>> Other thing about syntax. IMHO code that screams HERE_IS_MACRO is fine,
>>>> because macros should be avoided and if not avoided then readers should
>>>> be warned about these. The DOG and CAT are not macros so why you suggest
>>>> to scream there?
>>
>> Macros should not be avoided, nor are they something to panic about and
>> warn people "HERE BE DRAGONS". They are a tool in the toolbox - if you
>> use them properly and appropriately, they are perfect safe, functional
>> and useful - and they don't need special treatment.
>
> Macros have numerous weaknesses compared to functions or constants.

Yes, that's true. So don't use macros where a constant, or constexpr,
or static inline function, or templated function, would be a better choice.

That leaves you with using macros where macros are the best choice.

It is no different from using any feature in any language - when there
is more than one way to achieve the result, use the "best" method
available for whatever criteria of "best" you think is most appropriate.

> C++11/C++14 added features (like 'constexpr' functions) to further reduce
> the scope of usefulness of macros in C++ and I consider it good thing.
> There are indeed nothing to panic about those weaknesses but ... macros
> may have hard to realize effects, do not have namespace or scope, are
> difficult to debug etc. So if there is alternative to macro then it is
> usually cheaper to make, to use and to maintain. That is plenty of reason
> to avoid macros where possible and to warn readers that such weak text
> substitution thing was used where it isn't possible.
>

If you have used macros appropriately, they are not dangerous or weak.
If you use them /inappropriately/, they can quickly be risky. We all
know about potential problems from macros like these:

#define maxValue 10*2000
#define square(x) ((x) * (x))
#define show(x) showDecimal(x); showHex(x)

But the solution is not to give macros names in all-caps to show we are
using a risky feature - the solution is not to write or use bad macros,
thus avoiding using the feature in a risky manner!

[Alf P. Steinbach]

On 1/23/2016 5:55 PM, David Brown wrote:
> We all know about potential problems from macros like these:
>
> #define maxValue 10*2000
> #define square(x) ((x) * (x))
> #define show(x) showDecimal(x); showHex(x)
>
> But the solution is not to give macros names in all-caps to show we are
> using a risky feature - the solution is not to write or use bad macros,
> thus avoiding using the feature in a risky manner!

The reason for the common [1]all uppercase naming convention for macros
is not to make risky macros more evident to the source code reader, but
mainly to reduce the risk of inadvertent text substitution, and secondly
to make the macros less sexy, more of an eyesore, and keep this ugly
convention for names that should not be much used, instead of having it
applied to names that are much used such as constants.

I.e., if it were intentional then the above would be a [2]classic Straw
Man fallacy.

Lowercase macro names can work when the source code is pretty small. And
we've inherited a few such from the early C days, including `assert` and
`errno` (in C++ the latter is guaranteed to be a macro, e.g. C++11
§19.4/1). But as the source code size increases, so does the risk of
unintended substitutions, and modern code gets large fast.

Cheers & hth.,

- Alf

Notes:
[1] See e.g. <url: http://www.stroustrup.com/bs_faq2.html#macro>
[2] See e.g. <url: http://www.nizkor.org/features/fallacies/straw-man.html>

[JiiPee]

On 23/01/2016 17:51, Alf P. Steinbach wrote:
> and secondly to make the macros less sexy, more of an eyesore, and
> keep this ugly convention for names that should not be much used,
> instead of having it applied to names that are much used such as
> constants.

this is how I also think. its like static_cast.

[Mr Flibble]

On 23/01/2016 16:55, David Brown wrote:

> On 23/01/16 14:32, Öö Tiib wrote:
>> On Saturday, 23 January 2016 14:32:36 UTC+2, David Brown wrote:
>>> On 23/01/16 13:23, JiiPee wrote:

>>>> On 23/01/2016 12:00, Öö Tiib wrote:
>>>>> Other thing about syntax. IMHO code that screams HERE_IS_MACRO is
>>>>> fine,
>>>>> because macros should be avoided and if not avoided then readers
>>>>> should
>>>>> be warned about these. The DOG and CAT are not macros so why you
>>>>> suggest
>>>>> to scream there?
>>>
>>> Macros should not be avoided, nor are they something to panic about and
>>> warn people "HERE BE DRAGONS". They are a tool in the toolbox - if you
>>> use them properly and appropriately, they are perfect safe, functional
>>> and useful - and they don't need special treatment.
>>
>> Macros have numerous weaknesses compared to functions or constants.
>
> Yes, that's true. So don't use macros where a constant, or constexpr,
> or static inline function, or templated function, would be a better choice.
>
> That leaves you with using macros where macros are the best choice.
>
> It is no different from using any feature in any language - when there
> is more than one way to achieve the result, use the "best" method
> available for whatever criteria of "best" you think is most appropriate.

"Macros should be avoided" is good *general* advice given their
associated problems sausages.

/Flibble

[Ian Collins]

We could do that before C++11 thanks to RVO.

--
Ian Collins

[Chris Vine]

On Sat, 23 Jan 2016 17:55:29 +0100
David Brown <david...@hesbynett.no> wrote:
[snip]

> If you have used macros appropriately, they are not dangerous or
> weak. If you use them /inappropriately/, they can quickly be risky.
> We all know about potential problems from macros like these:
>
> #define maxValue 10*2000
> #define square(x) ((x) * (x))
> #define show(x) showDecimal(x); showHex(x)
>
> But the solution is not to give macros names in all-caps to show we
> are using a risky feature - the solution is not to write or use bad
> macros, thus avoiding using the feature in a risky manner!

The issue is not just avoiding macros when straightforward text
substitution may give the wrong results in certain contexts. The
problem is that the macro/definition names are unscoped and
unnamespaceable (is that a word?), so they merit attention being given
to them by using capitals, and they ought also to be prefixed as a
substitute for a namespace.

One example is from Qt. Their 'emit', 'signal' and 'slot' keywords are
macros, and they are an abomination. They break boost, for example.
The workaround that the Qt library provides is the option is to disable
the unprefixed lower case macros and substitute for them upper case
prefixed macro names.

Chris

[Öö Tiib]

On Saturday, 23 January 2016 17:17:14 UTC+2, Jorgen Grahn wrote:

> On Sat, 2016-01-23, Öö Tiib wrote:
> ...
> > Other thing about syntax. IMHO code that screams HERE_IS_MACRO is fine,
> > because macros should be avoided and if not avoided then readers should
> > be warned about these. The DOG and CAT are not macros so why you suggest
> > to scream there?
>
> People interpret the all-caps thing differently. To you it says
> HERE_IS_MACRO; for others (like me) it says HERE_IS_A_CONSTANT. That
> split probably happened (without anyone noticing) in C in the 1980s.

The constants are actually safest thing in programming. Constants are
immutable and lack life-time so thread-safe, exception-safe and
whatever-else-safe. So being loud about those feels inappropriate.
That would be still only matter of taste if it was the only reason.

>
> I concede that your view won in some sense ... but personally I still
> haven't made the switch, and I suspect there are a lot of people like
> me. One of the many obstacles in our line of work ...

Seems so that mine side has collected more votes over time, sorry.

First time I took a rule to coding standard that all macros must be
capitalized and no non-macros should be capitalized was somewhere 1998
when <windows.h> screwed up the 'std::numeric_limits<T>::max()' with its
'min' and 'max' macros in one code-base. It was pain because some other
Microsoft header used was using those macros. Therefore I felt that
making unique difference in naming of macros is important in practice and
it is not only matter of taste.

[Öö Tiib]

On Sunday, 24 January 2016 02:29:00 UTC+2, Öö Tiib wrote:
>
> First time I took a rule to coding standard that all macros must be

> capitalized and no non-macros should be capitalized ...

Perhaps the correct English term is "all caps" not "capitalized"? Does
latter mean only first letter made capital letter in English?

[Öö Tiib]

On Saturday, 23 January 2016 18:55:54 UTC+2, David Brown wrote:
> On 23/01/16 14:32, 嘱 Tiib wrote:
> > On Saturday, 23 January 2016 14:32:36 UTC+2, David Brown wrote:
> >> On 23/01/16 13:23, JiiPee wrote:
> >>> On 23/01/2016 12:00, 嘱 Tiib wrote:
> >>>> Other thing about syntax. IMHO code that screams HERE_IS_MACRO is fine,
> >>>> because macros should be avoided and if not avoided then readers should
> >>>> be warned about these. The DOG and CAT are not macros so why you suggest
> >>>> to scream there?
> >>
> >> Macros should not be avoided, nor are they something to panic about and
> >> warn people "HERE BE DRAGONS". They are a tool in the toolbox - if you
> >> use them properly and appropriately, they are perfect safe, functional
> >> and useful - and they don't need special treatment.
> >
> > Macros have numerous weaknesses compared to functions or constants.
>
> Yes, that's true. So don't use macros where a constant, or constexpr,
> or static inline function, or templated function, would be a better choice.
>
> That leaves you with using macros where macros are the best choice.
>
> It is no different from using any feature in any language - when there
> is more than one way to achieve the result, use the "best" method
> available for whatever criteria of "best" you think is most appropriate.

I trust we agree. I mean "to avoid" not in sense that to avoid like dragon
or plague but like usually poorer choice from the alternatives if there
are any. Sometimes there are no alternatives like when some name of
variable or enumerator needs to be stringized and so on.

>
> > C++11/C++14 added features (like 'constexpr' functions) to further reduce
> > the scope of usefulness of macros in C++ and I consider it good thing.
> > There are indeed nothing to panic about those weaknesses but ... macros
> > may have hard to realize effects, do not have namespace or scope, are
> > difficult to debug etc. So if there is alternative to macro then it is
> > usually cheaper to make, to use and to maintain. That is plenty of reason
> > to avoid macros where possible and to warn readers that such weak text
> > substitution thing was used where it isn't possible.
> >
>
> If you have used macros appropriately, they are not dangerous or weak.
> If you use them /inappropriately/, they can quickly be risky. We all
> know about potential problems from macros like these:
>
> #define maxValue 10*2000
> #define square(x) ((x) * (x))
> #define show(x) showDecimal(x); showHex(x)
>
> But the solution is not to give macros names in all-caps to show we are
> using a risky feature - the solution is not to write or use bad macros,
> thus avoiding using the feature in a risky manner!

The issue with naming is not because of actually defective or dangerous
implementations of macros but because there is limited supply of
meaningful short names and so it is easier when macros have unique
naming scheme that no other names use.

[David Brown]

On 23/01/16 18:51, Alf P. Steinbach wrote:
> On 1/23/2016 5:55 PM, David Brown wrote:
>> We all know about potential problems from macros like these:
>>
>> #define maxValue 10*2000
>> #define square(x) ((x) * (x))
>> #define show(x) showDecimal(x); showHex(x)
>>
>> But the solution is not to give macros names in all-caps to show we are
>> using a risky feature - the solution is not to write or use bad macros,
>> thus avoiding using the feature in a risky manner!
>
> The reason for the common [1]all uppercase naming convention for macros
> is not to make risky macros more evident to the source code reader, but
> mainly to reduce the risk of inadvertent text substitution, and secondly
> to make the macros less sexy, more of an eyesore, and keep this ugly
> convention for names that should not be much used, instead of having it
> applied to names that are much used such as constants.
>
> I.e., if it were intentional then the above would be a [2]classic Straw
> Man fallacy.
>
> Lowercase macro names can work when the source code is pretty small. And
> we've inherited a few such from the early C days, including `assert` and
> `errno` (in C++ the latter is guaranteed to be a macro, e.g. C++11
> §19.4/1). But as the source code size increases, so does the risk of
> unintended substitutions, and modern code gets large fast.
>
>

Why should there be any "inadvertent text substitution" ? Use macros
where appropriate, and in a way that is appropriate - don't use them
when they are not appropriate, and don't define them badly.

Using all-caps for macros is just pandering to bad programmers and bad
code. We should aim to weed out such bad code, not make it stand out.

[David Brown]

The appropriate "good general advice" here is "use the most suitable
language feature for the job". Often, that is /not/ macros. And with
each generation of C++, the number of cases where macros are the best
choice has decreased. So certainly macro usage should be rare - but
/not/ because they are macros, merely because templates, constant
expressions, strong enumerations, inline functions, etc., are usually a
better choice.

[Paavo Helde]

On 24.01.2016 2:36, 嘱 Tiib wrote:

> On Sunday, 24 January 2016 02:29:00 UTC+2, 嘱 Tiib wrote:
>>
>> First time I took a rule to coding standard that all macros must be
>> capitalized and no non-macros should be capitalized ...
>
> Perhaps the correct English term is "all caps" not "capitalized"? Does
> latter mean only first letter made capital letter in English?

Interestingly enough, online dictionaries define "capitalize" as "write
in capital letters or with an initial capital letter", but "capitalise"
as "write in capital letters" only. See e.g.
http://www.memidex.com/capitalise where both definitions appear in the
same page. I have no idea if there is indeed a difference in the meaning
or not.

[David Brown]

On 23/01/16 22:08, Chris Vine wrote:
> On Sat, 23 Jan 2016 17:55:29 +0100
> David Brown <david...@hesbynett.no> wrote:
> [snip]
>> If you have used macros appropriately, they are not dangerous or
>> weak. If you use them /inappropriately/, they can quickly be risky.
>> We all know about potential problems from macros like these:
>>
>> #define maxValue 10*2000
>> #define square(x) ((x) * (x))
>> #define show(x) showDecimal(x); showHex(x)
>>
>> But the solution is not to give macros names in all-caps to show we
>> are using a risky feature - the solution is not to write or use bad
>> macros, thus avoiding using the feature in a risky manner!
>
> The issue is not just avoiding macros when straightforward text
> substitution may give the wrong results in certain contexts. The
> problem is that the macro/definition names are unscoped and
> unnamespaceable (is that a word?), so they merit attention being given
> to them by using capitals, and they ought also to be prefixed as a
> substitute for a namespace.
>

No, they merit being given names that don't conflict with other names.
That is all.

Making macros, and only macros, all-caps is one way to avoid conflicts.
But it is neither necessary nor sufficient. It does nothing to stop
collisions between macro names, nor do you need to use all-caps to avoid
collisions.

This is no more and no less than the same namespace collision issues
that have always existed. For non-macro symbols, encapsulation in
classes and then namespaces have reduced the problem - or rather, pushed
it to a larger scale, allowing people to build bigger and bigger
programs while keeping control of their namespaces. Macros have not
benefited from this namespace scaling - this is a clear disadvantage.
But that does not mean that making them "shout" is a good answer.

> One example is from Qt. Their 'emit', 'signal' and 'slot' keywords are
> macros, and they are an abomination. They break boost, for example.

Qt is quite invasive - it is, in some ways, an extension to C++. If you
treat emit, signal and slot as keywords, then you have no problem.
Obviously that is going to be a problem for code that uses the same
identifiers for different purposes.

[David Brown]

Yes, I think we agree there. My point is that macros are not evil.
Sometimes they are very useful, but often there are better ways to
handle the problem at hand.

>
>>
>>> C++11/C++14 added features (like 'constexpr' functions) to further reduce
>>> the scope of usefulness of macros in C++ and I consider it good thing.
>>> There are indeed nothing to panic about those weaknesses but ... macros
>>> may have hard to realize effects, do not have namespace or scope, are
>>> difficult to debug etc. So if there is alternative to macro then it is
>>> usually cheaper to make, to use and to maintain. That is plenty of reason
>>> to avoid macros where possible and to warn readers that such weak text
>>> substitution thing was used where it isn't possible.
>>>
>>
>> If you have used macros appropriately, they are not dangerous or weak.
>> If you use them /inappropriately/, they can quickly be risky. We all
>> know about potential problems from macros like these:
>>
>> #define maxValue 10*2000
>> #define square(x) ((x) * (x))
>> #define show(x) showDecimal(x); showHex(x)
>>
>> But the solution is not to give macros names in all-caps to show we are
>> using a risky feature - the solution is not to write or use bad macros,
>> thus avoiding using the feature in a risky manner!
>
> The issue with naming is not because of actually defective or dangerous
> implementations of macros but because there is limited supply of
> meaningful short names and so it is easier when macros have unique
> naming scheme that no other names use.
>

That makes some sense - except that all-caps is a particularly ugly
naming scheme because it stands out so much. I also think it is wrong
to use a naming scheme for macros, when they are there to duplicate or
replace other code.

For example, you might be perfectly happy with a global constant:

static const int biggestNumber = 42;

If you need "biggestNumber" to be a macro - perhaps it depends on a
command-line parameter macro - why not write:

#define biggestNumber 42

You want to be able to use the macro version of "biggestNumber" in the
same way, and the same contexts, as the static const version. It
doesn't make any sense to me that you should rename it to BIGGEST_NUMBER.

[Paavo Helde]

'static' is redundant here, namespace-scope 'const' already implies
internal linking in C++.

And no, I would not be happy with this constant if it is not placed
inside a specific namespace.

>
> If you need "biggestNumber" to be a macro - perhaps it depends on a
> command-line parameter macro - why not write:
>
> #define biggestNumber 42

This is much worse as now the definition is not contained/confined in
any namespace.

There is no need to use macros for constants in C++, whether in all-caps
or not.

> You want to be able to use the macro version of "biggestNumber" in the
> same way, and the same contexts, as the static const version.

But I can't. I cannot use it in another namespace which defines
biggestNumber.

> It
> doesn't make any sense to me that you should rename it to BIGGEST_NUMBER.

No, you should not rename it to BIGGEST_NUMBER, but to
SPECIFICPRODUCTNAME_BIGGEST_NUMBER. Cf. BOOST_STATIC_ASSERT,
BOOST_LIB_TOOLSET etc. This is all about avoiding the conflicts. And the
convention to use special spelling for macros also helps to reduce
conflicts, just because the rest of the code does not use them. In this
sense using all-caps for enum values is an anti-pattern as it increases
the chance of conflicts.

Cheers
Paavo

[Alf P. Steinbach]

On 1/24/2016 12:28 PM, David Brown wrote:
> On 23/01/16 18:51, Alf P. Steinbach wrote:
>>
>> Lowercase macro names can work when the source code is pretty small. And
>> we've inherited a few such from the early C days, including `assert` and
>> `errno` (in C++ the latter is guaranteed to be a macro, e.g. C++11
>> §19.4/1). But as the source code size increases, so does the risk of
>> unintended substitutions, and modern code gets large fast.
>>
>
> Why should there be any "inadvertent text substitution" ?

Sorry, I fail to understand that question. It /sounds/ like a
rhetorical question meant to indicate that you know of a way to avoid
the problem, and that you're next going to describe that way.

> Use macros
> where appropriate, and in a way that is appropriate - don't use them
> when they are not appropriate, and don't define them badly.

But this is not a description of a way to avoid the problem.

> Using all-caps for macros is just pandering to bad programmers and bad
> code. We should aim to weed out such bad code, not make it stand out.

I.e., the Boost programmers, including e.g. Dave Abrahams, are in your
opinion “bad programmers”, producing “bad code”. Hm. I think this
argument, which involves some /name calling/, is very unconvincing.

• • •

There is, however, an alternative for those who don't want to use the
all uppercase convention for macros. Namely, Herb Sutter's advice [1]“If
you have to write a macro, try to give it an unusual and hard-to-spell
name that will be less likely to tromp on other names.”.

The all uppercase convention serves that uniqueness purpose in a simple
way, usually combined with some short namespace-like prefix.

When you don't use the all uppercase macro name convention you have to
compensate with e.g. less collision-likely longer prefixes or suffixes,
which approach reduces readability, but is a technical possibility.

Cheers & hth.,

- Alf

Notes:

[1] <url: http://www.gotw.ca/gotw/077.htm>

[Alf P. Steinbach]

On 1/24/2016 1:06 PM, David Brown wrote:
>
> For example, you might be perfectly happy with a global constant:
>
> static const int biggestNumber = 42;
>
> If you need "biggestNumber" to be a macro - perhaps it depends on a
> command-line parameter macro - why not write:
>
> #define biggestNumber 42
>
> You want to be able to use the macro version of "biggestNumber" in the
> same way, and the same contexts, as the static const version. It
> doesn't make any sense to me that you should rename it to BIGGEST_NUMBER.

Defined macro names are few, defined ordinary names are legio.

So there is much higher probability that the name `biggestNumber` is in
use in some other part code, than that the name `BIGGEST_NUMBER` or, as
would be natural, `SOMEPREFIX_BIGGEST_NUMBER`, is in use or will later
be in use in some other part code, possibly in 3rd party library code
that you don't control.

This is all about improving the odds, not about any absolute certainty.

[Jerry Stuckle]

I don't understand this statement. C is case sensitive - take advantage
of that fact. Using all upper case for macro names and #defined
constants clarifies what they are and means you won't have "inadvertent
text substitution". It also makes the code easier to maintain because
one doesn't have to look through every included file (and every file
THOSE include) to see if there might be a clash with a new variable or
function you have to define.

I would submit that NOT using all of the features of C (including case
sensitivity) is "just pandering to bad programmers and bad code."

You may not like it - but it's a long-established practice in both C and
C++, and for very good reasons.

--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================

[Mr Flibble]

Again that simply means that "macros should be avoided" is good
*general* advice; I know of at least one safety critical C++ coding
standard that actually prohibits the use of macros sausages.

/Flibble

[Jerry Stuckle]

OK, now what happens when, while modifying the code, I want to add
something like:

int biggestNumber(int * array, int size) {
...
}

Which finds the largest number in an array? According to you, I need to
look through every included header and every header those include to
ensure I don't have a conflict.

[Chris Vine]

On Sun, 24 Jan 2016 12:57:35 +0100

David Brown <david...@hesbynett.no> wrote:
[snip]

> Making macros, and only macros, all-caps is one way to avoid
> conflicts. But it is neither necessary nor sufficient. It does
> nothing to stop collisions between macro names, nor do you need to
> use all-caps to avoid collisions.

You are missing the point. If you use all-caps for preprocessor names
and for nothing else then you isolate the name clash risk for macro
names to the preprocessor only. Then, as I previously said, you use a
prefix to avoid name clashes within what has become the macro namespace.

This is very well established practice, and for good reason. It is by
convention the way to do it, and arguing about it is just silly in my
opinion.

Chris

[David Brown]

On 24/01/16 14:06, Alf P. Steinbach wrote:
> On 1/24/2016 12:28 PM, David Brown wrote:
>> On 23/01/16 18:51, Alf P. Steinbach wrote:
>>>
>>> Lowercase macro names can work when the source code is pretty small. And
>>> we've inherited a few such from the early C days, including `assert` and
>>> `errno` (in C++ the latter is guaranteed to be a macro, e.g. C++11
>>> §19.4/1). But as the source code size increases, so does the risk of
>>> unintended substitutions, and modern code gets large fast.
>>>
>>
>> Why should there be any "inadvertent text substitution" ?
>
> Sorry, I fail to understand that question. It /sounds/ like a
> rhetorical question meant to indicate that you know of a way to avoid
> the problem, and that you're next going to describe that way.
>
>
>> Use macros
>> where appropriate, and in a way that is appropriate - don't use them
>> when they are not appropriate, and don't define them badly.
>
> But this is not a description of a way to avoid the problem.

What problem? "Inadvertent text substitution" just means "I've made a
mistake in my coding that happens to involve a macro", as far as I can
see. It is not fundamentally different from any other kind of mistake.

Now, I am all in favour of programming habits that reduce the risk of
mistakes - and I am quite happy with "don't use macros unless they make
a significant benefit to the code" as such a habit.

What I /don't/ see is the idea that macros are so specially bad that it
is appropriate to disrupt the flow of the code and make them stand out
above all other identifiers.

>
>
>> Using all-caps for macros is just pandering to bad programmers and bad
>> code. We should aim to weed out such bad code, not make it stand out.
>
> I.e., the Boost programmers, including e.g. Dave Abrahams, are in your
> opinion “bad programmers”, producing “bad code”. Hm. I think this
> argument, which involves some /name calling/, is very unconvincing.
>

If these folks /need/ to use all-caps names for macros, then they are
doing something wrong.

Namespace collisions happen. It's almost inevitable. Macros certainly
don't help the matter because they don't follow scope rules, but they
are not the only type of collision possible.

The way to avoid problems with namespace collisions (through macros or
anything else) is, I think, threefold. First, make sure that your
library/header suppliers know what they are doing, and don't use common
names for anything in a wider scope than necessary. This applies to
macros, but it also applies to global functions, types, enumerators,
etc., just as much. Second, make sure that /you/ know what you are
doing, and understand what symbols exist at the different scopes and
namespaces you are using. Third, use tools (such as a good editor or
IDE) that help you get things right.

>
> There is, however, an alternative for those who don't want to use the
> all uppercase convention for macros. Namely, Herb Sutter's advice [1]“If
> you have to write a macro, try to give it an unusual and hard-to-spell
> name that will be less likely to tromp on other names.”.

That sounds like reasonable advice.

>
> The all uppercase convention serves that uniqueness purpose in a simple
> way, usually combined with some short namespace-like prefix.

I understand that. Naming conventions can be a useful thing, and
namespace-like prefixes are an age-old tool for this purpose.

My point is nothing more, and nothing less, than that an all-caps
convention is not necessary for macros, and that this convention
interferes with clear programming. I don't think macros as a class need
a naming convention. And I think that using all-caps encourages the
belief (not followed by everyone here) that macros are someone dangerous
and scary, and need to stand out so that they can be treated with
special care.

>
> When you don't use the all uppercase macro name convention you have to
> compensate with e.g. less collision-likely longer prefixes or suffixes,
> which approach reduces readability, but is a technical possibility.
>

It is all a balance, and will depend on the kind of code being written,
and the size of the project.

[David Brown]

Most C and C++ standards that I have seen - safety-critical or not -
discourage the use of macros. And I agree that where there are
alternatives, they are almost always a better idea. I would even list
"less need of macros" as one of the advantages of C++ over C. But there
are types of code problems which are best solved with macros - and if
they result in clearer and more reliable code, they are a good thing.

[Vir Campestris]

On 23/01/2016 11:34, Alf P. Steinbach wrote:
> avoids confronting a learner up-front with the (according to Kernighan
> and Stroustrup) failed syntax experiment of C and early C++

While C syntax is a mess I don't think we can call it failed. I'm still
writing it, 40 odd years later... though it does feel very painful
knowing C++ is available.

Andy

[JiiPee]

C was definitely top language in its time, 70-80 early (that would have
been my choice in 70 s, early 80 s). But I think C++ is then better,
especially the latest version.

[Robert Wessel]

On 25 Jan 2016 04:26:51 GMT, r...@zedat.fu-berlin.de (Stefan Ram)
wrote:

>"Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:
>>learner up-front with the (according to Kernighan and Stroustrup) failed

>>syntax experiment of C and early C++, which can be a barrier.
>
> What specific production(s) do you refer to?
>
> The most TIOBE-popular languages are: Java, C, C++, and C#.
> All based on the C syntax which insofar has prevailed in the
> evolution of languages. Even when today, in 2016, someone
> invents a new language, it is very probable that compound
> statements will start with a brace. (Which language was the
> first to do this?) I am teaching C to beginners, and so far
> no one has complained about the syntax. So both experts and
> beginners embrace braces.


C may be the first. BCPL used $( and $) (two character
sequences), and of course other languages did things like begin..end
much earlier. Some of that may simply be due to the character set
limitations of the era - before 1969 many machines simply didn't have
the curly braces available in a convenient way (and it certainly
wasn't universal for a long time after that - arguably not even now).

OTOH, languages like Lisp used parenthesis a lot, often for similar
block-structuring purposes.

[SG]

On Saturday, January 23, 2016 at 2:55:43 AM UTC+1, JiiPee wrote:
> In this thread/post you can tell what you like in C++11/C++14. How it
> made things nicer, how you use it and how it made those things easier.
> Why you like C++11/C++14 more than the old C++?

Apart from the obvious cool things (rvalue references, variadic
templates), I've just started to let go of classes and constructors to
some extent. For simple data-holding types I just use structs and
brace initialization:

struct foo {
double thiz;
std::string that;
};

void sink(foo);

foo source() {
return { 3.14159265, "pi" }; // Yay!
}

int main() {
sink({ 2.718281828, "e" }); // Yay!
}

The fact that I've been toying around with the Rust language probably
has something to do with this style. :)

I also like all the <type_traits> stuff. It's a stepping stone towards
concepts.

What I'm probably not appreciating enough right now is constexpr. I
know that constexpr functions were quite limited in C++11 but AFAIK
this has changed in C++14. But I don't really know its limitations
right now and what good things you can achieve using it.

Cheers!
sg

[Alf P. Steinbach]

On 1/25/2016 5:26 AM, Stefan Ram wrote:
> "Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:
>> learner up-front with the (according to Kernighan and Stroustrup) failed
>> syntax experiment of C and early C++, which can be a barrier.
>
> What specific production(s) do you refer to?
>
> The most TIOBE-popular languages are: Java, C, C++, and C#.
> All based on the C syntax which insofar has prevailed in the
> evolution of languages. Even when today, in 2016, someone
> invents a new language, it is very probable that compound
> statements will start with a brace. (Which language was the
> first to do this?)

Whether to use braces or begin/end keywords is not part of the
syntactical /structure/, which is what “syntax” refers to here.

One way to see that the form is irrelevant is by defining “begin”/“end”
macros and thus change the surface appearance of your code.

The block structure itself is, however, a part of the syntactical
structure. But it is a very successful, not a failed, part. It was
[1]introduced in Algol. C was based on BCPL, which as I recall had round
parenthesis blocks (today the Windows batch file language is one example
of a language with round parenthesis blocks). The block and control
structure of BCPL was based on CPL. Possibly CPLs variant was based
directly on Algol.

> I am teaching C to beginners, and so far
> no one has complained about the syntax.

It may be that these beginners do not know enough to judge it.

There are also other possible explanations of the lack of criticism.

> So both experts and beginners embrace braces.

Braces are not a problematic part, and as braces (as opposed to using
other block markers) they're not part of syntactic structure.

I referred to the language designers' very informed expert opinions of
their own syntax creations, in particular the declaration syntax. It may
be that I was wrong about exactly which C creator, I shouldn't so
casually have written Kernighan, but it's easy enough to google up
references where Bjarne Stroustrup, the C++ language creator, states
this, which he's done one several occasions. E.g. in [1]an interview
with the C User's Journal in 1996, Bjarne stated that “I consider the C
declaration syntax an experiment that failed”.

Surely the language creator must be considered an expert.

For that matter, I've been referred to as an expert.

But, by stressing that, I'm responding to what I perceive as the
associative impact of what you wrote. As far as I know it's not the case
that any experts are strongly opposed to curly braces or consider them a
failure. The braces, as braces, are just irrelevant here.

Cheers & hth.,

- Alf

Notes:
[1] <url: https://en.wikipedia.org/wiki/Block_%28programming%29#History>
[2] <url: http://www.stroustrup.com/cuj_interview.html>

[Jerry Stuckle]

I also have taught introductory C and C++ courses. These were to both
new and experienced programmers in corporate environments. None of them
had any criticism about the syntax, either. They accepted it and moved on.

>
>> So both experts and beginners embrace braces.
>
> Braces are not a problematic part, and as braces (as opposed to using
> other block markers) they're not part of syntactic structure.
>

How can you claim they are not part of the syntactic structure? They
are a major part of it.

> I referred to the language designers' very informed expert opinions of
> their own syntax creations, in particular the declaration syntax. It may
> be that I was wrong about exactly which C creator, I shouldn't so
> casually have written Kernighan, but it's easy enough to google up
> references where Bjarne Stroustrup, the C++ language creator, states
> this, which he's done one several occasions. E.g. in [1]an interview
> with the C User's Journal in 1996, Bjarne stated that “I consider the C
> declaration syntax an experiment that failed”.
>
> Surely the language creator must be considered an expert.
>

BJarne Stroustrup did not create C.

> For that matter, I've been referred to as an expert.
>

Anyone can be referred to as an expert by others. I have been referred
to as an expert by many of my students. That does not make me one. It
only means I knew more than they did.

> But, by stressing that, I'm responding to what I perceive as the
> associative impact of what you wrote. As far as I know it's not the case
> that any experts are strongly opposed to curly braces or consider them a
> failure. The braces, as braces, are just irrelevant here.
>
>
> Cheers & hth.,
>
> - Alf
>
> Notes:
> [1] <url: https://en.wikipedia.org/wiki/Block_%28programming%29#History>
> [2] <url: http://www.stroustrup.com/cuj_interview.html>
>

[Alf P. Steinbach]

On 1/25/2016 3:43 PM, Jerry Stuckle wrote:
>>
>>> I am teaching C to beginners, and so far
>>> no one has complained about the syntax.
>>
>> It may be that these beginners do not know enough to judge it.
>>
>> There are also other possible explanations of the lack of criticism.
>
> I also have taught introductory C and C++ courses. These were to both
> new and experienced programmers in corporate environments. None of them
> had any criticism about the syntax, either. They accepted it and moved on.

Not sure what you're talking about, it doesn't seem relevant to the
context (quoted above).

But if this is, like, from your point of view, a thread about what each
of us has done, I've taught C++ at college level, 20+ years ago, at then
Bodø College of Economics (now the University of Nordland) and to some
extent later at the corporate level. However, at the corporate level it
was mostly Java, which I didn't even know very much of at the time - but
the focus was not so much on the language. I helped (or mainly) create a
course for new employees in Andersen Consulting, now Accenture, called
“BEST”, which was short for “Building Enterprise Solutions and Testing”.
The nice thing about it was that it was first held in Nice, France. So I
got a sort of paid holiday. :)

>>> So both experts and beginners embrace braces.
>>
>> Braces are not a problematic part, and as braces (as opposed to using
>> other block markers) they're not part of syntactic structure.
>>
>
> How can you claim they are not part of the syntactic structure? They
> are a major part of it.

It seems that you're missing the points entirely (wilfully?).

Namely, first that braces as such are not part of the structure, they
are arbitrary symbol choices; and secondly, that the block structure is
not a failure; and third, that it didn't stem from C but from Algol.


[snip]

>> Surely the language creator must be considered an expert.
>
> BJarne Stroustrup did not create C.

To me that's completely mal-apropos. Bjarne did not head the Toyota
corporation, either. For example. Are you seriously contending that
Bjarne, creator of C++, did not know [2]what he was talking about in
1996? Jeez.


[snip]

> Anyone can be referred to as an expert by others. I have been referred
> to as an expert by many of my students. That does not make me one. It
> only means I knew more than they did.

Oh well.

>> Notes:
>> [1] <url: https://en.wikipedia.org/wiki/Block_%28programming%29#History>
>> [2] <url: http://www.stroustrup.com/cuj_interview.html>

Cheers & hth., even though I couldn't make much sense of what you wrote,

- Alf

[Jerry Stuckle]

On 1/25/2016 10:27 AM, Alf P. Steinbach wrote:
> On 1/25/2016 3:43 PM, Jerry Stuckle wrote:
>>>
>>>> I am teaching C to beginners, and so far
>>>> no one has complained about the syntax.
>>>
>>> It may be that these beginners do not know enough to judge it.
>>>
>>> There are also other possible explanations of the lack of criticism.
>>
>> I also have taught introductory C and C++ courses. These were to both
>> new and experienced programmers in corporate environments. None of them
>> had any criticism about the syntax, either. They accepted it and
>> moved on.
>
> Not sure what you're talking about, it doesn't seem relevant to the
> context (quoted above).
>

Then read ALL of the quoted text - including "I am teaching C to
beginners, ..." and "It may be that these beginners do not know enough
to judge it."

> But if this is, like, from your point of view, a thread about what each
> of us has done, I've taught C++ at college level, 20+ years ago, at then
> Bodø College of Economics (now the University of Nordland) and to some
> extent later at the corporate level. However, at the corporate level it
> was mostly Java, which I didn't even know very much of at the time - but
> the focus was not so much on the language. I helped (or mainly) create a
> course for new employees in Andersen Consulting, now Accenture, called
> “BEST”, which was short for “Building Enterprise Solutions and Testing”.
> The nice thing about it was that it was first held in Nice, France. So I
> got a sort of paid holiday. :)
>

I hate to say this, but I know of two people who taught at the college
level and moved to corporate teaching. Neither one could teach C or C++
in a week and eventually failed. College instructors are good at
teaching when they have a whole semester to deal with, but these two
didn't so so well teaching the same material in five days.

>
>>>> So both experts and beginners embrace braces.
>>>
>>> Braces are not a problematic part, and as braces (as opposed to using
>>> other block markers) they're not part of syntactic structure.
>>>
>>
>> How can you claim they are not part of the syntactic structure? They
>> are a major part of it.
>
> It seems that you're missing the points entirely (wilfully?).
>
> Namely, first that braces as such are not part of the structure, they
> are arbitrary symbol choices; and secondly, that the block structure is
> not a failure; and third, that it didn't stem from C but from Algol.
>

They are very much part of the syntactical structure. Whether they are
arbitrary symbol choices or not is immaterial; one could say '*' is an
"arbitrary symbol choice" for multiplications, for instance.

I never said the block structure was a failure; just that my students
never had a problem with the usage of braces. And they did stem from C;
C++ was built on C, starting with Stroustrups's first paper in the 70's
on "C with Objects". The fact C may have taken them from Algol is
immaterial; C++ is not built on Algol.

>
> [snip]
>>> Surely the language creator must be considered an expert.
>>
>> BJarne Stroustrup did not create C.
>
> To me that's completely mal-apropos. Bjarne did not head the Toyota
> corporation, either. For example. Are you seriously contending that
> Bjarne, creator of C++, did not know [2]what he was talking about in
> 1996? Jeez.
>

You snipped an important part here. I will remind you:

>>> E.g. in [1]an interview with the C User's Journal in 1996, Bjarne
>>> stated that “I consider the C declaration syntax an experiment that
>>> failed”.

>>> Surely the language creator must be considered an expert."

Bjarne Stroustup did not create C.

>
> [snip]
>> Anyone can be referred to as an expert by others. I have been referred
>> to as an expert by many of my students. That does not make me one. It
>> only means I knew more than they did.
>
> Oh well.
>
>
>>> Notes:
>>> [1] <url: https://en.wikipedia.org/wiki/Block_%28programming%29#History>
>>> [2] <url: http://www.stroustrup.com/cuj_interview.html>
>
>
> Cheers & hth., even though I couldn't make much sense of what you wrote,
>
> - Alf
>

It figures.

[Alf P. Steinbach]

On 1/25/2016 6:31 PM, Jerry Stuckle wrote:
>
> I hate to say this, but I know of two people who taught at the college
> level and moved to corporate teaching. Neither one could teach C or C++
> in a week and eventually failed. College instructors are good at
> teaching when they have a whole semester to deal with, but these two
> didn't so so well teaching the same material in five days.

You're right, I could certainly not teach C++ in a week.

I'm still learning, and as you may have surmised, I've used the language
since the early 1990s.

The facts and logic etc. that we dumb people who can't teach C++ in a
week, offer, must just be disregarded, ignored.

[Alf P. Steinbach]

On 1/25/2016 6:46 PM, Stefan Ram wrote:
> "Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:
>> with the C User's Journal in 1996, Bjarne stated that ''I consider the C
>> declaration syntax an experiment that failed''.
>

> I wonder how those that say that it has failed would then
> prefer to declare f below, instead of
>
> int (*f(int (*)(long), int))(int, ...);

It's a good example of one aspect of the failure, that the syntax
doesn't work with the ordinary idea of substitution.

This failure aspect is what's caused the numerous questions from
learners about the syntax, and the ditto numerous web sites trying to
explain how to analyze and synthesize declarations.

Another aspect is that not all declarations can even be expressed
without naming some parts. Don't ask me for an example, I can't cough it
up, but I remember some SO questions about it, where I think mainly the
examples had to do with member functions. It's the most abject failure
ever, that the syntax can't even express all possibilities.

However, any good programmer would /name/ things, to enable substitution.

And I suspect that Bjarne would name the concrete types here, although
instead of C++11 trailing return type he'd probably use C++03 syntax:

using Arg_function = auto( long ) -> int;
using Referred_function = auto( int, ... ) -> int;

auto f( Arg_function*, int)
-> Referred_function*;

I would, since some months ago, also or alternatively use named type
builders, e.g., like this without naming any concrete types:

// In some header that's included:
template< class Some_type >
using Type_ = Some_type;

template< class Some_type >
using Ptr_ = Some_type*;

// Directly in one's own application code:
auto g( Ptr_<Type_<auto( long )->int>>, int)
-> Ptr_<Type_<auto( int,... )->int>>;

Not sure yet if that's so verbose that it defeats the purpose. It's
certainly, like the C syntax, so alien at first sight that it might look
incomprehensible! But at least it's directly readable, and works with
the substitution principle, neither of which the C syntax does.


> , or - for another example - p, instead of
>
> int *(*(*p)())[5]

Now you try it. :-)


> IIRC, Ritchie said about C something link »it's quite all right,
> though some operators have the wrong precedence«.
>
> Syntax, of course, is the set of all programs, while
> semantics determine the meaning of a programs. The
> description of the syntax is called »grammar«. The
> grammar usually is given in the form of some variant
> of EBNF.

I'm sorry, my google-foo fails me. I shouldn't have mentioned it. Enough
with the Bjarne quote (he also considers exception specifications a
failure, and indeed they were removed), and the evidence of all the
questions and explanations, + your examples.


Cheers!,

- Alf

[Alf P. Steinbach]

On 1/25/2016 10:08 PM, Alf P. Steinbach wrote:
> I would, since some months ago, also or alternatively use named type
> builders, e.g., like this without naming any concrete types:
>
> // In some header that's included:
> template< class Some_type >
> using Type_ = Some_type;
>
> template< class Some_type >
> using Ptr_ = Some_type*;
>
> // Directly in one's own application code:
> auto g( Ptr_<Type_<auto( long )->int>>, int)
> -> Ptr_<Type_<auto( int,... )->int>>;
>
> Not sure yet if that's so verbose that it defeats the purpose. It's
> certainly, like the C syntax, so alien at first sight that it might look
> incomprehensible! But at least it's directly readable, and works with
> the substitution principle, neither of which the C syntax does.
>

Oh, I was stupid, all right.

That should instead be just

auto g( Ptr_<auto(long)->int>, int)
-> Ptr_<auto(int,...)->int>;

Or, taking advantage of automatic decay to pointer type, just

auto g( auto(long)->int, int)
-> Ptr_<auto(int,...)->int>;

But I feel that that last one is inconsistent in a way, when comparing
the formal argument type and the result type.

Anyway, no wonder I felt that the example I gave was too verbose!
Somehow I didn't notice the redundancy, I just mechanically, in a way,
translated from C syntax. Hm!


Cheers,

- Alf

[Jerry Stuckle]

Alf,

I didn't say YOU couldn't teach C++ in a week. All I said was the two
people I know who were university instructors could not teach it in a week.

But since you admit you can't do it, I guess you can't. There are a
number of other instructors whom I know are quite capable of doing it.
And they have done it on Europe, North America and Asia, as I have.

[Jerry Stuckle]

On 1/25/2016 3:42 PM, Stefan Ram wrote:
> "Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:

>> I could certainly not teach C++ in a week.
>

> One cannot teach C++ in a week, and one cannot teach C++
> in one semester.
>

That's where you're wrong. Corporations require courses no more than a
week long.

> What one can teach is a selection of C++ (a subset of all
> that one could say about C++).
>

One can teach the syntax and theory of C++ and OOP. I didn't say the
students were experts coming out of the class. But they are productive.

> The choice of that subset depends on several factors that
> include the length of the course.
>

Corporate courses can be no longer than one week (about 37.5 hours).
And there are numerous companies around the world which satisfy this
requirement. It can, and is being done.

[David Brown]

On 26/01/16 02:21, Jerry Stuckle wrote:
> On 1/25/2016 3:31 PM, Alf P. Steinbach wrote:
>> On 1/25/2016 6:31 PM, Jerry Stuckle wrote:
>>>
>>> I hate to say this, but I know of two people who taught at the college
>>> level and moved to corporate teaching. Neither one could teach C or C++
>>> in a week and eventually failed. College instructors are good at
>>> teaching when they have a whole semester to deal with, but these two
>>> didn't so so well teaching the same material in five days.
>>
>> You're right, I could certainly not teach C++ in a week.
>>
>> I'm still learning, and as you may have surmised, I've used the language
>> since the early 1990s.
>>
>> The facts and logic etc. that we dumb people who can't teach C++ in a
>> week, offer, must just be disregarded, ignored.
>>
>>
>> Cheers & hth.,
>>
>> - Alf
>>
>
> Alf,
>
> I didn't say YOU couldn't teach C++ in a week. All I said was the two
> people I know who were university instructors could not teach it in a week.
>

Jerry, you are very good at /saying/ one thing, and /implying/ something
very different.

From what you wrote and the way you wrote it, your message and thought
process was clear:

1. You know two people who taught programming at college, and failed to
teach it to companies.

2. Therefore everyone who teaches at college will fail at teaching to
companies.

3. Alf taught at college then moved to teaching to companies.

4. Therefore Alf is a bad teacher.

5. Therefore you win the argument.


I assume that you don't intend to come across as patronising and
insulting, but that's how it reads to me. I'm sure Alf has the
self-confidence to know that he is a good teacher (judging from his vast
number of helpful posts in this group over the years), and will not be
bothered by your attitude - but as a bystander, it irritates me.

> But since you admit you can't do it, I guess you can't. There are a
> number of other instructors whom I know are quite capable of doing it.
> And they have done it on Europe, North America and Asia, as I have.
>

Alf and Stefan are right. They are experienced C++ programmers and
teachers. You cannot learn C++ in a semester, and certainly not in a
week. You can get a reasonable /grounding/ of C++ in a semester, but
there is a lot of the language and how to use it that will be missing
completely. In a week, all you will get is a very rough overview.

Of course, this will not stop instructors claiming to teach C++ in a
week. And it will not stop companies sending employees on week-long
courses and assuming that after that, they "know" C++. And it will not
stop companies wasting time, money and reputation as a result of making
said employees program in a language they barely comprehend.

There is only one known realistic plan for really learning C++ in a
short time-frame, and even then it takes 21 days rather than a week:

<http://abstrusegoose.com/249>

[Öö Tiib]

On Tuesday, 26 January 2016 10:06:44 UTC+2, David Brown wrote:
>
> I assume that you don't intend to come across as patronising and
> insulting, but that's how it reads to me. I'm sure Alf has the
> self-confidence to know that he is a good teacher (judging from his vast
> number of helpful posts in this group over the years), and will not be
> bothered by your attitude - but as a bystander, it irritates me.

Sufficiently advanced troll is indistinguishable from a genuine kook but
Jerry Stuckle is likely genuinely insane. Just read comp.lang.c thread
"Offtopic: couldn't stop myself from sharing". When he ran out of nonsense
that seemed slightly coherent from afar then he turned to blather in style
of "Whoopie doopie ding dong". We can't provide the care he needs.

[David Brown]

Yes, I have seen that thread, and my opinion of Jerry is heavily
influenced by it (just as my opinion of Alf is heavily influenced by his
long history of helpful and considered posts - even if I have not always
agreed with them). Jerry is new to Usenet, or at least newly returned
to Usenet - I hope he can learn a more constructive style.

Anyway, enough of this - back to the topic on hand.

[David Brown]

On 23/01/16 02:55, JiiPee wrote:
> In this thread/post you can tell what you like in C++11/C++14. How it
> made things nicer, how you use it and how it made those things easier.
> Why you like C++11/C++14 more than the old C++?

My favourites would be:

* constexpr functions (improved in C++14)
* auto (for local variables, and local functions)
* explicit overrides and final
* strongly typed enumerations
* explicit conversion operators (no more "safe boolean idiom)
* static assertions (no more ugly macros)

Lambdas and nullptr are nice too. User-defined literals have been nice
to play with.

C++14 fixes up a few missing points (std::make_unique, improved constexpr).

It will be interesting to see what C++17 brings in concepts (including
requires, axiom, and assumes).

[Jerry Stuckle]

On 1/26/2016 3:06 AM, David Brown wrote:
> On 26/01/16 02:21, Jerry Stuckle wrote:
>> On 1/25/2016 3:31 PM, Alf P. Steinbach wrote:
>>> On 1/25/2016 6:31 PM, Jerry Stuckle wrote:
>>>>
>>>> I hate to say this, but I know of two people who taught at the college
>>>> level and moved to corporate teaching. Neither one could teach C or C++
>>>> in a week and eventually failed. College instructors are good at
>>>> teaching when they have a whole semester to deal with, but these two
>>>> didn't so so well teaching the same material in five days.
>>>
>>> You're right, I could certainly not teach C++ in a week.
>>>
>>> I'm still learning, and as you may have surmised, I've used the language
>>> since the early 1990s.
>>>
>>> The facts and logic etc. that we dumb people who can't teach C++ in a
>>> week, offer, must just be disregarded, ignored.
>>>
>>>
>>> Cheers & hth.,
>>>
>>> - Alf
>>>
>>
>> Alf,
>>
>> I didn't say YOU couldn't teach C++ in a week. All I said was the two
>> people I know who were university instructors could not teach it in a week.
>>
>
> Jerry, you are very good at /saying/ one thing, and /implying/ something
> very different.
>

David, I implied nothing.

> From what you wrote and the way you wrote it, your message and thought
> process was clear:
>
> 1. You know two people who taught programming at college, and failed to
> teach it to companies.
>
> 2. Therefore everyone who teaches at college will fail at teaching to
> companies.
>

I implied no such thing.

> 3. Alf taught at college then moved to teaching to companies.
>
> 4. Therefore Alf is a bad teacher.
>
> 5. Therefore you win the argument.
>

I implied no such thing.

>
> I assume that you don't intend to come across as patronising and
> insulting, but that's how it reads to me. I'm sure Alf has the
> self-confidence to know that he is a good teacher (judging from his vast
> number of helpful posts in this group over the years), and will not be
> bothered by your attitude - but as a bystander, it irritates me.
>

Read my words - not what you *think I mean*. If I would have thought
Alf is a bad teacher, I would have said so.

>> But since you admit you can't do it, I guess you can't. There are a
>> number of other instructors whom I know are quite capable of doing it.
>> And they have done it on Europe, North America and Asia, as I have.
>>
>
> Alf and Stefan are right. They are experienced C++ programmers and
> teachers. You cannot learn C++ in a semester, and certainly not in a
> week. You can get a reasonable /grounding/ of C++ in a semester, but
> there is a lot of the language and how to use it that will be missing
> completely. In a week, all you will get is a very rough overview.
>

You obviously have no idea what can and cannot be learned in a week.
Corporations pay big money for these courses because they are effective.

> Of course, this will not stop instructors claiming to teach C++ in a
> week. And it will not stop companies sending employees on week-long
> courses and assuming that after that, they "know" C++. And it will not
> stop companies wasting time, money and reputation as a result of making
> said employees program in a language they barely comprehend.
>

And it will not stop corporations from paying big money for something
that works. Virtually all of my clients were Fortune 500 companies -
such as IBM, Intel, Boeing and many others. You're saying these
companies don't know what they're doing? I don't think so.

> There is only one known realistic plan for really learning C++ in a
> short time-frame, and even then it takes 21 days rather than a week:
>
> <http://abstrusegoose.com/249>
>

That's one way. There are others - as corporations understand.

[Jerry Stuckle]

Yup, and that was an accurate response.

[Jerry Stuckle]

On 1/26/2016 9:18 AM, David Brown wrote:

Do you think I really care what your opinion of me is? You have shown
no reason for me to think your opinions are worth anything.

And no, I'm not at all new to usenet. I was one of the first people on
usenet back in the early 80's. I was on arpanet before usenet even
existed; we started with email lists, then went to list servers. Usenet
grew out of that. While I wasn't part of the crowd that created the
protocols, I was using the servers which eventually resulted in the RFPs
for NNTP being created.

And I have been on usenet continually since that time. Just not in this
newsgroup.

This and your other posts prove you are not worth any respect and your
opinions are completely worthless.

[JiiPee]

On 26/01/2016 14:24, David Brown wrote:
> Lambdas and nullptr are nice too.

i like very much nullptr, ... no more pondering whether to use 0 or
create some NULL stuff.... now its clear what to use everywhere. I did
not like that zero:

int* p = 0;

[Geoff]

On Tue, 26 Jan 2016 09:51:00 -0500, Jerry Stuckle
<jstu...@attglobal.net> wrote:

>I was using the servers which eventually resulted in the RFPs
>for NNTP being created.

They're called RFCs and you're full of BS.

[Jerry Stuckle]

Sorry, - I've been looking at RFP's for the last few days (mainly U.S.
Federal Government). I mixed up the terms. It doesn't mean I don't
know what I'm talking about.

But your head is so far up your ass you can see your tonsils.

[Dombo]

Op 24-Jan-16 om 20:26 schreef David Brown:

> On 24/01/16 14:06, Alf P. Steinbach wrote:

>> But this is not a description of a way to avoid the problem.
>
> What problem? "Inadvertent text substitution" just means "I've made
> a mistake in my coding that happens to involve a macro", as far as I
> can see. It is not fundamentally different from any other kind of
> mistake.

You are assuming here that *all* the code is written by *you*, which may
be the case on small embedded systems but is rarely the case with large
scale projects which typically involve thousands of header files from
many parties. Chances are that someone somewhere added a macro with
unintended side-effects. One "nice" example is the definition of a max()
macro (IIRC this was in one of the Windows header
files).

> Now, I am all in favour of programming habits that reduce the risk of
> mistakes - and I am quite happy with "don't use macros unless they
> make a significant benefit to the code" as such a habit.
>
> What I /don't/ see is the idea that macros are so specially bad that
> it is appropriate to disrupt the flow of the code and make them
> stand out above all other identifiers.

Though any language feature can be abused, my experience is that macros
are much more likely to introduce unintended effects than other language
constructs. Other language constructs tend to have more easily
predicable effects, not in the last part because their scope is limited,
and much better diagnostics in case you do get it wrong.

The problem with preprocessor macros is that it is bolted on to the C
and C++ languages rather than being an integral part of those languages.
On the system I learned C programming the preprocessor was actually a
separate program. You first had put your C file through the
preprocessor, after that you had feed the output of the preprocessor to
the C compiler which was another program.

Past 3 years I've done most of my programming in languages that don't
support a C style preprocessor. Frankly I haven't missed digging
through piles of header files to figure out how some "clever" macro
expands and why it causes problems.

>>> Using all-caps for macros is just pandering to bad programmers
>>> and bad code. We should aim to weed out such bad code, not make
>>> it stand out.
>>
>> I.e., the Boost programmers, including e.g. Dave Abrahams, are in
>> your opinion “bad programmers”, producing “bad code”. Hm. I think
>> this argument, which involves some /name calling/, is very
>> unconvincing.
>
> If these folks /need/ to use all-caps names for macros, then they are
> doing something wrong.
>
> Namespace collisions happen. It's almost inevitable.

Actually my experience is that namespace collisions are very rare since
the use of namespaces has become common in C++. I can't think of a case
where I had to deal with a namespace collision in over more than a
decade, with the exception of macros redefining identifiers.

> Macros certainly don't help the matter because they don't follow
> scope rules, but they are not the only type of collision possible.
>
> The way to avoid problems with namespace collisions (through macros
> or anything else) is, I think, threefold. First, make sure that your
> library/header suppliers know what they are doing, and don't use
> common names for anything in a wider scope than necessary. This
> applies to macros, but it also applies to global functions, types,
> enumerators, etc., just as much.

For those there are namespaces, unfortunately macros totally ignore those.

> [snip] My point is nothing more, and nothing less, than that an

> all-caps convention is not necessary for macros, and that this
> convention interferes with clear programming. I don't think macros
> as a class need a naming convention. And I think that using all-caps
> encourages the belief (not followed by everyone here) that macros are
> someone dangerous and scary, and need to stand out so that they can
> be treated with special care.

As long as macros do not adhere to the normal scoping rules, have the
ability to redefine just about anything and don't behave like the rest
of the language, they do need to be treated with special care.

Besides C, C++ and assembly languages there aren't many modern
programming languages that have a C like preprocessor. Also the C++
language itself gets more and more language features that reduce the
necessity to resort to preprocessor macros. I guess there is a reason
for that.

[David Brown]

On 30/01/16 00:38, Dombo wrote:
> Op 24-Jan-16 om 20:26 schreef David Brown:
>> On 24/01/16 14:06, Alf P. Steinbach wrote:
>
>>> But this is not a description of a way to avoid the problem.
>>
>> What problem? "Inadvertent text substitution" just means "I've made
>> a mistake in my coding that happens to involve a macro", as far as I
>> can see. It is not fundamentally different from any other kind of
>> mistake.
>
> You are assuming here that *all* the code is written by *you*, which may
> be the case on small embedded systems but is rarely the case with large
> scale projects which typically involve thousands of header files from
> many parties. Chances are that someone somewhere added a macro with
> unintended side-effects. One "nice" example is the definition of a max()
> macro (IIRC this was in one of the Windows header
> files).

Certainly my viewpoint is biased towards my own work, which is mostly
small embedded systems. And certainly I am talking about what /I/ write
- I can't change the naming style of other people's code!

My argument is not in favour of writing macros with names like "max" (at
least not in general - of course these names could be fine in a small
self-contained program, and one can be much freer within a source file
than in a header file). My argument is merely that you should pick
appropriate names for macros based on their usage and avoiding unwanted
naming conflicts - you should /not/ pick a style based on "it's a macro,
and macros are evil". The reason you don't name a macro "max" in a
common header is basically the same as the reason you don't name a
global function "max" in that common header. That macro is somewhat
worse - no arguments there - but the principle is the same.

>
>> Now, I am all in favour of programming habits that reduce the risk of
>> mistakes - and I am quite happy with "don't use macros unless they
>> make a significant benefit to the code" as such a habit.
>>
>> What I /don't/ see is the idea that macros are so specially bad that
>> it is appropriate to disrupt the flow of the code and make them
>> stand out above all other identifiers.
>
> Though any language feature can be abused, my experience is that macros
> are much more likely to introduce unintended effects than other language
> constructs. Other language constructs tend to have more easily
> predicable effects, not in the last part because their scope is limited,
> and much better diagnostics in case you do get it wrong.
>
> The problem with preprocessor macros is that it is bolted on to the C
> and C++ languages rather than being an integral part of those languages.
> On the system I learned C programming the preprocessor was actually a
> separate program. You first had put your C file through the
> preprocessor, after that you had feed the output of the preprocessor to
> the C compiler which was another program.
>
> Past 3 years I've done most of my programming in languages that don't
> support a C style preprocessor. Frankly I haven't missed digging
> through piles of header files to figure out how some "clever" macro
> expands and why it causes problems.

I agree entirely with what you say here. One of the most important
benefits of C99 over older C90 is that "static inline" and "static
const" have greatly reduced the /need/ of macros. The same applies to
C++ over C, and C++11 over C++03, and C++14 over C++11. But the reason
to use "constexpr" or templates instead of old macros is /not/ that
macros are "evil", but that these solutions are /better/. And when you
still need to use a macro for a particular purpose, you should name it
in the same way you name everything - in a way appropriate to its usage
and its interplay with the rest of the code. You should not name it in
shouting all-caps that disrupts the code and stands out from everything
else, simply because it happens to be a macro.