Wednesday, March 22, 2017

Digest for comp.lang.c++@googlegroups.com - 25 updates in 8 topics

David Brown <david.brown@hesbynett.no>: Mar 22 09:24AM +0100

On 21/03/17 18:02, Rick C. Hodgin wrote:
 
> And the usefulness is obvious: Base classes are a particular
> generalized type. Inherited classes are a more specialized form
> of that general type.
 
That bit is true...
 
 
> It would be natural to be able to extend enums to include additional
> information that the base class knows nothing about in the more
> specialized form.
 
And that bit is confused.
 
You first say you want to /extend/ the first enum, which is fair enough.
Then you say the extended version is more specialised, which is wrong.
 
 
It is fine for a derived class to extend a base class - but only in a
way that does not invalidate the public interface of the base class.
 
So you can have a base class that supports "red", "green" and "blue".
And a derived class that supports "yellow" as well. But in that case,
what happens when you have an object of the derived class that happens
to be "yellow", and you access it through the base class? It no longer
makes sense - it is invalid as an object of the base class type.
 
It is, of course, entirely possible to make such a system work - you
could throw an exception when the colour is used via a type that does
not understand it. You can use virtual functions. You can do some sort
of conversion to map to valid colours. You could have the derived class
keep a new member for more "advanced" colours - and so on. You could
use templates rather than classes, and make the hierarchy merely a
source code convenience without allowing run-time class hierarchy.
 
But however you solve the problem, you no longer have the simple and
limited public interface of "enum" (or "enum class").
 
See also <https://en.wikipedia.org/wiki/Liskov_substitution_principle>
 
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 22 08:52AM -0700

On Tuesday, March 21, 2017 at 1:02:46 PM UTC-4, Rick C. Hodgin wrote:
 
> It would be natural to be able to extend enums to include additional
> information that the base class knows nothing about in the more
> specialized form.
 
In this case of extending enums, at no point is anything invalidated.
The definition of the child class deriving information from the parent
class introduces a new class, which is a new creation. Both are
distinct and separate, and both use their definition syntax (including
inheritance and extensions to inheritance) to produce their form.
 
Going backward would violate the acceptable values of the base class.
However, that is solidly the responsibility of the developer to be
aware of and address because it will require an explicit cast to be
valid to C++.
 
If you need a generic global enum, then make it global public. If
you're defining an enum within a class, there an explicit reason why
you're doing so. And if you're desiring to extend enums from a parent
class to greater specialization in the child class, then there's also
a reason why you're doing so.
 
Enums in general exist for a purpose, and their use in classes exist
for another extended purpose. The color Yellow has no validity in
the base class colors of Red, Green, Blue. It doesn't exist to that
class's knowledge so it's invalid.
 
If you cast a class from child (with Yellow) to parent (with only
Red, Green, Blue), then YOU are responsible for that cast. C++ does
not allow automatic type casting, but only explicit type casting,
which shift the burden of it being a compiler-requirement to ensure
the cast is an "acceptable conversion" away from the compiler, and
directly upon the shoulders of the developer (to where it should be
in my opinion).
 
I can think of half a dozen ways C++ could be extended to address
this issue by syntax and protocol requirements, but I think it's
such a non-issue that it's not worth implementing those features.
 
Thank you,
Rick C. Hodgin
kus <bhattacharya.kushal4@gmail.com>: Mar 22 03:48PM +0530

HI,
Sorry i think i mistakenly ignored my own thread.
Thats why i think i cant see it in my news reader.
Now coming to my point.I am manually creating the threads
and it is working fine.But when i am creating those
detached threads in loop for say that many times
i am getting segmentation fault.Why am i
getting this behaviour ?
Thanks,
Kushal
Paavo Helde <myfirstname@osa.pri.ee>: Mar 22 05:47PM +0200

On 22.03.2017 12:18, kus wrote:
> detached threads in loop for say that many times
> i am getting segmentation fault.Why am i
> getting this behaviour ?
 
You have a bug in your code. My crystal ball says it is on line 447.
"Öö Tiib" <ootiib@hot.ee>: Mar 22 07:49AM -0700

On Tuesday, 21 March 2017 19:35:59 UTC+2, Rick C. Hodgin wrote:
> Christianity is not religion, it's a close, personal
> relationship with Jesus Christ. We come to Him asking for forgiveness,
> and in so doing are saved.
 
Jesus Christ does not either exist or does not want you to rave here.
What a god would need raving lunatics like you to post about him
in inappropriate places? Why? Nonsense. Gods are not supposed
to be that powerless.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 22 08:04AM -0700

On Wednesday, March 22, 2017 at 10:49:38 AM UTC-4, Öö Tiib wrote:
> What a god would need raving lunatics like you to post about him
> in inappropriate places? Why? Nonsense. Gods are not supposed
> to be that powerless.
 
There is one reason why you feel my posts are the ravings of a
lunatic, because they aren't. It's because there's an enemy of
God at work in this world who teaches us falsely. He teaches
against our sin nature so that we naturally drawn toward His
teachings. He is also present with us in our daily lives, such
that we, also by influence of our sin nature, are able to be
deceived with false thoughts, false feelings, being able to
conclude that something which is right and true and proper (the
teachings of Jesus Christ, for example) are, in our view, not
proper. That doesn't change their validity, however.
 
If you take the time to pursue the knowledge and Kingdom of
Jesus Christ, as taught in the Bible, then you will come to
understand things correctly, which will lead to you coming to
Christ and receiving salvation.
 
I urge you to do this, Öö Tiib. You are a beautiful and truly
remarkable creation of God. He has prepared a place for you
in Heaven and I would like to see you paint that place with
all that is uniquely and distinctly you, making it your Home,
making it out to your style and stamp.
 
Until we are forgiven for our sin, the only future we have is
in Hellfire because of judgment for sin. But if Jesus forgives
our sin, and takes it away from us, then we are set free and
our future will be in God's paradise in Heaven with Him for
all eternity, outside of time even ... existing in a way we do
not yet know, and cannot even speak about here upon the Earth
in our present form (http://biblehub.com/kjv/2_corinthians/12-4.htm).
 
There is so much more ahead, Öö Tiib. I don't want you or anyone
else to miss out on any of it. Jesus makes it possible for us to
have all of it. He, and He alone, because of what He did for us
at the cross.
 
Thank you,
Rick C. Hodgin
Christopher Pisz <christopherpisz@gmail.com>: Mar 22 07:36AM -0700

I've got a block of code that throws an Access Violation when executed. It is the async_connect handler for boost::asio.
 
//------------------------------------------------------------------------------
void MyClient::OnConnect(const boost::system::error_code & errorCode, boost::asio::ip::tcp::resolver::iterator endpoint)
{
if (errorCode || endpoint == boost::asio::ip::tcp::resolver::iterator())
{
// Error - An error occured while attempting to connect
// Most likely these error codes correspond to https://msdn.microsoft.com/en-us/library/windows/desktop/ms740668(v=vs.85).aspx
std::ostringstream msg;
msg << "An error occured while attempting to connect to " << endpoint->host_name()
<< ". Error code: " << errorCode
<< ". Error Message: " << ErrorCodeToString(errorCode);
 
LogError(msg.str().c_str(), __FUNCSIG__, __FILE__, __LINE__);
return;
}
 
// We connected to an endpoint
m_connectionState |= CONNECTED;
 
In the debugger it looks like the problem is inside endpoint->host_name(), because it tried to get values_[0] while values_ are null.
 
This is a common Connection Refused scenario. I thought the handler got the endpoint so that it knew who it was trying to connect to! Is there some manner of check I can do on the iterator before I try to call a method on it?
 
It seems to pass and still throw access violation on
if( endpoint != boost::asio::ip::tcp::resolver::iterator() )
{
std::string blah = endpoint->host_name();
}
"Öö Tiib" <ootiib@hot.ee>: Mar 22 06:23AM -0700

> Is there a more well worn idiom for a class that, by default, will own its own
> resource, but will also be happy to have that resource externally created/managed?
 
Motivating example of problem is missing for me for such
"maybe managing".
kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Mar 21 11:45PM -0700

Hi,
Could anyone please guide me how to make detached thread in a loop.I am getting some errors making it.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 22 08:29AM +0100

On 22-Mar-17 7:45 AM, kushal bhattacharya wrote:
> Could anyone please guide me how to make detached thread in a
> loop.I am getting some errors making it.
 
Technically,
 
for( int i = 1; i <= 3; ++i ) { thread{ &my_func }.detach(); }
 
Add any thread function arguments as additional arguments after the
function address.
 
But I strongly suspect that creating detached threads is not a solution
to your problem, that instead it will turn out to be a problem itself.
What are you trying to solve by doing this? Why do you want to detach
the threads?
 
 
Cheers & hth.,
 
- Alf
kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Mar 22 12:33AM -0700

hi,
Actually i want all those preswaned threads to run all the time for infinite amount of time until the program is ended
kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Mar 22 12:37AM -0700

Those threads should run in background
and should not block execution context
kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Mar 22 12:46AM -0700

Actually to be clear these thread are used for transmitting packets so these are run in background so that they can fetch message and deliver packets to client
kus <bhattacharya.kushal4@gmail.com>: Mar 22 02:15PM +0530

On Wednesday 22 March 2017 12:15 PM, kushal bhattacharya wrote:
> Hi,
> Could anyone please guide me how to make detached thread in a loop.I am getting some errors making it.
 
hi
kus <bhattacharya.kushal4@gmail.com>: Mar 22 02:17PM +0530

On Wednesday 22 March 2017 12:15 PM, kushal bhattacharya wrote:
> Hi,
> Could anyone please guide me how to make detached thread in a loop.I am getting some errors making it.
 
test message from thunderbird
kus <bhattacharya.kushal4@gmail.com>: Mar 22 02:19PM +0530

On Wednesday 22 March 2017 12:59 PM, Alf P. Steinbach wrote:
> the threads?
 
> Cheers & hth.,
 
> - Alf
hii i think the thunderbird is working fine now
kus <bhattacharya.kushal4@gmail.com>: Mar 22 02:31PM +0530

On Wednesday 22 March 2017 12:59 PM, Alf P. Steinbach wrote:
> the threads?
 
> Cheers & hth.,
 
> - Alf
Am i clear about my scenario now?
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 22 10:43AM +0100

On 22-Mar-17 9:47 AM, kus wrote:
>> Could anyone please guide me how to make detached thread in a loop.I
>> am getting some errors making it.
 
> test message from thunderbird
 
Yes, that works.
 
You're posting with
 
 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.7.0
 
 
Cheers!,
 
- Alf
kus <bhattacharya.kushal4@gmail.com>: Mar 22 03:19PM +0530

On Wednesday 22 March 2017 12:59 PM, Alf P. Steinbach wrote:
> the threads?
 
> Cheers & hth.,
 
> - Alf
hiii,
I came up with an idea about fetching threads from a configuration file.
Is it feasible?I mean about background threads here
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Mar 22 12:45AM

On Tue, 21 Mar 2017 14:05:31 -0700
"Chris M. Thomasson" <invalid@invalid.invalid> wrote:
[snip]
> > a lock free queue.
 
> Well, certain lock-free queues can be totally exception safe in the
> sense that the functions can be marked as nothrow.
 
Yes, but then they are queuing pointers to objects. Leaving aside
memory exhaustion, that is nothrow in any implementation, and not
really the context that we were talking about.
"Chris M. Thomasson" <invalid@invalid.invalid>: Mar 21 05:49PM -0700

On 3/21/2017 5:45 PM, Chris Vine wrote:
 
> Yes, but then they are queuing pointers to objects. Leaving aside
> memory exhaustion, that is nothrow in any implementation, and not
> really the context that we were talking about.
 
Fair enough. They work a lot better with POD's.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 22 01:03AM +0100

On 22-Mar-17 12:05 AM, Chris M. Thomasson wrote:
>> characterization, or for that matter, at all.
 
> I feel a bit cheated right now. Almost like everything I posted might
> have been in vain. Damn.
 
No, investigation & exploration & development of techniques is IMO never
in vain. Even if, as might be the case for some postings, and as Bonita
claims, there is currently little practical use /in some given niche/.
However, regarding her claims about what common usage patterns are, and
her claims about implications of that for your work, I'd consult others
about it. Don't know who, though. But maybe you do. ;-)
 
 
> The comparison to Ramine's behavior was pretty gnarly Alf.
 
It's only poison.
 
Now listen to Alice Cooper singing about a girl, who, in the video, is
beautiful, or at least not the least bit unattractive. You'd never guess
that he was/is a religious nutcase, now would you? But yes, Christian
and all: that's why he thinks that this girl, or his attraction to her,
must be Evil™. But she's really not that special, she just (like many
others) behaves provocationally, without thinking, at times. And in the
end it's all just ordinary, so /very ordinary/. :)
 
<url: https://www.youtube.com/watch?v=Qq4j1LtCdww>
 
 
Cheers!,
 
- Alf (off-topic rant mode)
"Chris M. Thomasson" <invalid@invalid.invalid>: Mar 21 05:23PM -0700

On 3/21/2017 5:03 PM, Alf P. Steinbach wrote:
 
> No, investigation & exploration & development of techniques is IMO never
> in vain. Even if, as might be the case for some postings, and as Bonita
> claims, there is currently little practical use /in some given niche/.
 
At least when one needs them, they are there in the toolbox. ;^o
 
 
> However, regarding her claims about what common usage patterns are, and
> her claims about implications of that for your work, I'd consult others
> about it. Don't know who, though. But maybe you do. ;-)
 
Another place where I have seen work in lock-free is game design wrt
highly efficient queues. Databases are another one. Take the following
talk into account:
 
https://youtu.be/qcD2Zj9GgI4
 
These exotic algorithms are important. Niche as they may be.
 
 
> others) behaves provocationally, without thinking, at times. And in the
> end it's all just ordinary, so /very ordinary/. :)
 
> <url: https://www.youtube.com/watch?v=Qq4j1LtCdww>
 
Poison: https://youtu.be/Qq4j1LtCdww
;^)
"Chris M. Thomasson" <invalid@invalid.invalid>: Mar 21 05:27PM -0700

On 3/21/2017 5:23 PM, Chris M. Thomasson wrote:
>> On 22-Mar-17 12:05 AM, Chris M. Thomasson wrote:
>>> On 3/21/2017 3:12 PM, Alf P. Steinbach wrote:
>>>> On 21-Mar-17 11:00 PM, Bonita Montero wrote:
[...]
 
>> <url: https://www.youtube.com/watch?v=Qq4j1LtCdww>
 
> Poison: https://youtu.be/Qq4j1LtCdww
> ;^)
 
Perhaps I can say only the crazy would ever even think about lock-free!
 
Welcome to the nightmare.
"Chris M. Thomasson" <invalid@invalid.invalid>: Mar 21 05:34PM -0700

On 3/21/2017 2:26 PM, Chris M. Thomasson wrote:
> Check this shi% out:
 
> https://www.google.com/patents/US8543743
 
> ;^o
 
Heck, even semaphores out there:
 
https://www.google.com/patents/US8392627
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)