Friday, October 21, 2016

Digest for comp.lang.c++@googlegroups.com - 13 updates in 4 topics

woodbrian77@gmail.com: Oct 21 03:06PM -0700

On Friday, October 21, 2016 at 1:33:10 AM UTC-5, Öö Tiib wrote:
> There are references, containers, indexes, iterators etc. As result
> I know only few cases where I have to declare something to be
> of type raw pointer to something else.
 
I use references and containers also. The pointers that
remain after that are what I'm talking about.
 
 
> Please name at least 3 different cases where you need raw pointer and
> why. Making people to dig in your poorly documented code base to try to
> find it out themselves is fruitless, they don't have time for that.
 
The documentation isn't very good, but people are free to
take a look a look as you did in a recent thread about std::deque.
 
 
> > I work on an alternative to JSON.
 
> JSON is language neutral, so your C++ code generator can not replace its
> main use-cases.
 
Did the OP say he needs support for multiple languages?
 
I'm open to adding support for other languages, but I'm
waiting to see how things shake out. C++ is a sure thing.
Other languages aren't as obvious to me.
 
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 21 11:22PM +0100


> I'm open to adding support for other languages, but I'm
> waiting to see how things shake out. C++ is a sure thing.
> Other languages aren't as obvious to me.
 
He didn't mean that; he meant you don't have to compile JSON because
JSON is just text not a programming language.
 
/Flibble
"Öö Tiib" <ootiib@hot.ee>: Oct 21 04:03PM -0700

On Saturday, 22 October 2016 01:22:15 UTC+3, Mr Flibble wrote:
> > Other languages aren't as obvious to me.
 
> He didn't mean that; he meant you don't have to compile JSON because
> JSON is just text not a programming language.
 
Yes, CMW code generator of Brian can not compete with JSON because JSON
is not in same niche of Brian's CMW. The issues solved are orthogonal.
Most of the systems producing JSON are not even written in C++.
Therefore we can't replace JSON with CMW even if we wan't to.
Brian however can offer JSON as an optional alternative to his custom
binary format that his generated code transfers. That can make his CMW
stand somewhat stronger.
Brian does not seemingly recognize that cooperation and compatibility
are strengths but alienating and competition are waste of time.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 22 12:22AM +0100

On Fri, 21 Oct 2016 15:06:44 -0700 (PDT)
> > for that.
 
> The documentation isn't very good, but people are free to
> take a look a look as you did in a recent thread about std::deque.
 
You haven't answered the question. Please name at least 3 different
cases where you need raw pointers and why. (Actually, I would be
satisfied by 2, provided they didn't amount to evading the issue, but I
cannot speak for your interlocutor).
Jerry Stuckle <jstucklex@attglobal.net>: Oct 21 10:08AM -0400

On 10/21/2016 3:46 AM, David Brown wrote:
 
>> So no corrections.
 
> You mean you have accepted my corrections to your mistakes, and are
> happy that the description is now reasonably accurate?
 
Not at all. As I said. I was merely trying to simplify the situation
to be understandable to your miniscule knowledge.
 
>> a larger block from your application, it will be split into chunks no
>> larger than that.
 
> Jumbo frames, anyone?
 
Not at the hardware layer. The Ethernet spec limits it to 1500 bytes.
 
> are the impedance (resistance, capacitance, inductance) of the cable,
> how that affects the signal strength, and how it affects different
> frequencies.
 
Actually, it has *everything* to do with the lengths between the pairs,
as was discussed extensively in the TIA standards committee. I wasn't
part of the committee, but there has been a great deal of discussion in
the trade magazines as well as webinars explaining the decisions and why
they were made.
 
While only one pair for each transmit and receive is currently being
used, they were very concerned about how it would work when using
multiple pairs for each transmit and receive - as is used in 40Gb links?
 
> limitations in the same way. And lower category CAT cables suffer more,
> which is why their distance limitation is shorter than higher category
> cables.
 
While it is true the signal degrades over distance, it does not degrade
that significantly. And as you noted, the effect can largely be
compensated for. But while you are correct that lower CAT (which is
short for category - so "category CAT" is redundant) suffer more, CAT-5,
CAT-6, CAT-7 and CAT-8 all have the same 100M limitation.
 
> only one frequency transmitted (WDM excluded). There is a related
> problem with varying light path length through the cable, but it has
> much lower effect - thus fibre connections can reach tens of km.
 
Once again, incorrect - and you show you know nothing about fiber.
 
There are two types of fiber - single-mode and multi-mode (further
subdivided, but I'll keep it simple for you here).
 
Multi-mode fiber has a larger diameter (typically 50um or 62.5um), which
allows multiple reflections of the beam inside the fiber, resulting in
multiple modes at the other end. The result is signal distortion, and
limits fiber lengths to 2km or less, depending on bit rate. It can,
however, be driven with relatively inexpensive LEDs.
 
Single-mode fiber is smaller in diameter (typically 8-10.5um), limiting
the reflections within the fiber. The result is a single mode signal ad
the output and a much cleaner signal. Resulting distances can exceed 80km.
 
 
>> Ah, but they are. Every one of the slows down the signal a bit,
>> resulting in slower data transfer rates.
 
> No.
 
You really don't understand latency, do you?
 
>> the router or switch.
 
> Handshaking affects the latency (especially of connection setup), but
> not the throughput.
 
And handshaking doesn't affect throughput? Here's a clue. The
handshake cannot occur until the entire packet is received. Anything -
including latency - which slows the signal delays the handshake.
 
 
> I know better than you do, anyway.
 
> Hint - you can get a hell of a lot of TV channels through a satellite
> link. There is a massive bandwidth, despite the latency.
 
Sure you can. But there is no handshaking on a TV channel.
 
> Here's another hint - a lorry load of DVDs has a huge bandwidth, despite
> huge and somewhat unpredictable latency.
 
Ditto above.
 
But if latency weren't important, why would disk manufacturers spend
huge amounts of money adding caches to their drives? The ONLY think the
cache affects is latency.
 
 
> I did not mention them because they were not relevant. I also didn't
> mention that you can buy Ethernet cable in different colours, for the
> same reason.
 
What kind of cable? There is no such thing as "Ethernet cable". There
is category cable. There is coax cable. There is fiber optic cable.
Any of them can carry ethernet signals.
 
Once again you show your ignorance.
 
> or network backbones. And of course the average throughput on the links
> will be well below the peak rates - there are few applications where you
> have a long-term sustained source of data at such rates.
 
Even data centers know better than to think they can get 40Gb on a 40Gb
link for anything but a short burst. But then you've never been in a
real data center, have you? Hint: we have several within 25 miles of
me. Not only U.S. government, which is highly restricted. But Network
Solutions, Amazon and other commercial entities have data centers here.
 
> you are an expert. But when it comes to details, you are all over the
> place - you make things up as you go along, and when challenged you deny
> things, change the subject, add straw men, or insult people.
 
Nope, I am accurate on every point. And I'm not the one who keeps
changing the subject or deny things. And calling an you an idiot would
be an insult - to idiots.
 
> parameters of the situation, recommending the customer buy different
> equipment, etc. You don't actually /do/ anything, except pocket the
> money, because you are not able to do the engineering or development work.
 
That is correct. But I am successful as a consultant because I am
successful in satisfying my client's needs. I don't lie to them, and I
don't try to snow them. I do very little subcontracting, and cannot
change the parameters of the situation or different equipment, etc. -
because those are all fixed in the contract.
 
I am successful because I CAN do the engineering and development work.
I wouldn't have made it for over 25 years if I were like you think.
 
> am happy to be an engineer and developer. And when I do consultancy
> (which is also part of my job), it is as an experienced developer and
> engineer, rather than as a con man.
 
I'm glad you'll never make it as a consultant. We have too many people
like you already. Fortunately, they don't last more than 2-3 jobs
before word gets around. But those 2-3 jobs create a stain on the
entire consulting community.
 
> wanted help to make a high speed, high bandwidth network system, I would
> have to read and learn more before going into details, or even pass the
> job on to someone else.
 
Ah, but that's the difference between you and me. I can give customers
*detailed information* and it will be *accurate* as later tests have
always proven. I don't have to read and learn more before going into
the details because I've been there and done that. But it would take a
lot more than just reading and learning for you to give anyone help. It
takes years of experience.
 
> You, with your limited understanding of the basics and invented details,
> seem to think you /are/ qualified to work with modern high-speed networking.
 
Yup, as I've been proving for years. But then I started when 2400 bps
synchronous links were considered "high speed", back in the 70's.
 
>> a lot more experience than you do.
 
> Plugging in a few cables 40 years ago does not mean you have 40 years of
> experience in Ethernet!
 
Nope, because ethernet hasn't been around for 40 years. But it shows
experience that you can't begin to have.
 
 
I know what your real problem is. For years you've been snowing people
in this newsgroup to think you actually know something. But now when
someone who knows more than you comes along and challenges you, it
really bugs you. You aren't the "top dog" any more. Very typical of
someone with a severe inferiority complex.
 
Unlike you, I don't, and I don't need to be "top dog". I just want
people to know the truth, not the snow jobs you've been giving them.
 
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
scott@slp53.sl.home (Scott Lurndal): Oct 21 05:17PM

>On 10/21/2016 3:46 AM, David Brown wrote:
 
 
>> Jumbo frames, anyone?
 
>Not at the hardware layer. The Ethernet spec limits it to 1500 bytes.
 
As with much of what you say, that is only partially accurate. While
the 802.3 specification does not include jumbo frames, and thus it is not
a de jure standard, jumbo frames _are_ a de facto standard and are supported
by all modern hardware from network interface controllers to switches
and routers. At the hardware layer.
Jerry Stuckle <jstucklex@attglobal.net>: Oct 21 03:08PM -0400

On 10/21/2016 1:17 PM, Scott Lurndal wrote:
> a de jure standard, jumbo frames _are_ a de facto standard and are supported
> by all modern hardware from network interface controllers to switches
> and routers. At the hardware layer.
 
Yes, but companies running the internet servers still adhere to the
802.3 standard and support 1500 byte frames. Not necessarily all of
them, but enough that that's the largest frame you can send over the
internet in most cases.
 
There are always companies who will go create things outside the spec.
That doesn't mean it is usable.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 21 09:00AM -0700

Your eternal soul is at stake. Your choices in this world determine where
you'll go for all eternity.
 
-----
You are a sinner. You were born with original sin (spiritual death), and
you have since been fooled by Satan through your flesh to where you yourself
have committed many sins.
 
God is perfect and holy and righteous and He does not allow sin to dwell in
His presence. There is one punishment for sin: Death. And for an eternal
being, the only way to have an eternal being die is to have an eternal place
of confinement, which is why Hell was created.
 
-----
The "good news" message (the "gospel" message) is that none of us need to go
there. Even though we're all guilty, Jesus Christ has made a way out for us
to be saved.
 
You can have your sins forgiven, and you can enter in to eternal life.
 
This message is important. If you have not already considered it, please do
so now, because you are not promised tomorrow.
 
Best regards,
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 21 09:47AM -0700

Christians beheadings, crucifixions. Brave souls standing up for their
faith in outreach ministry to the very end:
 
http://archbishopcranmer.com/christian-missionaries-aleppo-crucified-beheaded/
 
"While we drink our Fair Trade coffee and pray for the recovery of our gay
pride flags, our brothers and sisters in Christ are risking everything to
share the gospel with those who are being lost. They suffer hell on earth
to keep people out of hell for eternity. What experience of Jesus have
they had which we do not? What God-consciousness do they possess which we
have not? What inner life fires them to such certainty, peace and the
assurance that to die is gain?"
 
Best regards,
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 21 10:51AM -0700

Listen to the song's lyrics:
 
Refining Fire - Michael Sykes
https://www.youtube.com/watch?v=-aOc-gzzU0g
 
"I'm dying to myself 'cause that's what you require.
I'll walk through your refining fire."
 
The Lord leads from within. The drawing we have comes from the born again
nature, the spirit nature, and it is invisible on the inside, not from a
book, not from a list of rules, but a new nature placed atop the old man,
supplanting the old man with the new man.
 
Best regards,
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 21 11:04AM -0700

I'm the Clay:
 
https://www.youtube.com/watch?v=ZspVv223YBA
 
If you really are the gentle wind,
let me feel your slightest whispered breath.
If you are the smallest drop of rain,
let me feel the moisture on my skin.
If you are a silent soothing voice,
let me hear your every single word.
If you walk down Heaven's golden streets,
let me sense your stirring in my heart.
 
[chorus]
 
You are the lover of my heart.
I am the dear devoted child.
You are the master of my mind.
I am the captive meek and mild.
You are the light to guide my feet.
I am the pilgrim on His way.
 
You say the word and I'll be there.
You are the Model, I'm the clay.
The clay.
 
If I have to sell all that I own.
If I have to give up all I have.
If I have to open up my hands.
If I have to wander the unknown.
If I have to wait 10,000 years.
If I have to suffer through the pain.
All my joy will come from knowing You,
the Hand that wipes away these tears.
 
[chorus]
 
Mmmmm-mmm-mmm.
I'm the clay.
Mmmmm-mmm-mmm.
 
-----
http://biblehub.com/kjv/isaiah/64-8.htm
8 But now, O LORD, thou art our father; we are the clay, and thou
our potter; and we all are the work of thy hand.
 
Best regards,
Rick C. Hodgin
Daniel <danielaparker@gmail.com>: Oct 21 09:17AM -0700

On Friday, October 21, 2016 at 10:55:19 AM UTC-4, Mr Flibble wrote:
 
> I've found that performance improves using it.
 
What did you specify as the template parameters for boost::fast_pool_allocator? Or did you take the defaults (apart from the first)?
 
boost::fast_pool_allocator uses a singleton pool, which requires
synchronization for thread safety, and the synchronization does affect
performance, especially if there really is contention. If you know your
application will never use more than the main thread, you can improve
performance by specifying a Mutex template parameter as null_mutex.
 
But I think I would prefer to use a stateful allocator.
 
Thanks,
Daniel
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 21 03:54PM +0100

On 21/10/2016 14:42, Öö Tiib wrote:
 
>> I've found quite the opposite. Your experiments are obviously flawed.
 
> You have found what opposite? that std::allocator is slower and that there
> is a way to free the pool 'under boost::fast_pool_allocator'?
 
I've found that performance improves using it.
 
/Flibble
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.

No comments: