Let'me learn.

[thu ra]

Hello, ladies and gentlemen
My name is Thu Ra from Myanmar(Burma). I want to learn programming. Please, teach me. Thank you.

[thu ra]

[Alf P. Steinbach]

On 01-Jun-17 9:01 AM, thu ra wrote:
> Hello, ladies and gentlemen My name is Thu Ra from Myanmar(Burma). I
> want to learn programming. Please, teach me. Thank you.
>

In this group we discuss programming in the C++ language, so you're
technically off-topic.

Still, some words of advice: C++ is a difficult language even for
professionals, and even more difficult for beginners. Very.

It's my impression that most young beginners today use some variant of
JavaScript. They use online JavaScript exploration sites like JSFiddle,
and they use local JavaScript programming environments like “node.js”.
The “node.js” environment has some excellent tutorials. I suggest you
try it. Just google “node.js tutorials”.


Cheers & hth.,

- Alf

[Jorgen Grahn]

On Thu, 2017-06-01, Alf P. Steinbach wrote:
> On 01-Jun-17 9:01 AM, thu ra wrote:
>> Hello, ladies and gentlemen My name is Thu Ra from Myanmar(Burma). I
>> want to learn programming. Please, teach me. Thank you.
>>
>
> In this group we discuss programming in the C++ language, so you're
> technically off-topic.
>
> Still, some words of advice: C++ is a difficult language even for
> professionals, and even more difficult for beginners. Very.

Hey, why scare away potential new C++ programmers? We need them.

If you stay away from the C subset and the most esoteric stuff, I
don't think it's that difficult.

I'm not accusing you of this, but IMO a problem with C++ is people's
desire to complicate things, to create interesting problems. C++ is
a good language for that too, but I'd rather get useful things done.

A more real problem for beginners may be that there's little instant
gratification. Not counting unit tests, it takes some work to create
something that actually runs and does anything useful.

/Jorgen

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

[Rick C. Hodgin]

If you would like to learn C and some C++, I can teach you. If you
want to learn everything in C++ it's beyond my knowledge base. But
if you learn C and some C++, you can do 90% of C++ development until
a few years ago.

Email me if interested.

Thank you,
Rick C. Hodgin

[Öö Tiib]

On Thursday, 1 June 2017 19:57:32 UTC+3, Jorgen Grahn wrote:
> On Thu, 2017-06-01, Alf P. Steinbach wrote:
> > On 01-Jun-17 9:01 AM, thu ra wrote:
> >> Hello, ladies and gentlemen My name is Thu Ra from Myanmar(Burma). I
> >> want to learn programming. Please, teach me. Thank you.
> >>
> >
> > In this group we discuss programming in the C++ language, so you're
> > technically off-topic.
> >
> > Still, some words of advice: C++ is a difficult language even for
> > professionals, and even more difficult for beginners. Very.
>
> Hey, why scare away potential new C++ programmers? We need them.

But such words can scare away only the cowardly. I'm not sure that
we need them. ;)

[Mr Flibble]

A good alternative to Rick's tutoring on C++ would be to stick needles
in your eyes.

/Flibble

[Rick C. Hodgin]

On Thursday, June 1, 2017 at 1:42:36 PM UTC-4, Mr Flibble wrote:
> A good alternative to Rick's tutoring on C++ would be to stick needles
> in your eyes.

You're welcome to offer to teach someone your comprehensive skills,
Leigh. You have a vast amount of knowledge and experience. Others
would benefit greatly from your tutelage.

Would you like to tutel thu ra?

[Mr Flibble]

On 01/06/2017 19:02, Rick C. Hodgin wrote:
> On Thursday, June 1, 2017 at 1:42:36 PM UTC-4, Mr Flibble wrote:
>> A good alternative to Rick's tutoring on C++ would be to stick needles
>> in your eyes.
>
> You're welcome to offer to teach someone your comprehensive skills,
> Leigh. You have a vast amount of knowledge and experience. Others
> would benefit greatly from your tutelage.

If I was to offer such a service it would be free from the encumbrances
of tedious proselytising.

/Flibble

[Rick C. Hodgin]

Well ... it's not like you think.

Have you ever read the Bible? It's not that we proselytize, but
rather we are changed from within and now live a changed life.
It's part of our basic nature, so it's not like a conscious thing
we do, it's natural, from within.

For us, we are still here looking like other people, but we've been
changed on the inside. It's not for show or attention we teach these
things about Christ, but they are so integrated into our existence
now that it is only second nature. And there's a natural driving
force within us to want to teach. That is a driving impetus by
the very spirit of God which dwells within us, guiding us, leading
us, teaching us, giving us strength to stand up against the railing
hate we often receive.

It would be like if you hired an exercise trainer to stay with you
24/7, they would always be giving you advice. "Don't eat that."
"Time to workout." "C'mon, six more reps!" You'd have this
constant bug in your ear urging you on. With us, it's internal.
God is spirit, so He's literally dwelling with us on the inside,
all the time, guiding us.

-----
The changed nature, Leigh. It's only possible when Jesus takes
your sin away. And when He does, you're left with the changed
nature. And you really are changed on the inside, which then
manifests in to outward things you'll see as evidence of that
change on the outside.

[Mr Flibble]

On 01/06/2017 19:37, Rick C. Hodgin wrote:
> On Thursday, June 1, 2017 at 2:18:23 PM UTC-4, Mr Flibble wrote:
>> On 01/06/2017 19:02, Rick C. Hodgin wrote:
>>> On Thursday, June 1, 2017 at 1:42:36 PM UTC-4, Mr Flibble wrote:
>>>> A good alternative to Rick's tutoring on C++ would be to stick needles
>>>> in your eyes.
>>>
>>> You're welcome to offer to teach someone your comprehensive skills,
>>> Leigh. You have a vast amount of knowledge and experience. Others
>>> would benefit greatly from your tutelage.
>>
>> If I was to offer such a service it would be free from the encumbrances
>> of tedious proselytising.
>
> Well ... it's not like you think.
>

[tldr; snippped]

Why do you think I will actually waste my time and read your
proselytising word salad spam? I can assure that I don't and never will
and I can assure you that most other users of the newsgroup also don't
and never will.

/Flibble

[Rick C. Hodgin]

Mr Flibble wrote:
> Why do you think I will actually waste my time and read your ...

Because I have hope and I care about you. These things I teach and
share with you are the truth, and it's the best I have to offer you. I want
you to thrive and shine on after you leave this world. And I know that
will only happen if your sin is forgiven.

[Jorgen Grahn]

On Thu, 2017-06-01, Rick C. Hodgin wrote:
> On Thursday, June 1, 2017 at 3:01:56 AM UTC-4, thu ra wrote:
>> Hello, ladies and gentlemen
>> My name is Thu Ra from Myanmar(Burma). I want to learn programming.
>> Please, teach me. Thank you.
>
> If you would like to learn C and some C++, I can teach you.

I /do/ like C, but I don't think it's the right way to
learn C++.

> If you want to learn everything in C++ it's beyond my knowledge
> base.

Mine too. But trying to learn everything would also be a mistake.

> But if you learn C and some C++, you can do 90% of C++ development
> until a few years ago.

[Tristan B. Kildaire]

Teach how to malloc().

[Alf P. Steinbach]

Best practice in C is to not explicitly cast the result of `malloc`,
because if you've forgotten to include the relevant header, then that
will create an implicit declaration of `malloc` returning `int`.

In C++ you have to cast the `malloc` result if you want a more specific
pointer. This illustrates that what you've learned in one language
doesn't necessarily transfer to the other language. C is not C++-.

In C++ you will ordinarily use standard library and 3rd party container
classes, with no explicit memory management visible. And in C++, when
you do delve down to the level of explicit memory management, it's all
about `new` and `delete` expressions, not `malloc` and `free`. In C++
only use `malloc` when there are specific unavoidable requirements, such
as some library requiring `malloc`-ed memory handed to it (the prime
example, to me, is the standard library's `realloc`, for speed).

[Jerry Stuckle]

On 6/6/2017 1:31 PM, Alf P. Steinbach wrote:
> On 06-Jun-17 6:38 PM, Tristan B. Kildaire wrote:
>> On 2017-06-01 07:42 PM, Mr Flibble wrote:
>>> On 01/06/2017 18:02, Rick C. Hodgin wrote:
>>>> On Thursday, June 1, 2017 at 3:01:56 AM UTC-4, thu ra wrote:
>>>>> Hello, ladies and gentlemen
>>>>> My name is Thu Ra from Myanmar(Burma). I want to learn programming.
>>>>> Please, teach me. Thank you.
>>>>
>>>> If you would like to learn C and some C++, I can teach you. If you
>>>> want to learn everything in C++ it's beyond my knowledge base. But
>>>> if you learn C and some C++, you can do 90% of C++ development until
>>>> a few years ago.
>>>>
>>>> Email me if interested.
>>>
>>> A good alternative to Rick's tutoring on C++ would be to stick
>>> needles in your eyes.
>>>
>>> /Flibble
>>>
>> Teach how to malloc().
>>
>> Please, teach me. Thank you.
>
> Best practice in C is to not explicitly cast the result of `malloc`,
> because if you've forgotten to include the relevant header, then that
> will create an implicit declaration of `malloc` returning `int`.
>

<snip>

> Cheers & hth.,
>
> - Alf

This is far from being globally recognized. Many organizations (such as
CERT) recommend always casting the return value of malloc() to the
appropriate type. Among other things, it prevents a change in the code
from causing hidden problems, i.e.

int * p;

p = malloc(sizeof *p);
*p = -1;
if (*p < 0) {
....
}

No problem with this code. However, if for some reason we change this to

unsigned in *p;

There will be no compiler error, but the if statement will never succeed
(some compilers will warn here, but not all). This will cause a hidden
problem which may be hard to find later.

OTOH, if you had:

p = (int *) malloc(sizeof *p);

This will cause a compiler error if p is changed to an unsigned int *.

Now you may claim you'd never do this - but it happens - all too often -
when developing code. The extra cast doesn't hurt anything (other than
add a few extra characters to the statement), but can protect against
inadvertent problems.

For CERT's recommendation see
https://www.securecoding.cert.org/confluence/display/c/MEM02-C.+Immediately+cast+the+result+of+a+memory+allocation+function+call+into+a+pointer+to+the+allocated+type

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

[Alf P. Steinbach]

You, and apparently the author of the CERT guideline you link to, are
conflating two things:

A) Preventing a change of type of p.

B) Use of `malloc`.

`malloc` is not a good device to do (A).

I don't usually code in C so I had to google up a solution for (A):

#define ASSERT_IS_A(T, x) (0 && ((T){ 0 } = (x)))

> Now you may claim you'd never do this - but it happens - all too often -
> when developing code.

No doubt. One solution is presented above.

> The extra cast doesn't hurt anything (other than
> add a few extra characters to the statement),

That statement is a simple denial of a fact quoted by you above.

> but can protect against inadvertent problems.

Yes it can, but at needless cost (no matter how you deny it: denial
doesn't really work) and loss of clarity.

> For CERT's recommendation see
> https://www.securecoding.cert.org/confluence/display/c/MEM02-C.+Immediately+cast+the+result+of+a+memory+allocation+function+call+into+a+pointer+to+the+allocated+type

Apparently originally that article contained

> "Explicitly casting the return value of malloc() eliminates the
> warning for the implicit declaration of malloc()."

… mentioned in the comments, which is lunacy.

Or, let me soften that: using casts to shut up the compiler is something
a first year student might do in the first month or so, but not a
competent programmer.

[Jerry Stuckle]

As I said - it is a simplified example - one even you should be able to
understand. Whether it is the *best way* or not is immaterial.

>> Now you may claim you'd never do this - but it happens - all too often -
>> when developing code.
>
> No doubt. One solution is presented above.
>
>

Which is even more typing - and won't necessarily catch the problem.
You would have to have the macro before every call to malloc() to ensure
you don't have a problem.

>> The extra cast doesn't hurt anything (other than
>> add a few extra characters to the statement),
>
> That statement is a simple denial of a fact quoted by you above.
>

Not at all. There is a relationship between the type of p and malloc.
And during development (or even during maintenance), the type of p may
need to be changed for one reason or another.

>
>> but can protect against inadvertent problems.
>
> Yes it can, but at needless cost (no matter how you deny it: denial
> doesn't really work) and loss of clarity.
>

The cost is only a few cycles at compile time - less, in fact, than the
cost of your macro.

>
>> For CERT's recommendation see
>> https://www.securecoding.cert.org/confluence/display/c/MEM02-C.+Immediately+cast+the+result+of+a+memory+allocation+function+call+into+a+pointer+to+the+allocated+type
>>
>
> Apparently originally that article contained
>
>> "Explicitly casting the return value of malloc() eliminates the
>> warning for the implicit declaration of malloc()."
>
> … mentioned in the comments, which is lunacy.
>

Not at all lunacy.

> Or, let me soften that: using casts to shut up the compiler is something
> a first year student might do in the first month or so, but not a
> competent programmer.
>

Or, in the case of pointers, ensuring the types are the same. There are
no type conversions between pointers to different types, like there are
with other types. Even a first year student understands that.

>
> Cheers & hth.,
>
> - Alf

Personally, I take CERT's guidelines over any I see in a newsgroup.
Those people know how to develop safe code.

[Alf P. Steinbach]

I'm sorry but this is not meaningful; it's utter nonsense.

>>> The extra cast doesn't hurt anything (other than
>>> add a few extra characters to the statement),
>>
>> That statement is a simple denial of a fact quoted by you above.
>>
>
> Not at all. There is a relationship between the type of p and malloc.
> And during development (or even during maintenance), the type of p may
> need to be changed for one reason or another.

Again I'm sorry but this is not meaningful; it's utter nonsense.

>>> but can protect against inadvertent problems.
>>
>> Yes it can, but at needless cost (no matter how you deny it: denial
>> doesn't really work) and loss of clarity.
>>
>
> The cost is only a few cycles at compile time - less, in fact, than the
> cost of your macro.

And yet again I'm sorry but this is not meaningful; it's utter nonsense.

>>> For CERT's recommendation see
>>> https://www.securecoding.cert.org/confluence/display/c/MEM02-C.+Immediately+cast+the+result+of+a+memory+allocation+function+call+into+a+pointer+to+the+allocated+type
>>>
>>
>> Apparently originally that article contained
>>
>>> "Explicitly casting the return value of malloc() eliminates the
>>> warning for the implicit declaration of malloc()."
>>
>> … mentioned in the comments, which is lunacy.
>>
>
> Not at all lunacy.
>
>> Or, let me soften that: using casts to shut up the compiler is something
>> a first year student might do in the first month or so, but not a
>> competent programmer.
>>
>
> Or, in the case of pointers, ensuring the types are the same. There are
> no type conversions between pointers to different types, like there are
> with other types. Even a first year student understands that.

Oh. I'm sorry. This is not meaningful, it's nonsense.

> Personally, I take CERT's guidelines over any I see in a newsgroup.
> Those people know how to develop safe code.

You COULD look at the comments on that guideline.

Given the above avalanche of nonsense I guess relying on authority is a
reasonable strategy, but do be careful about that.

[Jerry Stuckle]

Ah, once again you can't argue facts, so you resort to denigrating comments.

>
>>>> The extra cast doesn't hurt anything (other than
>>>> add a few extra characters to the statement),
>>>
>>> That statement is a simple denial of a fact quoted by you above.
>>>
>>
>> Not at all. There is a relationship between the type of p and malloc.
>> And during development (or even during maintenance), the type of p may
>> need to be changed for one reason or another.
>
> Again I'm sorry but this is not meaningful; it's utter nonsense.
>

Ah, once again you can't argue facts, so you resort to denigrating
comments. The fact is - types DO change during both development and
maintenance.

>
>>>> but can protect against inadvertent problems.
>>>
>>> Yes it can, but at needless cost (no matter how you deny it: denial
>>> doesn't really work) and loss of clarity.
>>>
>>
>> The cost is only a few cycles at compile time - less, in fact, than the
>> cost of your macro.
>
> And yet again I'm sorry but this is not meaningful; it's utter nonsense.
>

Ah, once again you can't argue facts, so you resort to denigrating
comments. The truth hurts, doesn't it?

>
>>>> For CERT's recommendation see
>>>> https://www.securecoding.cert.org/confluence/display/c/MEM02-C.+Immediately+cast+the+result+of+a+memory+allocation+function+call+into+a+pointer+to+the+allocated+type
>>>>
>>>>
>>>
>>> Apparently originally that article contained
>>>
>>>> "Explicitly casting the return value of malloc() eliminates the
>>>> warning for the implicit declaration of malloc()."
>>>
>>> … mentioned in the comments, which is lunacy.
>>>
>>
>> Not at all lunacy.
>>
>>> Or, let me soften that: using casts to shut up the compiler is something
>>> a first year student might do in the first month or so, but not a
>>> competent programmer.
>>>
>>
>> Or, in the case of pointers, ensuring the types are the same. There are
>> no type conversions between pointers to different types, like there are
>> with other types. Even a first year student understands that.
>
> Oh. I'm sorry. This is not meaningful, it's nonsense.
>

It wouldn't be to you, but it is to a first year student.

Ah, once again you can't argue facts, so you resort to denigrating comments.

>
>> Personally, I take CERT's guidelines over any I see in a newsgroup.
>> Those people know how to develop safe code.
>
> You COULD look at the comments on that guideline.
>
> Given the above avalanche of nonsense I guess relying on authority is a
> reasonable strategy, but do be careful about that.
>

I did, and I stand by my comments.

Ah, once again you can't argue facts, so you resort to denigrating comments.

But then you expect people to rely on YOU - but not on CERT? It doesn't
work that way, Alf.

You have yet to show any reason why your way is better than CERTs. All
you have done is call CERTs recommendations "lunacy". The last resort
of those who can't argue facts.

>
> Cheers & hth.,
>
> - Alf

[Ian Collins]

On 06/ 7/17 09:15 AM, Jerry Stuckle wrote:

>
> Personally, I take CERT's guidelines over any I see in a newsgroup.
> Those people know how to develop safe code.

"Robert Seacord

Much earlier, John Bode suggested the following compliant solution:
widget *p;
...
p = malloc(sizeof *p);

as well as the use of Abstract Data Types (ADT). The ADT discussion is
probably orthogonal to this guideline, but the approach of taking the
sizeof *p seems to be a reasonable compliant solution that would seem to
be noncompliant given the title of this rule."

--
Ian

[Jerry Stuckle]

That is correct. And you should also notice that was not accepted as
the preferred solution, due to the reasons I mentioned.

[Dombo]

Op 06-Jun-17 om 18:38 schreef Tristan B. Kildaire:

Why not just use 'new'?

[Öö Tiib]

Because usually where 'new' is written in C++ code it is not best there.
Usually automatic variable or direct data member, 'std::optional',
'std::array', 'std::vector' or 'std::make_unique' are better, safer and
more efficient to use at that spot.

[Dombo]

Op 03-Jul-17 om 21:58 schreef Öö Tiib:

Let me rephrase the question (see the post I was replying to); why
prefer malloc() over 'new'?

I rarely use 'new' in C++ code and I cannot remember that last time I
used malloc() in C++ code, so I wonder why someone would ask how to use
malloc() in a C++ newsgroup?

[Chris Vine]

On Tue, 4 Jul 2017 18:43:18 +0200
Dombo <do...@disposable.invalid> wrote:
[snip]

> Let me rephrase the question (see the post I was replying to); why
> prefer malloc() over 'new'?

I generally use malloc() when I want uninitialized memory, say in which
objects are to be constructed with placement new. You could use
operator new instead, or even the new[] expression with an array of char
[1], but malloc() seems more "normal" to me.

Chris

[1] The effect would certainly be the same as malloc() for operator new.
I think the same is true of the new[] expression in that I think that
has to be aligned for any fundamental type, but I would need to look it
up to be sure.

[woodb...@gmail.com]

I'm looking forward to being able to write:

::std::unique_ptr request{new cmw_request(recbuf)};

rather than:

auto request=::std::make_unique<cmw_request>(recbuf);

in C++ 2017. Support for this isn't widely available
yet, though, from what I can tell.


Brian
Ebenezer Enterprises - In G-d we trust.
https://github.com/Ebenezer-group/onwards

[Alf P. Steinbach]

On 05-Jul-17 3:28 AM, woodb...@gmail.com wrote:
> I'm looking forward to being able to write:
>
> ::std::unique_ptr request{new cmw_request(recbuf)};
>
> rather than:
>
> auto request=::std::make_unique<cmw_request>(recbuf);
>
> in C++ 2017. Support for this isn't widely available
> yet, though, from what I can tell.
>

You can write that first declaration today, and you could from and
including C++11.

Using `make_unique` only matters when there are two or more `unique_ptr`
initializations in the same expression, since then a non-smart compiler
might let the `new` expressions be evaluated before the `unique_ptr`
initializations, and then what if the second `new` fails? Leak. Ouch.

As I understand it C++17 will make that use of `unique_ptr` unnecessary,
by constraining the evaluation order slightly.


Cheers!,

- Alf

[woodb...@gmail.com]

On Tuesday, July 4, 2017 at 9:14:26 PM UTC-5, Alf P. Steinbach wrote:
> On 05-Jul-17 3:28 AM, woodb...@gmail.com wrote:
> > I'm looking forward to being able to write:
> >
> > ::std::unique_ptr request{new cmw_request(recbuf)};
> >
> > rather than:
> >
> > auto request=::std::make_unique<cmw_request>(recbuf);
> >
> > in C++ 2017. Support for this isn't widely available
> > yet, though, from what I can tell.
> >
>
> You can write that first declaration today, and you could from and
> including C++11.
>

I have the above two lines here:
https://github.com/Ebenezer-group/onwards/blob/master/tiers/cmwAmbassador.cc

at lines 270 and 271. One of the lines is commented
out because I don't know of a compiler that accepts it
right now:

//::std::unique_ptr request{new cmw_request(recbuf)};

This thread is related:
https://groups.google.com/forum/#!topic/comp.lang.c++/m43-E2_msOw


Brian
Ebenezer Enterprises
http://webEbenezer.net

[Alf P. Steinbach]

I failed to see that there isn't any template argument for `unique_ptr`.

I think, from the reference to old discussion, that you're envisioning
constructor template argument deduction, as in <url:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4471.html>.

From what I understand of that paper they intend that the expression
`unique_ptr{ new T }` should be well-defined, deduced as `unique_ptr<T>{
new T }. But that wouldn't allow you to omit template argument in the
type in a declaration. You could use `auto` though.

* * *

The paper starts with the following example, which I've taken the
liberty of reformatting to more readable for me:


vector<int> vi1 = { 0, 1, 1, 2, 3, 5, 8 };

vector<int> vi2;

template< class Func > std::mutex m;

unique_lock<std::mutex> ul( m, std::defer_lock );

class Foo()
{
public:
Foo( Func f ) : func( f ) {}
void operator()(int i) { os << "Calling with " << i << endl; f(i); }
private:
Func func;
mutex mtx;
};


I /think/ that the author intended for the class to be a template,
starting with `template< class Func >`.


Cheers!,

- Alf

[woodb...@gmail.com]

On Wednesday, July 5, 2017 at 8:38:15 AM UTC-5, Alf P. Steinbach wrote:
> On 05-Jul-17 7:29 AM, woodb...@gmail.com wrote:
> >
> > I have the above two lines here:
> > https://github.com/Ebenezer-group/onwards/blob/master/tiers/cmwAmbassador.cc
> >
> > at lines 270 and 271. One of the lines is commented
> > out because I don't know of a compiler that accepts it
> > right now:
> >
> > //::std::unique_ptr request{new cmw_request(recbuf)};
> >
> > This thread is related:
> > https://groups.google.com/forum/#!topic/comp.lang.c++/m43-E2_msOw
>
> I failed to see that there isn't any template argument for `unique_ptr`.
>
> I think, from the reference to old discussion, that you're envisioning
> constructor template argument deduction, as in <url:
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4471.html>.
>
> From what I understand of that paper they intend that the expression
> `unique_ptr{ new T }` should be well-defined, deduced as `unique_ptr<T>{
> new T }. But that wouldn't allow you to omit template argument in the
> type in a declaration. You could use `auto` though.

Is this what you mean by using auto:

::std::unique_ptr<auto> { new T}

? Several months ago I applied a patch from professor
Spertus to a version of g++. After doing so I was able
to compile the line as I've written it here previously:

:std::unique_ptr request{new cmw_request(recbuf)};

. Professor Spertus saw my code and didn't say, "Hey,
you need to add auto ..."


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

[Alf P. Steinbach]

On 05-Jul-17 9:29 PM, woodb...@gmail.com wrote:
> On Wednesday, July 5, 2017 at 8:38:15 AM UTC-5, Alf P. Steinbach wrote:
>> On 05-Jul-17 7:29 AM, woodb...@gmail.com wrote:
>>>
>>> I have the above two lines here:
>>> https://github.com/Ebenezer-group/onwards/blob/master/tiers/cmwAmbassador.cc
>>>
>>> at lines 270 and 271. One of the lines is commented
>>> out because I don't know of a compiler that accepts it
>>> right now:
>>>
>>> //::std::unique_ptr request{new cmw_request(recbuf)};
>>>
>>> This thread is related:
>>> https://groups.google.com/forum/#!topic/comp.lang.c++/m43-E2_msOw
>>
>> I failed to see that there isn't any template argument for `unique_ptr`.
>>
>> I think, from the reference to old discussion, that you're envisioning
>> constructor template argument deduction, as in <url:
>> http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4471.html>.
>>
>> From what I understand of that paper they intend that the expression
>> `unique_ptr{ new T }` should be well-defined, deduced as `unique_ptr<T>{
>> new T }. But that wouldn't allow you to omit template argument in the
>> type in a declaration. You could use `auto` though.
>
> Is this what you mean by using auto:
>
> ::std::unique_ptr<auto> { new T}
>
> ?

I didn't think of that. Maybe the author(s) propose that. I was thinking

auto p = unique_ptr{ new T };

I'm sorry to have responded in an ungood way for the second time now.

If we ever should meet you are free to laugh derisively at me for a
period of your choosing, not exceeding 13 minutes.

> Several months ago I applied a patch from professor
> Spertus to a version of g++. After doing so I was able
> to compile the line as I've written it here previously:
>
> :std::unique_ptr request{new cmw_request(recbuf)};
>
> . Professor Spertus saw my code and didn't say, "Hey,
> you need to add auto ..."

Yeah. See above. (－‸ლ)


Cheers!,

- Alf

[Öö Tiib]

The differences of malloc compared to new[] (used for allocating raw
uninitialized buffer of bytes) are that it does not throw,
and that with malloc the buffer may be further resized using realloc.
These differences may give some benefit or not, it is always situational.

[Öö Tiib]

I don't know if we need multiple different ways to express exactly
same thing.

[Robert Wessel]

On Thu, 6 Jul 2017 15:16:35 -0700 (PDT), 嘱 Tiib <oot...@hot.ee>
wrote:

>On Tuesday, 4 July 2017 19:40:22 UTC+3, Dombo wrote:

>> Op 03-Jul-17 om 21:58 schreef 嘱 Tiib:

At least the first difference is usually eliminated by the use of the
nothrow variant of new.

[woodb...@gmail.com]

I consider 'make_unique' to be a bit of a kludge. If it had
been 'make_uniqueptr' that would have been a little better.

At any rate, this new form looks promising to me. A number
of things from C++ 2011 have largely displaced older forms.

Brian
Ebenezer Enterprises - In G-d we trust.

http://webEbenezer.net

[woodb...@gmail.com]

Due to refactoring of my code, support for class template
argument deduction has decreased on my wish list -- Christmas
in July. I still want string_view backported to C++ 2011
compilers. I'd also like this:

auto& request=
pendingRequests.emplace_back(::std::unique_ptr<cmw_request>());

-- emplace_back returning a reference to the inserted item -- to be
backported to 2011 compilers.

[Ian Collins]

On 07/10/17 01:23 PM, woodb...@gmail.com wrote:
>
> Due to refactoring of my code, support for class template
> argument deduction has decreased on my wish list -- Christmas
> in July. I still want string_view backported to C++ 2011
> compilers. I'd also like this:
>
> auto& request=
> pendingRequests.emplace_back(::std::unique_ptr<cmw_request>());
>
> -- emplace_back returning a reference to the inserted item -- to be
> backported to 2011 compilers.

Why on Earth would anyone want to do that?

--
Ian

[woodb...@gmail.com]

C++ 2011 was late and, when it did arrive, it was immature.
Ideally, string_view would have been a part of C++ 2011 or
earlier.

I make requests and let compiler vendors decide.