Looking for some example of stellar code for educational purpose. Any recommendations?

[ujjwol....@gmail.com]

Looking for some example of stellar code for educational purpose. Any recommendations?

[Lynn McGuire]

On 3/15/2018 11:27 PM, ujjwol....@gmail.com wrote:
> Looking for some example of stellar code for educational purpose. Any recommendations?

100 lines ?

100,000 lines ?

10,000,000 lines ?

Lynn

[Öö Tiib]

On Friday, 16 March 2018 06:27:18 UTC+2, ujjwol....@gmail.com wrote:
> Looking for some example of stellar code for educational purpose. Any recommendations?

If by "stellar" you mean "simple" && "efficient" && "elegant" && "readable"
&& "flexible" && "solid" && "clear" && "robust", then there may be are such
things but those are rare.

Of course everything should be done as simply as possible but not simpler
than possible. Majority of problems worth solving do not have simple
solutions. Only about 5% of code base is worth considering from viewpoint
of efficiency, rest just should avoid being too feeble. About 80% of useful
code base is checking pre-conditions and post-conditions and handling
errors and corner cases. As such it can be plain and robust but not too
elegant. The flexible and solid are also sort of contradicting with each
other.

So what remains ... readability, clarity and robustness. These are worth
teaching ... rest are rare luxury in practice.

[James R. Kuyper]

On 3/15/2018 11:27 PM, ujjwol....@gmail.com wrote:

> Looking for some example of stellar code for educational purpose. Any recommendations?

<https://sourceforge.net/projects/collidinggalaxi/>
<https://sourceforge.net/projects/agbstarviewer/>
<https://sourceforge.net/projects/stellarics/>

[woodb...@gmail.com]

On Thursday, March 15, 2018 at 11:27:18 PM UTC-5, ujjwol....@gmail.com wrote:
> Looking for some example of stellar code for educational purpose. Any recommendations?

https://github.com/Ebenezer-group/onwards

The repo is just called onwards, but that's short for
onwards and upwards. By the grace of G-d, I keep working
on the software to make it more robust, efficient,
flexible, etc.


Brian
Ebenezer Enterprises - Enjoying programming again.
http://webEbenezer.net

[Mr Flibble]

On 20/03/2018 17:28, woodb...@gmail.com wrote:
> On Thursday, March 15, 2018 at 11:27:18 PM UTC-5, ujjwol....@gmail.com wrote:
>> Looking for some example of stellar code for educational purpose. Any recommendations?
>
> https://github.com/Ebenezer-group/onwards
>
> The repo is just called onwards, but that's short for
> onwards and upwards. By the grace of G-d, I keep working
> on the software to make it more robust, efficient,
> flexible, etc.

Your god doesn't exist mate.

/Flibble

--
"Suppose it’s all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I’d say, bone cancer in children? What’s that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It’s not right, it’s utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That’s what I would say."

[Chris M. Thomasson]

On 3/20/2018 6:42 AM, James R. Kuyper wrote:
> On 3/15/2018 11:27 PM, ujjwol....@gmail.com wrote:
>> Looking for some example of stellar code for educational purpose. Any
>> recommendations?
>
> <https://sourceforge.net/projects/collidinggalaxi/>

Nice! Thank you for that.

> <https://sourceforge.net/projects/agbstarviewer/>
> <https://sourceforge.net/projects/stellarics/>

Fwiw, C++ can be used in interesting ways:

https://youtu.be/-KfI6qZyoQw?t=1938
(Kip Thorne...)

;^)

[Chris Vine]

I have the awful feeling that you may have missed the joke. But
probably you are meeting irony with more irony.

[woodb...@gmail.com]

On Tuesday, March 20, 2018 at 1:04:12 PM UTC-5, Mr Flibble wrote:
> On 20/03/2018 17:28, woodb...@gmail.com wrote:
> >
> > https://github.com/Ebenezer-group/onwards
> >
> > The repo is just called onwards, but that's short for
> > onwards and upwards. By the grace of G-d, I keep working
> > on the software to make it more robust, efficient,
> > flexible, etc.
>
> Your god doesn't exist mate.
>

Without faith in G-d's goodness and wisdom, I never
would have invested in the company.

[Rick C. Hodgin]

On Tuesday, March 20, 2018 at 2:04:12 PM UTC-4, Mr Flibble wrote:
> Your god doesn't exist mate.

https://www.biblegateway.com/passage/?search=Psalm+14%3A1%2C53%3A1&version=KJV

"The fool hath said in his heart, There is no God..."

You do not know as you ought, Leigh.

https://www.biblegateway.com/passage/?search=Hosea+4%3A6&version=KJV

6 My people are destroyed for lack of knowledge:
because thou hast rejected knowledge, I will also
reject thee..

--
Rick C. Hodgin

[Alf P. Steinbach]

On 16.03.2018 05:27, ujjwol....@gmail.com wrote:
> Looking for some example of stellar code for educational purpose. Any recommendations?

I just released version 1.0 of my “Empty files as Unicode” Notepad++
extension,

<url:
https://github.com/alf-p-steinbach/NPP-plugin-Empty-files-as-Unicode>

From the recent ISOCPP developer survey it seems that roughly 0% of C++
developers use Notepad++. So it is perhaps sillyware, this. Still.

It's mostly simple down to Earth code, but I use modern C++ trailing
return type syntax for function declarations, while most C++ programmers
still stick to the C style syntax wherever they can (they can't for
lambdas and for some template stuff, so they unwillingly mix two
syntaxes while muttering a stream of unspeakables about dang newfangled
stuff). I.e. the modern C++ syntax in this code is still unconventional
at this point. Also, I use `ptr_` and `ref_` type builders with uniform
prefix `const` notation, instead of the old C declaration syntax with
mixed or suffix `const`, and that's /really/ unconventional.

It's also perhaps unconventional in its general structure where I've
relied on C++ mechanisms such as static initialization instead of the
common C style Notepad++ “framework”.

So, it's solid, clear code; it's not stellar, nothing fancy here; it's
unconventional in the three aspects mentioned (function syntax, type
builders, structure), namely that it's C++ oriented instead of C style.

Cheers & hth.,

- Alf

[David Brown]

On 21/03/18 03:29, Alf P. Steinbach wrote:
> On 16.03.2018 05:27, ujjwol....@gmail.com wrote:
>> Looking for some example of stellar code for educational purpose. Any
>> recommendations?
>
> I just released version 1.0 of my “Empty files as Unicode” Notepad++
> extension,
>
> <url:
> https://github.com/alf-p-steinbach/NPP-plugin-Empty-files-as-Unicode>
>
> From the recent ISOCPP developer survey it seems that roughly 0% of C++
> developers use Notepad++. So it is perhaps sillyware, this. Still.

Notepad++ is often used as a programmers' editor on Windows by people
looking for something a bit lighter than Eclipse. Most C++ programmers
on Windows will, of course, be using MSVC or perhaps Borland, and these
have their own IDEs. People doing embedded development (especially when
the toolchain comes with a poor IDE) or working with other compilers
such as mingw64 gcc, however, will find more use it. So the percentage
of users is going to be a little higher than 0%, I think. (Remember the
percentage of C++ developers who would have seen or responded to an
ISOCPP survey is also roughly 0%.)

>
> It's mostly simple down to Earth code, but I use modern C++ trailing
> return type syntax for function declarations, while most C++ programmers
> still stick to the C style syntax wherever they can (they can't for
> lambdas and for some template stuff, so they unwillingly mix two
> syntaxes while muttering a stream of unspeakables about dang newfangled
> stuff). I.e. the modern C++ syntax in this code is still unconventional
> at this point. Also, I use `ptr_` and `ref_` type builders with uniform
> prefix `const` notation, instead of the old C declaration syntax with
> mixed or suffix `const`, and that's /really/ unconventional.
>

Your style is, shall we say, different from the mainstream. IMHO, it is
a less bad kind of different from some of the other regulars in this
newsgroup. But I doubt that using trailing return types when they are
not needed is likely to become popular.

> It's also perhaps unconventional in its general structure where I've
> relied on C++ mechanisms such as static initialization instead of the
> common C style Notepad++ “framework”.
>

That is a more questionable decision.

A key point about style - either coding style, or design style - is that
it should be consistent. When you are working on an existing project it
is usually more important to be consistent with the rest of the code,
than to use a "better" style.

> So, it's solid, clear code; it's not stellar, nothing fancy here; it's
> unconventional in the three aspects mentioned (function syntax, type
> builders, structure), namely that it's C++ oriented instead of C style.
>

It sounds like a fine example for the OP. Being unconventional, but
with a rational and consistent choice of conventions, should be good for
showing students that there are many ways to write code.

[Ian Collins]

On 03/21/2018 08:47 PM, David Brown wrote:
> On 21/03/18 03:29, Alf P. Steinbach wrote:
>> On 16.03.2018 05:27, ujjwol....@gmail.com wrote:
>>> Looking for some example of stellar code for educational purpose. Any
>>> recommendations?
>>
>> I just released version 1.0 of my “Empty files as Unicode” Notepad++
>> extension,
>>
>> <url:
>> https://github.com/alf-p-steinbach/NPP-plugin-Empty-files-as-Unicode>
>>
>> From the recent ISOCPP developer survey it seems that roughly 0% of C++
>> developers use Notepad++. So it is perhaps sillyware, this. Still.
>
> Notepad++ is often used as a programmers' editor on Windows by people
> looking for something a bit lighter than Eclipse. Most C++ programmers
> on Windows will, of course, be using MSVC or perhaps Borland, and these
> have their own IDEs. People doing embedded development (especially when
> the toolchain comes with a poor IDE) or working with other compilers
> such as mingw64 gcc, however, will find more use it. So the percentage
> of users is going to be a little higher than 0%, I think. (Remember the
> percentage of C++ developers who would have seen or responded to an
> ISOCPP survey is also roughly 0%.)

Most embedded developers I have worked with who use windows use Visual
Studio as their main editing IDE and whatever they have to for target
builds. It makes sense to use the best tools for day to day tasks.

--
Ian

[David Brown]

This all depends on the kind of work, the kind of developer, the kind of
target. For microcontroller development, Eclipse is the most common IDE
- because that is the basis for the toolchains provided by most major
microcontroller manufacturers. The main exceptions are Microchip PICs
(Netbeans) and Atmel (now also Microchip) AVRs (MSVS).

Notepad++ used to be more popular, before vendors standardised on
Eclipse, and is still used by people who don't like Eclipse.

I agree that it makes sense to use the best tools - but "best" depends
on the person and the project, as well as what is commonly used. IMHO,
MSVS is not "best" for any sort of embedded development even if you are
using Windows, but I fully appreciate that other people like it.

[red floyd]

Still not proof of existence.

[Richard]

[Please do not mail me a copy of your followup]

"Alf P. Steinbach" <alf.p.stein...@gmail.com> spake the secret code
<p8sg1f$em5$1...@dont-email.me> thusly:

>[...] but I use modern C++ trailing

>return type syntax for function declarations

By describing it this way you're saying that your usage is "modern"
and by implication, other usages are "archaic".

Had you just said "I use C++ trailing return type" instead of injecting
the adjective modern, I wouldn't have bothered to reply.

I would describe your style as gratuitous use of trailing return type.

I describe it as gratuitous because while it is an option provided by
C++11, it was introduced to enable specific use cases and clarify
others. It wasn't introduced as the "declare all functions this way
from now on" recommendation. So I find your global adoption of this
syntax to be gratuitous.

It is, however, a matter of style.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Mr Flibble]

Speed of light mate.

#atheism

[Ian Collins]

Most of us, that is the teams I am or have been working with, spend very
little time working "on target". Almost all of our time is spent
working in a desktop environment with the very occasional dabble with
the target debugger when something we can't reproduce on the desktop
goes wrong. So the "best" environment depends on the individual's
background and preferences. My current team has an embedded CE
background hence the preference for Visual Studio, my background is
microcontroller development and I prefer Linux/NetBeans. Most of the
other Linux uses prefer Visual Studio Code, which is becoming an
excellent IDE.

--
Ian

[Alf P. Steinbach]

On 21.03.2018 17:27, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> "Alf P. Steinbach" <alf.p.stein...@gmail.com> spake the secret code
> <p8sg1f$em5$1...@dont-email.me> thusly:
>
>> [...] but I use modern C++ trailing
>> return type syntax for function declarations
>
> By describing it this way you're saying that your usage is "modern"
> and by implication, other usages are "archaic".

It's the term adopted by Herb, Scott and Andrei. I think they adopted
for the reason you state, that using the old C style syntax is archaic.

Here's Herb's take on the styles, quoted verbatim:

// Classic C++ declaration order // Modern C++ style
int f( double ); auto f (double) -> int;

Where I differ terminologically is in how I refer to the /old/ style:
while Herb (and presumably also Scott and Andrei) call it "Classic C++"
I call it "C style" -- I think that's more fitting and descriptive. :)

https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/

> Had you just said "I use C++ trailing return type" instead of injecting
> the adjective modern, I wouldn't have bothered to reply.

Well, because you replied you're now learning modern terminology also. ;-)

So that was a good thing.

> I would describe your style as gratuitous use of trailing return type.

You would, yes.


Cheers!,

- Alf

[Ian Collins]

So would I!

I use it occasionally for obvious or very long return types (more often
just C++14's auto without the return type) and the rest of my team
generally hate it!

--
Ian.

[Chris Vine]

On Wed, 21 Mar 2018 21:58:18 +0100
"Alf P. Steinbach" <alf.p.stein...@gmail.com> wrote:
> On 21.03.2018 17:27, Richard wrote:
> > [Please do not mail me a copy of your followup]
> >
> > "Alf P. Steinbach" <alf.p.stein...@gmail.com> spake the
> > secret code <p8sg1f$em5$1...@dont-email.me> thusly:
> >
> >> [...] but I use modern C++ trailing
> >> return type syntax for function declarations
> >
> > By describing it this way you're saying that your usage is "modern"
> > and by implication, other usages are "archaic".
>
> It's the term adopted by Herb, Scott and Andrei. I think they adopted
> for the reason you state, that using the old C style syntax is
> archaic.
>
> Here's Herb's take on the styles, quoted verbatim:
>
> // Classic C++ declaration order // Modern C++ style
> int f( double ); auto f (double) -> int;
>
> Where I differ terminologically is in how I refer to the /old/ style:
> while Herb (and presumably also Scott and Andrei) call it "Classic
> C++" I call it "C style" -- I think that's more fitting and
> descriptive. :)
>
> https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/

Argumentum ad verecundiam = very little.

These are just fads. auto has its uses for local variables to simplify
code but outside of that "almost always auto" is ridiculous and not
recommended generally in the type inference world. Trailing return
types are rarely used in code I have seen except where the return type
has to be deduced by applying decltype to arguments or where the syntax
demands it (eg the return type of lambda expressions or to assign a
lambda expression or the return value of std::bind to a variable).

As regards the appeals to reference, Scott is no longer active in C++,
nor is Andrei (if you refer to Scott Meyers and Andrei Alexandrescu).
The latter now follows his interests in D. I don't know what Scott
Meyers is now doing.

[Chris Vine]

On Wed, 21 Mar 2018 21:25:50 +0000
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> As regards the appeals to reference, Scott is no longer active in C++,

^^^^^^^^^
reverence

[Alf P. Steinbach]

These well-known experts, which include the chair of the international
C++ standardization committee, recommend trailing return type for the
C++ world, not the type inference world. Also note that trailing return
type has nothing to do with type inference. So, both the "not
recommended" and the "type inference" association are incorrect
assertions: trailing return type /is/ recommended, by our best and
brightest, and not for type inference, which is irrelevant.

I don't think it's ridiculous, they don't think it's ridiculous, and you
do think so, no doubt tied to the incorrect assertions about it.

> Trailing return
> types are rarely used in code I have seen except where the return type
> has to be deduced by applying decltype to arguments or where the syntax
> demands it (eg the return type of lambda expressions or to assign a
> lambda expression or the return value of std::bind to a variable).

That's true, and unfortunate. I mentioned this extremely slow adoption
in a posting up-thread, that you're now indirectly replying to.

> As regards the appeals to reference, Scott is no longer active in C++,
> nor is Andrei (if you refer to Scott Meyers and Andrei Alexandrescu).
> The latter now follows his interests in D. I don't know what Scott
> Meyers is now doing.

It's not an appeal. It's a reference to the source of the terminology
that was questioned. Should I now refrain from giving references out of
fear that they will be described as argumentative appeals? Jeez.

[Chris Vine]

On Wed, 21 Mar 2018 22:50:32 +0100
"Alf P. Steinbach" <alf.p.stein...@gmail.com> wrote:
> On 21.03.2018 22:25, Chris Vine wrote:

[snip]

> > Argumentum ad verecundiam = very little.
> >
> > These are just fads. auto has its uses for local variables to
> > simplify code but outside of that "almost always auto" is
> > ridiculous and not recommended generally in the type inference
> > world.
>
> These well-known experts, which include the chair of the
> international C++ standardization committee, recommend trailing
> return type for the C++ world, not the type inference world. Also
> note that trailing return type has nothing to do with type inference.
> So, both the "not recommended" and the "type inference" association
> are incorrect assertions: trailing return type /is/ recommended, by
> our best and brightest, and not for type inference, which is
> irrelevant.
>
> I don't think it's ridiculous, they don't think it's ridiculous, and
> you do think so, no doubt tied to the incorrect assertions about it.
>
> > Trailing return
> > types are rarely used in code I have seen except where the return
> > type has to be deduced by applying decltype to arguments or where
> > the syntax demands it (eg the return type of lambda expressions or
> > to assign a lambda expression or the return value of std::bind to a
> > variable).
>
> That's true, and unfortunate. I mentioned this extremely slow
> adoption in a posting up-thread, that you're now indirectly replying
> to.
>

> > As regards the appeals to [reverence], Scott is no longer active in

> > C++, nor is Andrei (if you refer to Scott Meyers and Andrei
> > Alexandrescu). The latter now follows his interests in D. I don't
> > know what Scott Meyers is now doing.
>
> It's not an appeal. It's a reference to the source of the terminology
> that was questioned. Should I now refrain from giving references out
> of fear that they will be described as argumentative appeals? Jeez.

Well you were using it as a justification for your use of the word
"modern".

Your opinions are always worth reading. But on your use of trailing
return types, and if you accept the 'almost always auto' line as
regards the typing of variables, I don't agree with you. I prefer
"auto when it shortens your code and doesn't (i) export unintelligible
type errors to some other code 1000 lines away, or (ii) obfuscate the
intention of the code"; and I prefer leading return types where
syntactically correct.

On 'almost always auto' it was you who referred to it when linking to
a Herb Sutter post. If you weren't expressing an opinion on the auto
typing of variables, so be it.

[Richard]

[Please do not mail me a copy of your followup]

Ian Collins <ian-...@hotmail.com> spake the secret code
<fhfs7v...@mid.individual.net> thusly:

>[...] My current team has an embedded CE

>background hence the preference for Visual Studio, my background is
>microcontroller development and I prefer Linux/NetBeans. Most of the
>other Linux uses prefer Visual Studio Code, which is becoming an
>excellent IDE.

I've had very positive experiences with CLion on linux. I haven't
tried VS code on linux, though. Does it have any refactoring support?

[Mr Flibble]

Alf is talking bollocks as usual. Of course trailing return type is to
be used rarely not routinely.

[Richard]

[Please do not mail me a copy of your followup]

"Alf P. Steinbach" <alf.p.stein...@gmail.com> spake the secret code

<p8uh1b$o5k$1...@dont-email.me> thusly:

>On 21.03.2018 17:27, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> "Alf P. Steinbach" <alf.p.stein...@gmail.com> spake the secret code
>> <p8sg1f$em5$1...@dont-email.me> thusly:
>>
>>> [...] but I use modern C++ trailing
>>> return type syntax for function declarations
>>
>> By describing it this way you're saying that your usage is "modern"
>> and by implication, other usages are "archaic".
>
>It's the term adopted by Herb, Scott and Andrei. I think they adopted
>for the reason you state, that using the old C style syntax is archaic.

If by Scott you mean Scott Meyers, he doesn't recommend unconditional
use of trailing return type in "Effective Modern C++", so I'm not sure
where that is coming from.

You'll also notice that Herb's "Almost Always Auto" has received
significant pushback from the community and he has dialed back on that
somewhat.

>Well, because you replied you're now learning modern terminology also. ;-)
>
>So that was a good thing.

Nope, just a difference of opinion.

>> I would describe your style as gratuitous use of trailing return type.
>
>You would, yes.

And do. But like I say, it's a matter of style, not correctness.

If I joined a team where trailing return type was mandated, I'd state
my opinion (once). Were I unpersuasive, I'd probably write a clang-tidy
like tool to automatically apply those transformations and just continue
coding from muscle memory.

[Rick C. Hodgin]

On Wednesday, March 21, 2018 at 1:48:13 PM UTC-4, Mr Flibble wrote:
> On 21/03/2018 00:50, Rick C. Hodgin wrote:
> > On Tuesday, March 20, 2018 at 2:04:12 PM UTC-4, Mr Flibble wrote:
> >> Your god doesn't exist mate.
> >
> > https://www.biblegateway.com/passage/?search=Psalm+14%3A1%2C53%3A1&version=KJV
> >
> > "The fool hath said in his heart, There is no God..."
> >
> > You do not know as you ought, Leigh.
> >
> > https://www.biblegateway.com/passage/?search=Hosea+4%3A6&version=KJV
> >
> > 6 My people are destroyed for lack of knowledge:
> > because thou hast rejected knowledge, I will also
> > reject thee..
> >
>
> Speed of light mate.

(1) God created the Earth mature.
(2) God created the sun, moon, solar system mature.
(3) God created all life on Earth full-grown, mature.
(4) God created Adam full-grown.
(5) God created Eve full grown.
(6) God created the stars for us to see, for them to be signs for us.

When you load a scene on a space game, do you have to wait years
for light from distant stars to reach your spaceship?

You give no thought to God, or His abilities. You cage Him in to
your own limited mind, casting yourself and your understanding of things
in the role of God.

You will miss it, Leigh, if you keep your foolish pride up.

--
Rick C. Hodgin

[Mr Flibble]

[Rick C. Hodgin]

Did you read anything I wrote?

> --
> "Suppose it’s all true, and you walk up to the pearly gates, and are
> confronted by God," Bryne asked on his show The Meaning of Life. "What
> will Stephen Fry say to him, her, or it?"
> "I’d say, bone cancer in children? What’s that about?" Fry replied.
> "How dare you? How dare you create a world to which there is such misery
> that is not our fault. It’s not right, it’s utterly, utterly evil."
> "Why should I respect a capricious, mean-minded, stupid God who creates
> a world that is so full of injustice and pain. That’s what I would say."

This person you quote does not understand that God created everything
perfect, and that it was sin which introduced death, disease, destruction,
hate, war, famine, and everything else.

He thinks only in terms of here and now, of our flesh. He is both
short-sighted and misguided. It is why he concludes God is in error,
rather than himself being wrong about his current beliefs about God.

He is like you, Leigh. Confused. And damned ... unless you repent.

You and Peter Cheung... I don't know why I care so deeply for either
of you. My flesh tells me to abandon you both. But my spirit tells me
to pray for you, and keep reaching out.

--
Rick C. Hodgin

[Mr Flibble]

[Rick C. Hodgin]

On Wednesday, March 21, 2018 at 9:05:02 PM UTC-4, Mr Flibble wrote:
> Speed of light mate.

May God Himself open your eyes to the truth, Leigh. May He pour
out grace and mercy upon you as He did me, breaking your pride,
replacing your error with truth, saving your soul, teaching you
love like you've never known.

May you prosper greatly in knowledge of the truth.

--
Rick C. Hodgin

[Chris M. Thomasson]

Let us go down the crazy town rabbit hole, for Rick: The speed of light
is rendered meaningless by means of amplifying and focusing a
gravitational field to create an artificially connected portal. The
craft does not travel in a straight line from original point A to
destination point B. Instead, it pulls B to itself until a portal is
created. The craft at A smoothly glides across, and simply turns the
amplified field off. A is automatically at B. The distance between A and
B could easily be tens of thousands of light years traveled within an
instant, perhaps within a single tick of Plank time.


Element 115 mate. Sausages, and Beer. ;^)

[leigh.v....@googlemail.com]

[leigh.v....@googlemail.com]

Being able to fold space doesn't negate the fact that space would need to be folded in the first place i.e. distances to stellar objects greater than 6000 light years exist that we can observe thus falsifying the 6000 year old universe claim due to the speed of light.

[David Brown]

Use auto if it makes the code clearer, makes it easier to write correct
code, and makes it harder to write incorrect code. "Shortens your code"
should have nothing to do with the decision, any more than cool catch
phrases (even if they come from C++ experts).

The original justification for "auto" was to avoid figuring out and
writing complex template type names for things like iterators - and it
works marvellously for that. It is also (obviously) useful for function
declarations when you can't give the type in advance.

With concepts, it is also a very neat way to declare template functions
and classes.

But its use in most other circumstances is just as a lazy way of writing
the code. Lazy can be good, of course - wasted effort is, well, wasted.
It can keep the code shorter and easier to read. But it can also lead
to unexpected effects due to unwarranted assumptions, or code that is
unclear because you don't know what type things are, and it reduces some
of the scope for the compiler to check your code. If "foo()" returns a
double but you think it returns an "int", and you write "int x =
foo();", then your compiler can warn you of the potential mistake (if it
has appropriate warnings, and they are enabled). If you write "auto x =
foo();", your error goes unnoticed and affects things later on somewhere.

Concepts can give a nice middle ground here - if you write "Number x =
bar();", then you are telling the compiler to make x of whatever Number
type bar() returns - but you want an error if bar() returns a string.

[leigh.v....@googlemail.com]

That's easy: if the return type is a scalar then don't use auto otherwise use auto.

[Scott Lurndal]

Feel free to give references to standards. Anything else is appealing
to an authority.

[Chris M. Thomasson]

On 3/22/2018 1:10 AM, leigh.v....@googlemail.com wrote:
> Being able to fold space doesn't negate the fact that space would need to be folded in the first place

Agreed.

> i.e. distances to stellar objects greater than 6000 light years exist that we can observe thus falsifying the 6000 year old universe claim due to the speed of light.

Agreed. If A and B are 10000 light years from one another, well, going
the speed of light would take way to long: This is NOT ideal! The Bob
Lazar "factoid" is that the source, say A pulls the destination B to it;
A moves "into" B; A turns off the artificial field; everything snaps
back together. Now A is at B in, say a single tick of Plank time...

The total travel time from A to B would be virtually "instantaneous".
Afaict, this does not take away from the fact that the distance is 10000
light years away. Older than 6000 years of existence. ;^)

Rick actually seems to think that traveling 10000 light years in any
direction away from Earth as the origin, is impossible. He think the
explorers will physically hit a projected image on a physical screen
6000 light years away. Humm... Strange. Flat Earth Crap? Oh, we can't go
too far in one direction because we will fall off an infinite waterfall
or something...

Wow. Beam be up!

[Ian Collins]

On 03/22/2018 11:53 AM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Ian Collins <ian-...@hotmail.com> spake the secret code
> <fhfs7v...@mid.individual.net> thusly:
>
>> [...] My current team has an embedded CE
>> background hence the preference for Visual Studio, my background is
>> microcontroller development and I prefer Linux/NetBeans. Most of the
>> other Linux uses prefer Visual Studio Code, which is becoming an
>> excellent IDE.
>
> I've had very positive experiences with CLion on linux. I haven't
> tried VS code on linux, though. Does it have any refactoring support?

It does have refactoring support across a range of languages. I haven't
tried it myself, but I am tempted to give it a go based on feedback from
my colleagues.

--
Ian.

[Vir Campestris]

On 21/03/2018 22:57, Mr Flibble wrote:
>
> Alf is talking bollocks as usual.  Of course trailing return type is to
> be used rarely not routinely.

Alf rarely talks bollocks. But...

In this case however I agree with you. I'm working in a codebase that's
evolved over years - parts of it predate C++ entirely - and the leading
return value syntax was all that was available. So it's used everywhere.

Changing a few functions to a different syntax would mean breaking the
house style, and would require a slight interruption in my chain of
thought every time I met one.

I also avoid auto. If I see this variable auto foo I have to move the
mouse onto it to let the IDE have a think and tell me what it really is.
Which is slower than just declaring it properly. Sometimes of course
(type of a lambda for example) auto is unavoidable.

Andy

[Richard]

[Please do not mail me a copy of your followup]

Vir Campestris <vir.cam...@invalid.invalid> spake the secret code
<p93r33$4n5$2...@dont-email.me> thusly:

>Changing a few functions to a different syntax would mean breaking the
>house style, and would require a slight interruption in my chain of
>thought every time I met one.

There is a use case for trailing return type but it has to do with
template functions where the return type depends on the types of the
arguments, e.g.

template <typename T, typename T>
auto add(T t, U u) -> decltype(t + u)
{
return t + u;
}

...other than those specific use cases for which it was intended, I
find the arguments for trailing return type unconvincing. It's extra
tokens to express trailing return type (generally a bad idea IMO) and
in all the years that C++ has been around "leading return types!"
hasn't been a community complaint. Adopting it wholesale is a
solution in search of a problem IMO. Appealling to Herb Sutter
doesn't convince me; he's not a god, he's a human being with an
opinion. I'm not persuaded by his arguments.

The case where trailing return type (e.g. above) is convenient and
useful are generally few and far between in any typical codebase, so
it doesn't make sense to flip the whole world upside down to conform
to these rare cases "for the sake of consistency".

This is why I say that I feel Alf's use of trailing return type feels
gratuitous and on any team is more likely to yield friction than
clarity when reading code.

My team's coding guidelines says to avoid auto unless it makes the
code easier to read, e.g.
std::vector<std::map<std::string,std::string>>::const_iterator is way
too verbose and auto is preferable here.

[Ian Collins]

On 03/24/2018 11:30 AM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Vir Campestris <vir.cam...@invalid.invalid> spake the secret code
> <p93r33$4n5$2...@dont-email.me> thusly:
>
>> Changing a few functions to a different syntax would mean breaking the
>> house style, and would require a slight interruption in my chain of
>> thought every time I met one.
>
> There is a use case for trailing return type but it has to do with
> template functions where the return type depends on the types of the
> arguments, e.g.
>
> template <typename T, typename T>
> auto add(T t, U u) -> decltype(t + u)
> {
> return t + u;
> }
>

> ....other than those specific use cases for which it was intended, I

> find the arguments for trailing return type unconvincing.

Even in this case the trailing return is superfluous under C++ >= 14
rules :)

> It's extra
> tokens to express trailing return type (generally a bad idea IMO) and
> in all the years that C++ has been around "leading return types!"
> hasn't been a community complaint. Adopting it wholesale is a
> solution in search of a problem IMO. Appealling to Herb Sutter
> doesn't convince me; he's not a god, he's a human being with an
> opinion. I'm not persuaded by his arguments.
>
> The case where trailing return type (e.g. above) is convenient and
> useful are generally few and far between in any typical codebase, so
> it doesn't make sense to flip the whole world upside down to conform
> to these rare cases "for the sake of consistency".
>
> This is why I say that I feel Alf's use of trailing return type feels
> gratuitous and on any team is more likely to yield friction than
> clarity when reading code.
>
> My team's coding guidelines says to avoid auto unless it makes the
> code easier to read, e.g.
> std::vector<std::map<std::string,std::string>>::const_iterator is way
> too verbose and auto is preferable here.

Pretty much the same here, the iterator example is one where both auto
variables and trailing return types would be okay, but I still get some
push back with the trailing return usage...

--
Ian

[Jorgen Grahn]

On Fri, 2018-03-23, Vir Campestris wrote:
> On 21/03/2018 22:57, Mr Flibble wrote:
>>
>> Alf is talking bollocks as usual.  Of course trailing return type is to
>> be used rarely not routinely.
>
> Alf rarely talks bollocks. But...
>
> In this case however I agree with you. I'm working in a codebase that's
> evolved over years - parts of it predate C++ entirely - and the leading
> return value syntax was all that was available. So it's used everywhere.
>
> Changing a few functions to a different syntax would mean breaking the
> house style, and would require a slight interruption in my chain of
> thought every time I met one.

Also, I've seen no sign that C++ programmers are switching to this
syntax en masse.

Perhaps what happened that some people saw C++11 as a chance to start
from scratch, break free from the C legacy and so on. Others (like
me) saw it as just a welcome incremental improvement.

> I also avoid auto. If I see this variable auto foo I have to move the
> mouse onto it to let the IDE have a think and tell me what it really is.
> Which is slower than just declaring it properly.

I thought I was more sceptical to auto than most, but I wouldn't say I
/avoid/ it. I agree that if you have to ask your IDE, then you have
overused it:

- I don't use an IDE.
- If I did I wouldn't want to force my readers to use one.
- git diff isn't an IDE.
- Gerrit (the code review tool) isn't an IDE.
- etc

But there are plenty of local variables where it's obvious from close
context what the type is. Or you just pass the value on without
caring what it is. There I happily use auto (or const auto, or const
auto&).

I was in one project the other year where one of the goals was to go
all-in with C++11 and later. Auto didn't become a problem there. In
fact, the only C++11 feature we perhaps overdid was messing with move
semantics.

> Sometimes of course (type of a lambda for example) auto is
> unavoidable.

/Jorgen

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

[woodb...@gmail.com]

I would write auto const or auto const&, but otherwise agree
with you.


Brian
Ebenezer Enterprises
http://webEbenezer.net