"The C++14 Standard: What You Need to Know"

[Lynn McGuire]

"The C++14 Standard: What You Need to Know"
http://www.drdobbs.com/cpp/the-c14-standard-what-you-need-to-know/240169034

Nice, thorough article with good explanation on auto.

I miss Dr. Dobbs magazine.

Lynn

[Rick C. Hodgin]

A quote from the article:
---[ Begin ]---
It is obvious to both me and the compiler that the function is returning a double. So in C++14, I can define the function return type as auto instead of double:

auto getvalue() {
return 1.4;
}
---[ End ]---

I think this is potentially very dangerous. Suppose I meant to type 1.4f
but forgot the f? This will not catch that error, and may only generate
a warning elsewhere which another developer sees as "oh, I just need to
cast it to double to get rid of that ridiculous warning," and inserts a
new bug and does not correct the original flaw which would've actually
fixed the first bug and prevented the second.

I believe strongly in an explicit conveyance of developer information
through syntax. For example, getvalue() should be declared thusly:

double getvalue(void) {
return 1.4;
}

In this case the return type was explicitly given, and you explicitly
indicated that you, as the developer, purposefully had no parameters,
rather than leaving a potential questiont here: Did the developer
intend to pass any parameters? When "void" is used, there is no
ambiguity as it's much harder to accidentally type "void" than it is
to accidentally leave off parameters in an otherwise valid syntax
such as "double getvalue()".

I also think we should do away with .h files when they're not necessary,
and instead provide something like:

#includeh "myclass.cpp"

Which is interpreted by the compiler as "read myclass.cpp, but only
derive its information to create what we need to access it, as would
othemrwise be provided by a header."

In a similar manner, an IDE should be able to divine this information
for you and present a read-only, on-the-fly created header file that
can be logically wielded, examined, printed, etc., but rather stems
directly back to the actual cpp source code rather than a separate
file. It also saves disk space. (LOL had to throw that in there :-))

Oh I can't wait to get my compiler written. :-) All of these life and
living requirements make it painful to pause as the months roll by. :-)

Best regards,
Rick C. Hodgin

[Victor Bazarov]

On 9/17/2014 1:05 PM, Rick C. Hodgin wrote:
> [..]

> A quote from the article:
> ---[ Begin ]---
> It is obvious to both me and the compiler that the function is
returning a double. So in C++14, I can define the function return type
as auto instead of double:
>
> auto getvalue() {
> return 1.4;
> }
> ---[ End ]---
>
> I think this is potentially very dangerous. Suppose I meant to type 1.4f

> but forgot the f? This will not catch that error, [..]

Even a very good compiler is not the panacea against the programmer's
stupidity... <ahem> ...forgetfulness.

It's not an error the compiler is supposed to catch.

int foo(int* pi)
{
return *pi;
}

int main()
{
return foo(nullptr);
}

I "forgot" that the function 'foo' dereferences the pointer without
checking, so not until I run my program (and only if I'm lucky and the
execution environment provides the mechanism for catching that type of
situation) shall I know that I've blundered.

There are some tools that can perform static code analysis and point out
the potential trouble in such a case. Omitting a suffix in a literal is
much more difficult to diagnose as unintentional.

If your compiler when you finish it can "do what I mean, not what I
write", let us know.

V
--
I do not respond to top-posted replies, please don't ask

[Paavo Helde]

"Rick C. Hodgin" <rick.c...@gmail.com> wrote in
news:b22a043b-54d7-44fd...@googlegroups.com:

> So in C++14, I can define the function return type
> as auto instead of double:
>
> auto getvalue() {
> return 1.4;
> }
> ---[ End ]---
>
> I think this is potentially very dangerous. Suppose I meant to type
> 1.4f but forgot the f

This feature is not obligatory, one is not forced to use it. Most shops
have coding guidelines which ought to spell out when and how 'auto' is
acceptable.

> I also think we should do away with .h files when they're not
> necessary, and instead provide something like:
>
> #includeh "myclass.cpp"
>

> Oh I can't wait to get my compiler written. :-)

The module system support for C++ is underway: http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2014/n4047.pdf

It's long overdue, but will still probably be finished before your
compiler is ready ;-)

Cheers
Paavo

[Rick C. Hodgin]

On Wednesday, September 17, 2014 3:04:34 PM UTC-4, Paavo Helde wrote:
> "Rick C. Hodgin" <rick.c...@gmail.com> wrote in

> > #includeh "myclass.cpp"
> > Oh I can't wait to get my compiler written. :-)
>

> The module system support for C++ is underway: [url didn't work]

>
> It's long overdue, but will still probably be finished before your
> compiler is ready ;-)

Probably so. It is a lot of work to write an IDE, compiler, and
everything in-between. I am handicapped further in that I am writing
mine after a regular 50+ hour work week. It has been the most
difficult thing I've ever undertaken (for a software project), mainly
because I am also writing everything entirely from the ground up so
it is all founded upon a baseline Christian effort, one designed from
its very inception to be an offering in love of the fruits of the
skills, knowledge, talents, and abilities the Lord first gave me, and
anyone else who wants to come on board and help (so far it's just me
and one man from Columbia, though he's not a C/C++ developer, just
an XBASE developer).

It is very hard work to proceed due to the type of work itself. And
the difficulty in my effort is multiplied by staunch opposition to
all such offerings (my project being offered up explicitly in the
name of Jesus Christ, and being written and given because of Him and
the way He first reached out to me). It is like setting roadblocks
at every point where you would otherwise receive help were the
project given over to monetary profit, or some other worldly purpose.
As it is, being a solely offering-unto-the-Lord project, no one will
get near it ... and I find myself working alone in an ongoing manner.

It is routinely hurtful to be engaged in a project like this,
continuing to press ahead offering everything that is of the very
best within yourself unto others for free, only to have them not
only reject your offering because of its foundations, bu to reject
you personally, and to unleash negativity in all its various forms
toward you. It is nothing less than a continuous test of character.

[Jorgen Grahn]

On Wed, 2014-09-17, Paavo Helde wrote:
> "Rick C. Hodgin" <rick.c...@gmail.com> wrote in
> news:b22a043b-54d7-44fd...@googlegroups.com:
>
>> So in C++14, I can define the function return type
>> as auto instead of double:
>>
>> auto getvalue() {
>> return 1.4;
>> }
>> ---[ End ]---
>>
>> I think this is potentially very dangerous. Suppose I meant to type
>> 1.4f but forgot the f
>
> This feature is not obligatory, one is not forced to use it.

And C++ was never about protecting programmers from themselves.
Featured get added because they can be used, not because they cannot
be misused.

(But I note that you don't seem to disagree with each other.)

/Jorgen

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