- Italian meat dishes (Was: neos) - 16 Updates
- is there any UB in this integer math... - 5 Updates
- how to get random value - 3 Updates
- [Jesus Loves You] Why do I post Christian messages? - 1 Update
| gazelle@shell.xmission.com (Kenny McCormack): Feb 24 09:18PM In article <a673e2bf-75bf-4853-9cf1-0813fe126d92@googlegroups.com>, Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: ... >"Ravioli. >"Ravioli... >"Ravioli." Lasagne Lasagne Lasagne -- Modern Christian: Someone who can take time out from using Leviticus to defend homophobia and Exodus to plaster the Ten Commandments on every school and courthouse to claim that the Old Testament is merely "ancient laws" that "only applies to Jews". |
| David Brown <david.brown@hesbynett.no>: Feb 25 09:24AM +0100 On 24/02/2019 16:16, Mr Flibble wrote: > There is no feature creep going on: it has always been the intention > that neoGFX will have a scripting engine but it makes sense to make the > engine a separate project. I must admit I assumed your first post here was a parody of Rick. The suspicious part is that you did not include any pseudo-religious waffle. But the "I am going to re-invent half the computing world solely because it will be /my/ version" part was there, along with a bold claim that you alone would handle a project that would normally be estimated at hundreds of man-years of effort. Including a scripting engine in neoGFX makes sense. Trying to make a "universal compiler" that supports Ada, JavaScript, Python, Lua, Forth and maybe C - that makes far, far less sense. The key questions you have to ask yourself are: 1. Who is going to use it? 2. Why are they going to choose this system rather than another one? 3. Why are they going to choose this language rather than a different one? 4. This work will take time and effort - is it the most important use of your time and effort? (Note - "it's fun" and "I want to do it" are perfectly good reasons, if you are economically free to make the choice.) I think it is reasonable to say right at the start that there are precisely /zero/ Forth or Ada programmers who would be interesting it using those languages along with neoGFX. And there will be precisely /zero/ users of neoGFX who would be interested in learning Ada or Forth in order to use them there. People might well be interested in using Python with neoGFX (that would interest me). But almost certainly what they will want is Python bindings for neoGFX - they would want to write their software in Python and use neoGFX for the gui, just as they do today with TKinter, wxPython or QT for Python. I can't imagine that anyone would want to make, say, a C++ application with neoGFX and attach Python as a scripting language. Lua and JavaScript, on the other hand, are perfect candidates. Both are very popular as scripting languages for this sort of thing - and in both cases you can use existing projects to provide the interpreter, bytecode and VM. Surely it would make most sense to integrate an existing JavaScript or Lua system into neoGFX, and then build out from there? You may have grand overall plans, and thus this is not "feature creep" - but it is still wise to take smaller steps at a time. |
| leigh.v.johnston@googlemail.com: Feb 25 01:23AM -0800 On Monday, February 25, 2019 at 8:24:25 AM UTC, David Brown wrote: > Lua system into neoGFX, and then build out from there? > You may have grand overall plans, and thus this is not "feature creep" - > but it is still wise to take smaller steps at a time. Hi David! The substantive urgency with which you genuflect toward the status quo and existing paradigms just strengthens my belief that I am on the right track. For example the very thought of pulling in Chrome/V8 as a dependency and having to interface with that shite in order to support just one scripting language (JavaScript) couldn't be any more egregious in my mind. /Leigh/Flibble |
| queequeg@trust.no1 (Queequeg): Feb 25 10:00AM > Work on neos my universal compiler that can compile ANY programming > language is progressing. Initial language implementations will be Ada, > JavaScript, Python, Lua and Forth then maybe C. Show effects, not promises. -- https://www.youtube.com/watch?v=9lSzL1DqQn0 |
| leigh.v.johnston@googlemail.com: Feb 25 02:06AM -0800 On Monday, February 25, 2019 at 10:00:40 AM UTC, Queequeg wrote: > > language is progressing. Initial language implementations will be Ada, > > JavaScript, Python, Lua and Forth then maybe C. > Show effects, not promises. I hope to get "Hello, world!" working in Ada by next weekend .. screenshots will be provided. /Leigh/Flibble |
| David Brown <david.brown@hesbynett.no>: Feb 25 11:23AM +0100 > The substantive urgency with which you genuflect toward the status > quo and existing paradigms just strengthens my belief that I am on > the right track. I'm sorry to hear that - as it makes you sound more fanatical, and more like Rick, and will convince others that you are on the /wrong/ track. This is a sad day for neoGFX - it looks like a very nice and innovative toolkit, and it would be a shame to spoil it by such a dramatic loss of focus. There is nothing wrong with wanting to invent a better wheel. But there /is/ something wrong with trying to re-invent everything at once rather than doing it in bits. Take existing parts, and use them first to build your complete system. Then see what parts are most in need of replacement or re-writes, and tackle them at that point. > as a dependency and having to interface with that shite in order to > support just one scripting language (JavaScript) couldn't be any more > egregious in my mind. Sorry, who suggested using Chrome as a dependency here? Not I, at any rate. As a first suggestion I'd look at a project such as <https://duktape.org/> for a JavaScript engine. Three files, runnable on embedded systems with 160KB flash and 64K ram - it is hardly going to break your resource budget. Off-the-shelf Lua is in the same range. |
| leigh.v.johnston@googlemail.com: Feb 25 02:48AM -0800 On Monday, February 25, 2019 at 10:23:19 AM UTC, David Brown wrote: > <https://duktape.org/> for a JavaScript engine. Three files, runnable > on embedded systems with 160KB flash and 64K ram - it is hardly going to > break your resource budget. Off-the-shelf Lua is in the same range. Duktape doesn't have a JIT. Listen David, you are not cognisant of my vision and you are underestimating my technical abilities. I am not RCH -- I do know what I am doing. I know how to design software based on decades of experience learning both from my successes and mistakes. Once the infrastructure for my universal compiler is in place adding support for a particular programming language would be almost trivial. This is a functional requirement of my architecture. /Leigh/Flibble |
| David Brown <david.brown@hesbynett.no>: Feb 25 02:10PM +0100 >> hardly going to break your resource budget. Off-the-shelf Lua is >> in the same range. > Duktape doesn't have a JIT. True. JIT systems are big and complex, and are tightly tied to specific systems. Are you sure that scripts run from within neoGFX are going to be so big and demanding that a JIT strategy is worth the effort? As you say, I don't know your vision. But it would surprise me greatly if that were the case. And are you convinced that your users would rather wait a few years (this is, I think, being wildly optimistic) for a solid and reliable JIT compiler that will handle a dozen different languages they will never use - or would they prefer a simple working Lua and/or JavaScript interpreter here and now? > Listen David, you are not cognisant of my > vision and you are underestimating my technical abilities. I don't know your vision, or your abilities (judging from what I have seen, they are very good but not super-human). That is why I am asking questions and making suggestions - to be sure that you have considered what makes sense for you and your project. The appearance you have given in this thread suggests that you are /not/ making sensible choices or realistic plans. It may be that you have not made yourself clear, or have some secret methods that we don't know about. I am throwing up questions - only you can answer them. (And you have mostly avoided them so far.) > mistakes. Once the infrastructure for my universal compiler is in > place adding support for a particular programming language would be > almost trivial. This is a functional requirement of my architecture. You are not Rick - that much is true. But there are similarities here - surely you cannot be surprised that people thought your post was a parody of him. Do you have any experience with Ada, Forth, JavaScript, Python and Lua? The Ada language standard, for example, is 832 pages long. That you can describe implementing it as "almost trivial" suggests that either you have many well-hidden talents, or you /don't/ know what you are doing. (Note that I am writing all this because I think neoGFX is a great idea, and would be happy to see it succeed - wild optimism about a one mad universal super-compiler seems a good way to make it fail.) |
| scott@slp53.sl.home (Scott Lurndal): Feb 25 02:19PM >1) you compared apples with oranges: my projects are serious whilst >Hodgin's are toy; >2) you are underestimating my technical ability. You both do have hubris in common... |
| leigh.v.johnston@googlemail.com: Feb 25 06:28AM -0800 On Monday, February 25, 2019 at 2:19:38 PM UTC, Scott Lurndal wrote: > >Hodgin's are toy; > >2) you are underestimating my technical ability. > You both do have hubris in common... Confidence is often mistaken for hubris by those who have neither. /Leigh/Flibble |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 25 07:16AM -0800 > On Monday, February 25, 2019 at 2:19:38 PM UTC, Scott Lurndal wrote: > > Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> writes: > > >2) you are underestimating my technical ability. A scene leaps to mind: Beginning at 3:48: https://www.youtube.com/watch?v=7tzqehBgi4I&t=3m48s > > You both do have hubris in common... > Confidence is often mistaken for hubris... People seeking to attack others also often assert "hubris" as a blanket assessment, rather than seeking to know the truth of the situation, or the true goals of the individual. I've looked at your work, Leigh. I have no doubts in your technical abilities. I believe you will suceed in what you set your mind to, and I am sincere in my wishing you great success. I am equally sincere in trying to teach you the truth about sin and spiritual influences ... but, you will not point your high intellect toward that saving knowledge. You will undoubtedly have success here in this world, but it will be short-lived without Christ, without forgiveness of your sin. You are as Anakin ... so full of blind rage against the truth you cannot see it, nor will you hear it. But there is hope. Vader eventually saw the light. It's possible you will too. I am envious of your passion and accomplishments. You have had a goal and a vision and you've remained focused upon it for years. The success you achieve will be well-earned, well-deserved, and I do wish you bug-free code, and feature-rich options. -- Rick C. Hodgin |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Feb 25 12:14PM -0500 >>> 2) you are underestimating my technical ability. >> You both do have hubris in common... > Confidence is often mistaken for hubris by those who have neither. But it's even more common for hubris to be mistaken for confidence by those who have hubris. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 25 09:16AM -0800 On Monday, February 25, 2019 at 12:14:44 PM UTC-5, James Kuyper wrote: > > Confidence is often mistaken for hubris by those who have neither. > But it's even more common for hubris to be mistaken for confidence by > those who have hubris. Look at his code and judge for yourself. Leigh's got game. -- Rick C. Hodgin |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 25 05:26PM On 25/02/2019 15:16, Rick C. Hodgin wrote: > a goal and a vision and you've remained focused upon it for years. > The success you achieve will be well-earned, well-deserved, and > I do wish you bug-free code, and feature-rich options. Not true. I have only been thinking about creating a C++ GUI library to compete with the likes of Qt's for the past 10 years only seriously starting to tackle it 3.5 years ago; last year I decided to change the scope of neoGFX to be a full blown app/game creation framework so I am now competing with the likes of Unity and Unreal Engine and only in the past few weeks did I decide to make the neoGFX scripting engine a separate project with a universal compiler. A universal compiler makes sense if you want the framework to support everyone's favourite scripting language and of course it has a nice side benefit of an explicit separation of concerns: the language and the implementation. /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| gazelle@shell.xmission.com (Kenny McCormack): Feb 25 05:28PM In article <4eb9d972-a336-478e-937c-be4fb1a4fd2e@googlegroups.com>, >> But it's even more common for hubris to be mistaken for confidence by >> those who have hubris. >Look at his code and judge for yourself. Leigh's got game. I get where you are coming from. I'm sure he is every bit as competent as you are. So, from your POV, it must look good. You two are so meant for each other. -- They say compassion is a virtue, but I don't have the time! - David Byrne - |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 25 05:31PM On 25/02/2019 17:28, Kenny McCormack wrote: > you are. > So, from your POV, it must look good. > You two are so meant for each other. You are asserting that without actually looking at my code? Remember what Christopher Hitchens said about assertions based on no evidence Kenny. You are indeed a fucktard. /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| "Öö Tiib" <ootiib@hot.ee>: Feb 25 02:17AM -0800 On Saturday, 23 February 2019 17:18:29 UTC+2, David Brown wrote: > a useful job despite that. Turning these potential bugs into crashes > and error messages simply guarantees that it will /not/ do a useful job > (though it may mean the bugs get found and fixed faster). Then I do not understand how the crashes on those bugs that are reached only on tiny fraction of actual cases turn the software useless. > the source code could all turn them into /real/ problems. But they > won't be spotted using testing. And options like -ftrapv can make them > /real/ problems. Earlier discovery is still clearly better statistically. Casual incorrect behavior of unknown nature takes at least ten times more time to be tracked down and eliminated than crash. Reporting crashes is easy to automate. Even if only quarter of such crashes did prevent misbehavior and rest did not then we still get more than two times less misbehaviors in total. > I am saying "Don't always halt on all errors - consider carefully how to > deal with them." And you are saying "Don't always ignore errors - > consider carefully how to deal with them". Everybody should consider best ways to handle known issues. For me the discussion was about unknown errors that are there but about what our best efforts so far have given no indications. Basically during program run it has unexpected positive insanity check (or negative sanity check). Best would be to report it and roll back to sane situation. We have no insanity barriers in process and we can not estimate where it started and to where it has spread. Safest seems to halt the process. > > written by programmer and so it is not handled and no one did notice. > Make your checks positive, not negative - check that the data fits the > patterns you want, rather than checking for patterns that you know are bad. It is orthogonal in what way the missing check supposedly is. Regardless if it is checking if the program is sane or insane It is just not there at all. > > Raise hands who has not forgotten to add such a check anywhere > > in last ten thousand of lines of code they wrote. I see none such hands. Regardless if the checks are positive or negative I observe zero hands. |
| "Fred.Zwarts" <F.Zwarts@KVI.nl>: Feb 25 01:34PM +0100 schreef in bericht news:bb9ae4ae-8993-42c9-a7f8-bf83ac21e383@googlegroups.com... >entirely upon the context. The only unambiguously wrong approach is to >assume that there's a single correct choice that is the same in all >contexts. Indeed. Unfortunately, for a program with unknown bugs, it is not very easy to predict what the context will be when a bug is encountered. In the case of an airplane controller, the consequences of undefined behaviour can be very serious. I would prefer to switch off the automatic controller and to switch to manual mode, instead of continuing an airplane controller with undefined behaviour. But for a computer game it may be fun to continue with undefined behaviour. |
| David Brown <david.brown@hesbynett.no>: Feb 25 01:54PM +0100 On 25/02/2019 11:17, Öö Tiib wrote: >> (though it may mean the bugs get found and fixed faster). > Then I do not understand how the crashes on those bugs that are > reached only on tiny fraction of actual cases turn the software useless. (I am not sure what you are saying here.) > Earlier discovery is still clearly better statistically. Casual incorrect behavior > of unknown nature takes at least ten times more time to be tracked down > and eliminated than crash. I agree. That is why testing is so important. (And also why static testing and compile-time warnings are so useful.) You should put a good deal of effort into identifying problems as soon as possible, before release. But once you are talking about release, the balance changes. Your aim is typically that any bugs in the code should present the least possible problems to the user. That might mean "crash and report" - causing short-term inconvenience with an aim to improvements in the long term. But it might equally mean "Run quickly, ignore potential bugs and hope there are no real effects" to maximise short-term usability of the software. There is no single correct answer. "Run slowly, crash on any possible overflow error but ignore all other errors, and hope that the user reports in a useful manner", or "-ftrapv", is very unlikely to be the best choice. > Reporting crashes is easy to automate. For some kinds of programs, yes. For others, no - it is impossible to automate. You are making sweeping statements generalised from only some possible types of software. > Best would be to report it and roll back to sane situation. We have no > insanity barriers in process and we can not estimate where it started > and to where it has spread. Safest seems to halt the process. My argument is merely that "safest seems to halt the process" is, in many cases, wrong. And even when it might be appropriate, the cost in performance may be an issue (not every system is performance critical, of course). And in general, sweeping generalisations are wrong most of the time. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Feb 25 12:11PM -0500 On 2/25/19 07:34, Fred.Zwarts wrote: > schreef in bericht > news:bb9ae4ae-8993-42c9-a7f8-bf83ac21e383@googlegroups.com... You should normally include the name (or at least, the userid) of the person you're quoting. ... >> contexts. > Indeed. Unfortunately, for a program with unknown bugs, it is not very easy > to predict what the context will be when a bug is encountered. Not really. In the case of program controlling a vending machine, you're guaranteed that the context is "vending snacks". In the case of a program controlling the launch of nuclear weapons, you're guaranteed that the context is "nuclear weapons launch". If you use exactly the same approach in both contexts, you're either wasting time and money putting way too much effort into dealing with possible defects in your vending machine code, or you're taking excessively large risks by putting way too little effort into dealing with possible defects in your nuclear launch code - quite possibly both. It is a popular design goal to make sure that when failures occur, they do so in the safest possible manner - the technical term for this is "failsafe". However, what constitutes "safest" is also context dependent. Ordinarily, for instance, it would be safest for a missile to not explode. But what if successful detonation of that missile somewhere near it's intended target is essential to preventing your own forces from being on the receiving end of subsequent attacks? If a failure occurs that substantially reduces, but does not eliminate, the possibility of hitting that target, it may be safer (for the source, not the target) if the missile deals with that failure by continuing to do it's best to hit that target. > controller and to switch to manual mode, instead of continuing an airplane > controller with undefined behaviour. But for a computer game it may be fun > to continue with undefined behaviour. What if manual mode is essentially unusable? Traditionally, many airplanes were designed to be "inherently stable" - if the plane were rolled slightly to the right, and you let go of the controls, it would have a built in tendency to start rotating to the left. If it were pitched downward, and you let go of the controls, it would have an innate tendency to start pitching upward. This was a very valuable safety feature - in many contexts. However, many modern planes are designed to be inherently unstable - if rolled slightly to the right, and you take your hands off the controls, they have an innate tendency to start rolling to the right faster. Why would anyone do that? Because an inherent consequence of such instability is that the plane is more maneuverable. Special electronics is used to initiate corrective actions more quickly and more precisely than any human could. In essence, software is used to make an inherent unstable plane emulate an inherently stable plane - but much more maneuverable. As a result, such planes can be difficult, maybe even impossible, to fly manually, by anyone with less that superhuman reflexes. So, when the software controlling such a system runs into a problem that degrades it's ability to control your plane (for instance, by having damaged sensors reporting invalid values that trigger overflows), would you be better off having the program simply abort, or to continue running with degraded control? That depends critically upon how badly degraded the control is. |
| "Öö Tiib" <ootiib@hot.ee>: Feb 25 09:11AM -0800 On Monday, 25 February 2019 14:54:23 UTC+2, David Brown wrote: > > Then I do not understand how the crashes on those bugs that are > > reached only on tiny fraction of actual cases turn the software useless. > (I am not sure what you are saying here.) You said "If they were all to stop with an error report on each bug, the software would be useless until all bugs were eliminated." My point was that it is false dichotomy and not how the actual reality works. In reality the conditions under what most of still undiscovered bugs manifest are reached very rarely. Did you test it at all? Yes. So it is obvious why. So there can be hundreds of bugs in calculations of product, each one guaranteed to crash thanks to that -ftrapv, each even easy to reproduce once discovered *and* also hundreds of thousands users monthly using it with not a single crash actually happening. So how did -ftrapv turn the program suddenly into useless? > testing and compile-time warnings are so useful.) You should put a good > deal of effort into identifying problems as soon as possible, before > release. None of what was discarded nor replaced with -ftrapv. > possible overflow error but ignore all other errors, and hope that the > user reports in a useful manner", or "-ftrapv", is very unlikely to be > the best choice. Again built up argument? What program will perform "very slowly"? Most stuff on current hardware is I/O bound. What "but ignore all other errors"? I suggested to crash only on all programming errors. Basically do not turn off sanity checks like specify NDEBUG, turn off -ftrapv etc. Ok, twice bigger executable binary (that is anyway only fraction of all the files and data) and 5% worse overall performance. Is it factor? It does no way mean that I suggested usage of crashes as a form of user input validation or -ftrapv as replacement to testing or that I do not care about performance or whatever other such strawman nonsense. > For some kinds of programs, yes. For others, no - it is impossible to > automate. You are making sweeping statements generalised from only some > possible types of software. Even for software with no persistent external communications it is easier to automate reporting crashes and hangs than to automate reporting misbehaviors of every imaginable nature. > many cases, wrong. And even when it might be appropriate, the cost in > performance may be an issue (not every system is performance critical, > of course). I was specifically talking about processes whose misbehavior can have worse consequences than lack of behavior. Why I have to restate it in every second message? The alternative is that safest is to ignore unexpected signs of insanity and hope that it passes and will not harm and there will be bonus of performance gain. How to get rid of that red herring of performance? Typical software that heavily uses hardware resources are about like that: About 5% of code base is executed about 30% of run-time, half of rest of code base is executed 1.5% of run-time other half is executed too close to 0% of run-time to express. Rest of 68.5% of run-time the software is waiting after I/O from files and from elsewhere. So if to optimize those 5% (for example 15K code lines of 300K SLOC) of code-base to be twice more efficient then it perhaps eats somewhat less battery and runs 15% faster overall. If it is desirable but somehow made harder by some sanity checks in that 15K lines of code then with that can be dealt locally, and not by turning off sanity checks in whole program, especially in those 285K lines of code that are ran rarely. > And in general, sweeping generalisations are wrong most of the time. I was specifically talking about process whose wrong answers can have worse consequences than lack of answers. I was not talking about every kind of software. |
| arief.muh.h@gmail.com: Feb 24 11:32PM -0800 hi guys when i run my program, result stack in 37, i want result of this script as below will be random, how to get the best script #include <iostream> //using namespace std #include <stdio.h> #include <stdlib.h> int main() { int c, a; int n; a = rand()% 50 +1; printf("value a is %d \n",a); for(c =1; c <= a; c++) { n = rand()% 50 + 1; //n = rand(); printf("value : %d \n",n); return n; } printf("value of n : %d \n",n); if (n > 50){ printf(" lowest : %d",n); } else printf("highest : %d",n); return 0; } |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 25 09:26AM +0100 > hi guys > when i run my program, result stack in 37, i want result of this > script as below will be random, how to get the best script [Reformatted with AStyle:] > else printf("highest : %d",n); > return 0; > } If you want different pseudo-random sequences then you have to provide a /seed/ value that's different in each run of the program. For the machinery you're using you pass that seed value to `srand`, but where to get a varying seed? One portable possibility is to use `time`, but note that it doesn't vary fast enough to guarantee different values in close runs of the program. Another portable possibility is to use the modern C++ random generation facilities just for this, `std::random_device`. Declare such an object. It's callable, so you just call it (like a function) to get the random seed value. Note: at least as version 8.2.0 g++ wasn't quite up to date in its implementation; if it doesn't work with g++ you can define `_GLIBCXX_USE_RANDOM_TR1` globally in the build. Of course, using the modern facilities for a random seed, you might almost just as well use them also for the random number generation. It's slightly more complex code, though. Unless you write a reusable wrapper. Cheers!, - Alf |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Feb 25 11:36AM -0500 > else printf("highest : %d",n); > return 0; > } You've already been told that the solution is to call srand() with a suitably chosen value, along with some hints as to how to choose such a value. However, it wasn't explained why that was necessary. Here's the key reason: "If rand is called before any calls to srand have been made, the same sequence shall be generated as when srand is first called with a seed value of 1." (7.22.2.2p2). |
| shizoor <a@b.com>: Feb 25 04:05AM Just testing my newsgroup software by replying to this.. Join the Church of the SubGenius my child. Let "Bob" show you the way. https://www.youtube.com/watch?v=BbHjybg50BU |
| 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