- High horse - 17 Updates
- "Why does most C/C++ developer prefers char *c instead of char* c? Pin" - 4 Updates
- Blinking message in Dev C++ - 2 Updates
- OOP is the new GOTO - 1 Update
- High horse - 1 Update
| woodbrian77@gmail.com: Jun 03 05:04PM -0700 On Sunday, June 3, 2018 at 3:26:57 PM UTC-5, Daniel wrote: > group/onwards > https://github.com/Ebenezer-group/onwards/issues > Unless there's another explanation ... Joseph had dreams about the future and shared his dreams with his brothers. They reacted badly and thought about killing him. They wound up selling him as a slave. They had a baseless hatred against their brother. When I started working on my software in 1999, it wasn't obvious that ++C would remain one of best languages for software development. It also wasn't obvious that an on-line approach (cloud computing) would become so important. So I say "thanks G-d" for helping me get those and other things right. https://www.biblestudytools.com/john/passage/?q=john+15:18-25 Brian Ebenezer Enterprises http://webEbenezer.net |
| Daniel <danielaparker@gmail.com>: Jun 03 06:11PM -0700 On Sunday, June 3, 2018 at 6:25:24 PM UTC-4, Ian Collins wrote: > Would you consider writing a detailed design to bridge the gap between > what the user asks for and the code as sampling the specification? Probably not anymore :-) Because I don't want to, and don't have to. > If where is the conceit? If no, how does a requirement written in prose > differ from one written in code? I work mostly on financial trading and risk projects. The specification such as it is consists of a wide variety of business documents, technical notes that can be expected to contain errors, dozens of matlab scipts, spreadsheets and VBA code, interview notes, business processes (a guy runs over to a Bloomberg terminal and downloads some data daily) and much else. I regard this collective body of artifacts as the "specification", to be reflected upon and used as the basis for a computer application. In general I would say that a requirement written in prose is easier to read and think about than one written in code. It's nice to have specifications written in a formal notation such as BNF, but even that requires some supplementary prose. > these ended up being a subset of the actual test cases for the code. So > the tests were more detailed than the formal detailed design; at least > until they were fed back into the design. If you're generating test cases from the clauses in formal notation, I don't see how that's test first. Best regards, Daniel |
| seeplus <boardmounrt@gmail.com>: Jun 03 06:58PM -0700 > Brian > Ebenezer Enterprises > http://webEbenezer.net So you have a robot snipping away the cancer around your prostate gland.... Would you prefer: - The programmer thought long and hard and decided not to use "auto" in this case OR: - Just prayed to a mythical faery that some divine inspired snipping "for loop" should work .... somehow? |
| Ian Collins <ian-news@hotmail.com>: Jun 04 02:14PM +1200 On 04/06/18 13:11, Daniel wrote: >> Would you consider writing a detailed design to bridge the gap between >> what the user asks for and the code as sampling the specification? > Probably not anymore :-) Because I don't want to, and don't have to. Me too, thanks to tests :) > and think about than one written in code. It's nice to have specifications > written in a formal notation such as BNF, but even that requires some > supplementary prose. It is also something a typical customer, or in our case, product specialists and UX team lack the skills to produce. Even when written in formal notation, you still can't guarantee a written specification truly reflects the code. I also believe most programmers fall asleep way sooner reading requirements that reading code.. >> the tests were more detailed than the formal detailed design; at least >> until they were fed back into the design. > If you're generating test cases from the clauses in formal notation, I don't see how that's test first. Well the test cases were empty prototypes that did come before the code... This was an investigation into generating documentation with validated links between clauses in the various layers. The test case was just the final step to verify that each clause had a test. -- Ian. |
| Juha Nieminen <nospam@thanks.invalid>: Jun 04 07:12AM > On 02/06/18 14:17, Mr Flibble wrote: >> I see Ian Collins is on his TDD high horse again. Fecking clueless. > Feel free to write code that you don't know works. I think that TDD is poorly suited for the kind of programming I do, which is graphically-heavy video games. How exactly do you write a unit test for "this sprite should appear here, and its fragment shader should make it look like this"? There are certain things that could ostensibly be automatically tested, but the machinery required to do that feels excessively laborious and complicated to implement. Such as something like "when the projectile shot by the player hits this enemy sprite, it should launch this particle effect and run this fragment shader". I suppose theoretically that could be automatically tested, but the code required for it would be quite complicated. Another thing I have noticed about TDD is that it's difficult to test the behavior of private member functions (without exposing them to outside code, breaking object-oriented modularity design.) Essentially you would need to add testing code to the class itself, which I think isn't something TDD is supposed to do. |
| David Brown <david.brown@hesbynett.no>: Jun 04 09:12AM +0200 > with his brothers. They reacted badly and thought about > killing him. They wound up selling him as a slave. They > had a baseless hatred against their brother. Are you trying to say you think people hate you? They don't - not as far as I can see. I dislike some of your opinions (like your homophobia), and I advise against mixing personal philosophies and religion with professional work, but I certainly don't /hate/ you. I would not be trying to give you advice if I did! Or are you saying people are afraid of your dreams? If so, that is utter nonsense. You can see what people think of your online code generator plans - the reaction is /not/ one of fear. Or are you simply showing your megalomania again? You have previously claimed to be a second Noah and Jesus's appointed vice-president on earth with special responsibilities for C++. So maybe being merely a reincarnated Joseph is progress. "But the fact that some geniuses were laughed at does not imply that all who are laughed at are geniuses. They laughed at Columbus, they laughed at Fulton, they laughed at the Wright Brothers. But they also laughed at Bozo the Clown." Carl Sagan > When I started working on my software in 1999, it wasn't > obvious that ++C would remain one of best languages for > software development. It was a solid bet at the time that C++ would remain popular for a good while to come. Not a sure bet, but a reasonable one. And it was a self-fulfilling prophesy, because every second programmer the world over made exactly the same bet. > It also wasn't obvious that an > on-line approach (cloud computing) would become so > important. Betting on online code generation in 1999 would certainly have been a bold move. Betting on online "something" or "the internet" was not unreasonable. But while cloud computing is important, online code generation is almost entirely irrelevant. > So I say "thanks G-d" for helping me get > those and other things right. Thank whoever you want for your successes (but don't forget to blame them equally for your failures or disappointments). Just don't expect others to hold the same views. And if you want to get any customers, you might want to tell them that it was in fact /you/ who had the ideas and wrote the code. No potential customer is going to want code written by your god - they will only come to you for code /you/ wrote. |
| Ian Collins <ian-news@hotmail.com>: Jun 04 07:49PM +1200 On 04/06/18 19:12, Juha Nieminen wrote: >> Feel free to write code that you don't know works. > I think that TDD is poorly suited for the kind of programming I do, > which is graphically-heavy video games. I have never worked in that field, so I can't really comment. > How exactly do you write a unit test for "this sprite should appear > here, and its fragment shader should make it look like this"? Our UI teams do unit test similar component functionality, but again that is not my area. > effect and run this fragment shader". I suppose theoretically that could > be automatically tested, but the code required for it would be quite > complicated. Some of our test support infrastructure is very complex, but it only had to be written once and it is very widely used, so the investment was worth while. If the code doesn't have a long lifetime, it might not be worth the cost. We have a considerable amount of legacy (early 2000s) code which was never designed for test, if the code was, testing would be much easier. > outside code, breaking object-oriented modularity design.) Essentially > you would need to add testing code to the class itself, which I think > isn't something TDD is supposed to do. If the functionality can't be tested through the public interface, the usual approach (which often occurs when working with existing code) is to extract the private member function functionality into a class and test that. This does, surprisingly often, produce a useful reusable component. -- Ian. |
| leigh.v.johnston@googlemail.com: Jun 04 04:22AM -0700 On Monday, June 4, 2018 at 8:49:54 AM UTC+1, Ian Collins wrote: > to extract the private member function functionality into a class and > test that. This does, surprisingly often, produce a useful reusable > component. Reducing encapsulation in the process. I have said before that TDD is the enemy of encapsulation and therefore by extension an enemy of good design as encapsulation is an important design principle. /Leigh |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 04 11:54AM -0400 On 06/03/2018 09:26 AM, Daniel wrote: > nonsensical to talk about "100" percent coverage unless you're talking > about software verified through mathematical proof, and if you're > talking about that, you're not talking about C++. I worked for awhile under a requirement that our unit tests provide 100% coverage of our code - but I strongly suspect that what we were talking about was involved different numbers in the numerator and denominator of the fraction that is being converted to 100% than what you're apparently thinking of. In our case, the denominator was the number of full-expressions in the code. To this number was added any sub-expressions that were not guaranteed to be executed when the containing expression was executed (such as b and c in a?b:c, or b in a&&b). The numerator was the number of such expressions which should be executed by the unit test if the code was correct (this is obviously not black-box testing, which we also did). This was combined with other requirements, such as the requirement that if a branch in the code depends upon the value of an integer expression, there must be at least two cases where that branch is tested; one where the expression should have the minimum possible value that should cause the high branch to be chosen, and one where it should have the maximum possible value that should cause the low branch to be chosen. This principle was extended in the obvious fashion for switch() statements. For purposes of this requirement, empty branches (such as if(a) b();) are treated as if there were an expression-statement on the missing branch (if(a) b(); else dummy();). Furthermore, there was a requirement that if two test cases caused different expressions to be executed, the test cases must be set up so that whether or not those expressions were executed causes a detectable difference in the test results. Was creating such thorough tests was "the best use of [my] time to keep [my] software free of defects"? Well, our defect rate rose significantly when management stopped requiring that we do such detailed testing, and started pressuring us to make deliveries too quickly to allow such testing to be done, so I suspect that the answer is "yes". > approached through unit tests, I'm thinking particularly of > simulation, where we need to run code for hours and calculate the > statistical properties of outcomes. I would be very surprised to learn that the "T" in TDD referred only to unit tests. I would assume that if a requirement involved the interaction of a program with the external environment (for instance, there is a requirement that, under certain circumstances, a missile must be fired), the corresponding test would include evaluating the impact on the external environment (i.e. confirming that the missile (or at least, a dummy missile) was actually fired). |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 04 12:03PM -0400 On 06/04/2018 03:12 AM, Juha Nieminen wrote: >> On 02/06/18 14:17, Mr Flibble wrote: >>> I see Ian Collins is on his TDD high horse again. Fecking clueless. >> Feel free to write code that you don't know works. ... > Another thing I have noticed about TDD is that it's difficult to test > the behavior of private member functions (without exposing them to > outside code, breaking object-oriented modularity design. You test the private member function by calling whichever public functions call it, directly or indirectly. If execution of the private member function is needed to achieve some required result, it's always possible to perform such a test, by checking to see whether that required result occurred. If execution of a private member function has no testable consequences, then that private member function isn't actually needed. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 04 05:16PM +0100 On 04/06/2018 17:03, James Kuyper wrote: > ... If execution of a private member function has > no testable consequences, then that private member function isn't > actually needed. False. A private member function is allowed to call other private member functions without the need to maintain a class invariant; these other private member functions may indeed have no testable consequences unless taken together with the other private member functions that call them. TDD is the enemy of encapsulation ergo TDD is the enemy of good (object oriented) software design. /Flibble -- "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." |
| legalize+jeeves@mail.xmission.com (Richard): Jun 04 05:01PM [Please do not mail me a copy of your followup] Ian Collins <ian-news@hotmail.com> spake the secret code >On 02/06/18 14:17, Mr Flibble wrote: >> I see Ian Collins is on his TDD high horse again. Fecking clueless. >Feel free to write code that you don't know works. From his high horse it's much easier to hit the ball with his polo mallet :-). -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| legalize+jeeves@mail.xmission.com (Richard): Jun 04 05:09PM [Please do not mail me a copy of your followup] Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code >> test passes. >That's certainly the impression I got too, from reading Beck's book >once. His argument seemed weak to me. In a language like C++ where we have to contend with build systems and compilers and linkers and their funny ways, getting code to a syntactically correct state can be non-trivial at times. Going in small steps, e.g. from compilation error to failing test to passing test is one way to avoid making stupid mistakes. In my experience with doing TDD in C++, the "satisfy the compiler" or "satisfy the build system" steps generally only happen at the start of a new library or executable. In those situations, making sure my build system is setup correctly is a useful small step. When working on adding new features to existing code that was written with TDD, it's not usually necessary to proceed in those smaller steps. Experts take larger steps than novices. I've developed code without TDD for decades before I adopted TDD. I certainly know how to do it both ways and for an existing code base, it may simply be less work to do things the "old way" than adopt TDD because there might be too much decoupling needed to do strict TDD. However, having done it both ways for a number of years, I have found that I am more productive with TDD than without it. I find my bugs faster and spend less time doing long tedious integration debugging sessions. (I've been in a tedious integration debugging session for about two weeks right now at work.) -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 04 01:34PM -0400 On 06/04/2018 12:16 PM, Mr Flibble wrote: ... > functions without the need to maintain a class invariant; these other > private member functions may indeed have no testable consequences unless > taken together with the other private member fun So perform a test that takes them together with the other private member functions (which must also, of course, be invoked indirectly). What's the problem? The important thing isn't how the code is subdivided into individual functions, whether public or private. The important thing is what the code actually does. If you can stub out a private member function without producing any testable failure to meet requirements, you don't need that function to meet requirements - it's inherently and by definition that simple. For example, consider a private function which is intended to meet the requirement that it cause a visit to the user by the Invisible Pink Unicorn <https://en.wikipedia.org/wiki/Invisible_Pink_Unicorn>. By Her very nature, it's inherently impossible to prove whether or not She has visited, so there would be no testable consequences of stubbing out that function. But for precisely the same reason, there's no problem with delivering that code with the function still stubbed out. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 04 06:54PM +0100 On 04/06/2018 18:34, James Kuyper wrote: > function without producing any testable failure to meet requirements, > you don't need that function to meet requirements - it's inherently and > by definition that simple. In a word: bullshit. Private member functions don't have to be testable in isolation BY DESIGN but that doesn't mean they can removed. If you don't get this then you are beyond help: your designs must be a mess. > visited, so there would be no testable consequences of stubbing out that > function. But for precisely the same reason, there's no problem with > delivering that code with the function still stubbed out. I've seen a lot of bad analogies in my day but that just takes the biscuit. You really are clueless mate. I suggest you do a bit of reading starting with a read about class invariants and encapsulation. /Flibble -- "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." |
| cross@spitfire.i.gajendra.net (Dan Cross): Jun 04 06:01PM In article <fnj2arFn9lqU1@mid.individual.net>, >> Works in what sense? >Works as in does what the detailed design (the tests) says it is >supposed to do. "Test as design" is an attempt to respond to the reality that a detailed design document (in the waterfall sense) is destined to become hopelessly out of date in very short order. But it does not follow that this is the only way to document a "design", nor that it is even a good way to do so (let alone sufficient for long-term maintenance). Tests can certainly perform some documentary function, but they fall far short of the sort of design that may be required for non-trivial software. The example was brought up of implementing IETF standards; in that case, an RFC is sort of like a design document for a protocol (yes, there are RFCs for other sorts of things, but let's keep it simple). I hope we could all agree that if a protocol were described by a series of tests, that would be a poor way to communicate a description of the protocol sufficient for an implementer; I would argue it would be so opaque as to be insufficient. >> people that talk about "100 percent" test coverage? >No, in software, there is always the unexpected. But I do strive to >minimise the unexpected through test coverage. Test coverage is neither necessary nor sufficient for minimizing the unexpected. Unit tests are useful as an easy to use and easy to understand communication medium for verifying that software behaves in an expected way in the context of a highly controlled testing environment, but of course there are other ways to do that. However, often those ways aren't easy to use without special training; testing provides a nice balance as a platform for shaking a lot of bugs out of the tree. This is presumably why it is so popular. However, it is manifestly insufficient: suppose I have a bit of code that is succeptible to perturbations of various kinds in the execution environment: for example, it may be subject to tight timing guarantees. How does one probe that in the context of a unit test? Or perhaps I need some guarantee of time complexity for an algorithm as applied to some user-provided data. Unit testing is awkward at best for this purpose. >initially, but the time saved in chasing down bugs, retesting after >changes or stepping through code in a debugger pays off pretty quickly. >Tests are an investment in the future of the code. This conflates the utility of a robust body of unit tests with the practice of TDD. The former is undeniably useful; but the latter is only useful as a means to the former and it is trivially not the only such means. >> and if you're talking about that, you're not talking about C++. >I don't think anyone claims otherwise. See the last point in the link I >posted. Proponents of TDD in the Martin, Beck, Jeffries sense really do try and push it too far. I wrote about this some time ago: http://pub.gajendra.net/2012/09/stone_age See, for example, Martin's comments here: https://sites.google.com/site/unclebobconsultingllc/home/articles/echoes-from-the-stone-age (The first comment on his page is pretty spot-on.) See also this post, and look for Martin's comment: http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html There, Martin tries to make a vague analogy connecting Ron Jeffries's failure to produce a working sudoku solver to kind of martial arts mysticism, wherein Jeffries is a venerable master engaging in a mysterious kind of exercise that's so abstruse as to be essentially unknowable to all but the most senior of the initiated. I call shenanigans: Ron Jeffries simply didn't know what he was doing and while yes, it took some courage to fail publicly, the inescapable conclusion is that TDD is insufficient as a design paradigm. Peter Seibel's blog post is required reading on this debacle: https://gigamonkeys.wordpress.com/2009/10/05/coders-unit-testing/ >> statistical properties of outcomes. >That's correct, there should always be multiple levels of testing, again > I don't think anyone claims otherwise. They most certainly do; repeatedly and in public. It might be that they do not believe it themselves, and are only saying so because they are (most commonly) consultants and authors who are trying to sell engagements and books. But there's a certain kind of cultish devotion that arises from this that's unsettling: it's the sort of fervent devotion of the converted, who claim that, "if you just genuflected THIS way..." then all would be well. The bottom line: unit testing seems to sit at a local maxima on the cost/benefit curve, but there are many ways to get similar quality results. However, unit testing is insufficient to ensure that software is correct and responsive in all respects and TDD, in particular, seems like something of an oversold fad. - Dan C. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 04 02:11PM -0400 On 06/04/2018 01:54 PM, Mr Flibble wrote: > On 04/06/2018 18:34, James Kuyper wrote: ... > In a word: bullshit. Private member functions don't have to be testable in > isolation BY DESIGN but that doesn't mean they can removed. If you don't > get this then you are beyond help: your designs must be a mess. So, don't test them in isolation. Just because they can only be tested in conjunction with other functions doesn't mean they can't be tested. > I've seen a lot of bad analogies in my day but that just takes the > biscuit. You really are clueless mate. I suggest you do a bit of reading > starting with a read about class invariants and encapsulation. I'll have a better idea of what you mean by that claim with a specific example. Please give me the simplest example you can create of a requirement, and a complete program meeting that requirement, which makes use of a private member function whose behavior is necessary to meet requirement, where the entire program's ability to meet that requirement is untestable. |
| scott@slp53.sl.home (Scott Lurndal): Jun 04 02:51PM >> the return address in the first word of the target function (e.g. PDP-8) >> or on a stack (Burroughs/IBM mainframes). >The branch instruction is a small part of the cost. Aside from any cache related costs (not a problem in the 70's), what additional costs are there in your concept of 70's functions? |
| legalize+jeeves@mail.xmission.com (Richard): Jun 04 04:57PM [Please do not mail me a copy of your followup] bart4858@gmail.com spake the secret code > T z; >Then that relationship is lost, and it will need more maintenance to >ensure they stay the same type. This is really just a missing abstraction. If you want a 3D point, make a type for it. It's zero-overhead in C++ and allows you to express the idea directly in code. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Bart <bc@freeuk.com>: Jun 04 06:05PM +0100 On 04/06/2018 17:57, Richard wrote: >> ensure they stay the same type. > This is really just a missing abstraction. If you want a 3D point, > make a type for it. The 3 values might form a vector with those three components, but usually they won't or you have other reasons for independent access to the variables. But even suppose you did encapsulate them into a type; the problem doesn't go away: do you declare them inside that type with one T and 3 names, or three Ts? -- bartc |
| legalize+jeeves@mail.xmission.com (Richard): Jun 04 05:12PM [Please do not mail me a copy of your followup] Bart <bc@freeuk.com> spake the secret code >But even suppose you did encapsulate them into a type; the problem >doesn't go away: do you declare them inside that type with one T and 3 >names, or three Ts? It's irrelevant at that point because the abstraction makes it clear that they all belong together. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Juha Nieminen <nospam@thanks.invalid>: Jun 04 07:01AM > for(long l1=0; l1<300000000; l1++); Never, ever use a busyloop for anything. You have zero control over how long it will actually take (it could very well take exactly 0 seconds because the compiler could just see that the loop isn't doing anything and optimize it away), and even when it's not optimized away, you will be using the CPU core at 100% for doing absolutely nothing. Busyloops were common in 8-bit consoles and home computers, and extremely early PC's (often because there was no alternative), but have been a bad idea since forever. |
| legalize+jeeves@mail.xmission.com (Richard): Jun 04 05:00PM [Please do not mail me a copy of your followup] bintom <binoythomas1108@gmail.com> spake the secret code >I noticed that there are no library functions in Dev C++ to display a >blinking message. So I wrote this function, which I hope does the job >for any oneout there. It doesn't work on my LA36. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Juha Nieminen <nospam@thanks.invalid>: Jun 04 07:04AM > to make things somewhat clear ;c and make a bit of foam... > i think 'Object Oriented Programming' when you sue it - making > objects passing pointers Object-oriented programming doesn't necessitate passing objects by pointer. |
| Real Troll <real.troll@trolls.com>: Jun 03 07:59PM -0400 On 03/06/2018 21:26, Daniel wrote: > https://gith > Unless there's another explanation ... > Daniel Another explanation is that nobody is using that crap. He's just wasting time doing something that nobody is interested in. It's like people writing compilers for C. Nobody wants their crap. We have VS, Embarcadero, G++ (minGW) so why bother with something that is not likely to be any better. |
| 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