- how to copy a structure to a cstring - 4 Updates
- Best way to use enum with classes - 3 Updates
- Your eternal soul is at stake - 4 Updates
- What do people think about std::multimap? - 2 Updates
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:
Post a Comment