- "Why does most C/C++ developer prefers char *c instead of char* c? Pin" - 12 Updates
- High horse - 6 Updates
- Blinking message in Dev C++ - 6 Updates
- Here is my new website - 1 Update
| "Öö Tiib" <ootiib@hot.ee>: Jun 01 04:35PM -0700 > #define MAX(x, y) ... > A[i][j][k]; // inside a 3-nested loop indexed by i,j,k > Or the evaliandexpr() routine in my last post. Huh? Why you swap ints? Even MISRA (<- most backward minded crowd), does not allow to type "int" in their code standards. |
| Bart <bc@freeuk.com>: Jun 02 12:47AM +0100 On 01/06/2018 22:38, Ian Collins wrote: >> confidence in that is not quite the 100% it is when being explicit about >> the type. > Why would the type be anything other than the return of evaleqexpr()? The type of what? There could be three different ones. In this function, you want to emphasise that x and y (when both are used) have the same type. You want to do that without having to analyse different parts of function. You might also want to know what that type is without having to hunt for the called functions. If somebody wants to take my function and port it to an unknown language (unknown to us), then they would likely find it easiest working from the code that /I/ write than the C or C++ versions other people are suggesting. > That is terrible practice. You should only introduce variables when and > were you need them. Anything is is chaos. Have you done any real programming where you build an application incrementally, or have to copy and paste from one part to another, or have to comment out code, or delete code that that will be replaced, but you still have the declarations, or... In other words, just normal development. Because it doesn't sound like it! Do you only ever submit complete, debugged working programs to a compiler? Do you only ever declare a variable when all the references to that variable in the code are complete? Would you ever write a skeleton function like this: int fn(int a, int b, int c){ puts("fn not ready"); return 0; } If so, how do you cope with with warnings about a, b and c not being used? -- bartc |
| Ian Collins <ian-news@hotmail.com>: Jun 02 12:06PM +1200 On 02/06/18 11:47, Bart wrote: > used) have the same type. You want to do that without having to analyse > different parts of function. You might also want to know what that type > is without having to hunt for the called functions. I would have thought the emphasis is on the algorithm, not the types. > If somebody wants to take my function and port it to an unknown language > (unknown to us), then they would likely find it easiest working from the > code that /I/ write than the C or C++ versions other people are suggesting. How many people do that? That someone might want to port to language B a pretty daft justification for avoiding the idioms of language A. > incrementally, or have to copy and paste from one part to another, or > have to comment out code, or delete code that that will be replaced, but > you still have the declarations, or... Nope. My code is written incrementally, one passing test at a time. There is no code that isn't introduced to make a test pass. > In other words, just normal development. Because it doesn't sound like it! Normal from days gone by, maybe. > Do you only ever submit complete, debugged working programs to a > compiler? No, because I have to verify that it won't pass a new test before the code to pass the test is written. > Do you only ever declare a variable when all the references to > that variable in the code are complete? A variable is introduced once it can be correctly initialised. > return 0; > } > If so, how do you cope with with warnings about a, b and c not being used? By not naming them. -- Ian |
| Ian Collins <ian-news@hotmail.com>: Jun 02 12:14PM +1200 On 02/06/18 11:47, Bart wrote: > incrementally, or have to copy and paste from one part to another, or > have to comment out code, or delete code that that will be replaced, but > you still have the declarations, or... What you describe there is analogous to a surgeon leaving dead tissue and instruments in a patient after surgery! -- Ian. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jun 02 07:53AM On Fri, 2018-06-01, Scott Lurndal wrote: >>That is supposing code of seventies. Then it was that function calls >>were too expensive so program consisted of only few long functions. > What gives you that impression? Whatever caused it, I had that impression until 1995 or so. And reading others' code, it seems many still do: it's not uncommon to find long functions which could easily could have been improved by having helper functions factored out. But perhaps the latter has more to do with people seeing functions as necessarily big, important and visible in external interfaces. > in the 70's. Or in the 60's. Just a simple branch, generally saving > 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. [snip] /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| David Brown <david.brown@hesbynett.no>: Jun 02 12:41PM +0200 >> "lexm"), > 'lexm' is a local function in this module, and it is clearly a > function because it is followed by (). I don't see the problem. It is clearly a function, yes. I'd be suspicious of such a short-named function - even when it is local to a module (I hope you've remembered "static" or an anonymous namespace). If it is local, commonly used, and the name is obvious within the context of the program, then "lexm" might be fine. > project will have underscores, some sets will have a common prefix, > others a common suffix, and some both (see below). But all names in > the same related set will use the same scheme Using different styles for different purposes is fine, and can help improve legibility. Some people prefer underscores, some prefer camel-case - I'm not going to argue for one or the other. But jammed-up identifiers without a break between the words, are always hard to read. That makes them bad style in almost all circumstances. >> before its initialisation. > I have a problem with your version because the important > initialisation of x is separated from the rest of the code. No, it is not. The initialisation is right there with the rest of the code. In your version, there is no initialisation of x - but its definition is separated. > I like to separate code that just provides information, like a > declaration, from code that actualy does something, like the > assigment. Then you picked the wrong language. In C++, definitions (rather than just declarations) /do/ something (even if, for simple types and a good compiler, that "logical something" may involve no object code). And "int64_t x" inside a function is a definition, not just a declaration. > The algorithm here is to assign the first lhs term to x > then loop for any rhs terms. Your version breaks that up. No, it does not. It has the same actions in the same place. The only difference is that "x" is not declared earlier. > It also involves the type of x (and y; see below) more than I would > like. If one day I decide to change their type, then I would need to > change the block of code that expresses the algorithm. No, you would not. You would only need to change it in one place at the start of the block. And it would make no sense to change the type of "x" unless you were also changing the type of evaleqexpr() - you need to make multiple changes anyway. And if you had several variables to deal with here, you would use a "using" (modern C++) or "typedef" (older C++ and C) to name the type, thus you would only have to change it at one point. (Your evaleqexpr() function would use that same typedef'ed type.) You can also use modern C++ style and use "auto" instead of the type for x. > all named 'evalOPexpr', all declaring 'int64 x,y'. Most will use y, > in one or two it was dispensed with (such as the one I chose to > post), but I yet make use of it in the future. If you define your variables when you need them, you don't need to pre-define extra variables just to make copy-and-paste easier. > These functions evaluate the operands of a binary operator and it is > natural to call those operands x and y. I am quite happy with the operands being called "x" and "y" - that seems a good choice of names here. |
| David Brown <david.brown@hesbynett.no>: Jun 02 12:54PM +0200 On 01/06/18 22:27, Bart wrote: >> With clang and g++, this will generate an unused variable warning with >> all but the most basic compilers options. > That's fine when you've finished your program and wrapped it up. Absolutely not. Enable warnings from the moment you start with your first empty C file and its first build. You want to deal with problems (or potential problems) as quickly as possible, not let them build up until you think you've finished the code and then discover all the issues! > of variables but haven't got round to making use of them, or haven't > decided which are staying. Or some of them are there for possible > debugging. If you don't define them until you need them, this is not a problem. If they are useful for debugging, then there will be no compiler warnings about them - if the compiler is warning about them (that they are unused, or assigned to but unused), then they are useless for debugging. |
| David Brown <david.brown@hesbynett.no>: Jun 02 01:04PM +0200 On 02/06/18 01:47, Bart wrote: > return 0; > } > If so, how do you cope with with warnings about a, b and c not being used? I want the warnings. Then I am not going to forget that the function is missing! Early in development, I have warnings as warnings, and accept that there are while coding. Parts of the development may even be done as first adding the stubs that lead to warnings, and then going through fixing the warnings. (A good IDE makes this convenient and practical.) Then I use "-Werror" to turn all warnings into errors. |
| David Brown <david.brown@hesbynett.no>: Jun 02 01:10PM +0200 On 02/06/18 02:06, Ian Collins wrote: >> If so, how do you cope with with warnings about a, b and c not being >> used? > By not naming them. I hate when people declare functions without naming the parameters. If you don't have a use for something, then it should not be there. And if you have a use for it, it needs a name. (A rare exception being "operator++(int)".) If I have reason to leave a parameter unused, and don't want a warning (for example, to give consistent interfaces to a number of functions), then I use "__attribute__((unused))" or cast the variable to void. |
| Bart <bc@freeuk.com>: Jun 02 12:12PM +0100 On 02/06/2018 01:06, Ian Collins wrote: >> you still have the declarations, or... > Nope. My code is written incrementally, one passing test at a time. > There is no code that isn't introduced to make a test pass. Then I envy you your clear and simple specifications! My current project is a new compiler X for a static language M' written in static language M. Parts of X will be taken from an old compiler for M written in dynamic language Q, and parts from a more recent compile written in M but which compiles C source code. So there are lots of imported bits which can't immediately be used because they need dynamic->static conversion, or which have been converted but are intended to compile C (with a different set of AST nodes and different intermediate language). Or they can't be used because the new compiler works differently from the other two (a project at a time rather than a module at a time). It's not practical to convert everything all at once. There will be loads of stuff commented out or half converted or which I know will be wrong, but it just needs to be get past the compiler to do a test that might be unrelated to that half-done function. So yes it's chaotic. But so are lots of things (like writing a screenplay adapted from something else; there will be lots of rewriting and refining and even starting again). Your strategy sounds very worthy but is the equivalent of calling in a team of management consultants and project managers to help me build a garden fence. >> compiler? > No, because I have to verify that it won't pass a new test before the > code to pass the test is written. I couldn't program like that. As for testing, my project X from above is now being tried on a sizeable input Y'. Y' is a 20Kloc interpreter. It partly 'works' in that Y' can be converted from source code to a binary executable (an achievement given the things that can and have gone wrong), and the next step is running Y' on its own input Z. Testing then is seeing whether X compiling Y' interpreting Z gives the same results as original working Y interpreting Z. So if something doesn't work, there is source code for three separate projects to consider. When it gets more advanced, Z can be the compiler that compiles X, then it gets more interesting as I can then test second and third generation X' and X''. After that X's source code will be tweaked from M to M' and X will compile itself directly. Oh, and X is intended to compile code at up to 500Kloc per second. (Although I'm some way short of that at the minute; X needs twice as many passes as my C compiler. Still, X should be able to compile itself at the rate of several generations per second, even UNOPTIMISED. How many will C++ do?). Now, this is chaotic but it's fun. With your formal, sterile approach to coding, I'd be looking for a 6' length of rope inside a week. -- bartc |
| Ian Collins <ian-news@hotmail.com>: Jun 03 08:17AM +1200 On 02/06/18 23:10, David Brown wrote: > If I have reason to leave a parameter unused, and don't want a warning > (for example, to give consistent interfaces to a number of functions), > then I use "__attribute__((unused))" or cast the variable to void. Which is all well and good in C, C++ has unnamed parameters for that case. -- Ian. |
| Bart <bc@freeuk.com>: Jun 02 09:26PM +0100 On 02/06/2018 21:17, Ian Collins wrote: >> (for example, to give consistent interfaces to a number of functions), >> then I use "__attribute__((unused))" or cast the variable to void. > Which is all well and good in C, C++ has unnamed parameters for that case. What happens when you eventually decide to use that parameter, but forget to name it and it happens to shadow a more global variable with the same name? Let me guess: unit tests will pick that up. -- bartc |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 02 03:17AM +0100 I see Ian Collins is on his TDD high horse again. Fecking clueless. /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." |
| Ian Collins <ian-news@hotmail.com>: Jun 02 03:00PM +1200 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. -- Ian |
| Paavo Helde <myfirstname@osa.pri.ee>: Jun 02 09:28AM +0300 On 2.06.2018 5:17, Mr Flibble wrote: > I see Ian Collins is on his TDD high horse again. Fecking clueless. TDD is fine as long as it stays a tool and does not become a goal in itself. One still has to know what the program must do and how to write the code to accomplish that. TDD does not mean randomly alternating your code to make the next test pass (for starters, that would require 100% perfect tests which never happens). And if any TDD method appears counter-productive or not effective in some situation, it can be skipped or replaced (because it is just a tool). The same can be said for any tool or methodology of course, but it looks like TDD is especially prone to misunderstandings and misuse for some reason (it cannot beat "agile" of course ;-) |
| Ian Collins <ian-news@hotmail.com>: Jun 02 06:46PM +1200 On 02/06/18 18:28, Paavo Helde wrote: > The same can be said for any tool or methodology of course, but it looks > like TDD is especially prone to misunderstandings and misuse for some > reason (it cannot beat "agile" of course ;-) Very true! -- Ian. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 02 08:53PM +0100 On 02/06/2018 04:00, Ian Collins 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. Designing software by incrementally fixing failing tests is NOT designing software. /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." |
| Ian Collins <ian-news@hotmail.com>: Jun 03 08:22AM +1200 On 03/06/18 07:53, Mr Flibble wrote: >> Feel free to write code that you don't know works. > Designing software by incrementally fixing failing tests is NOT designing > software. True. https://www.thinksys.com/development/tdd-myths-misconceptions/ Point 3. -- Ian. |
| woodbrian77@gmail.com: Jun 02 10:46AM -0700 On Friday, June 1, 2018 at 2:19:56 AM UTC-5, David Brown wrote: > purpose behind your work - that is a personal thing. If your site is > worth using professionally, then it is worth using professionally > regardless of the user's beliefs. I'm a bopper - Biblically oriented programmer. When I say that I'd like to work with an Israeli company, they are more likely to be boppers. You don't have to be a bopper in order to get my help, but ideally I'd like to work with other boppers. Brian https://github.com/Ebenezer-group/onwards |
| David Brown <david.brown@hesbynett.no>: Jun 02 08:11PM +0200 > are more likely to be boppers. You don't have to be a > bopper in order to get my help, but ideally I'd like to > work with other boppers. When you say things like that, the message you are giving is that your are unable to separate your work from your private life, and you are unable to work with people who /can/ separate them - i.e., the great majority of people. You are chasing away everyone who is not a close follower of your particular cult - including the vast majority of Christians. If that's your choice, fine - but be aware of the consequences. |
| woodbrian77@gmail.com: Jun 02 11:20AM -0700 On Saturday, June 2, 2018 at 1:11:51 PM UTC-5, David Brown wrote: > majority of people. You are chasing away everyone who is not a close > follower of your particular cult - including the vast majority of > Christians. If that's your choice, fine - but be aware of the consequences. Not everyone is as bigoted as you are. They can "taste and see" if they want to. |
| David Brown <david.brown@hesbynett.no>: Jun 02 09:04PM +0200 >> Christians. If that's your choice, fine - but be aware of the consequences. > Not everyone is as bigoted as you are. They can > "taste and see" if they want to. I don't care what religion people want to follow, or what nationality they are - if I am dealing with a person or company professionally, I only care about there work professionally. I only ask one thing - that that person or company does not judge people on anything but /relevant/ issues. You want to judge people based on their religion, their nationality, their sexuality. You want to do so in your professional life. /That/ is bigotry. (Note that this is different from ethics or human rights. It's fine to say you don't want to work with companies that make bombs, or for your software to be used to run a drug sales operation.) If I have prejudices, it is only against bigots. Anyway, enough of this - it is off-topic. You can accept the fact that mixing religion with your professional work will limit your company's potential sales and partners, or you can ignore it. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 02 03:50PM -0400 > On Saturday, June 2, 2018 at 1:11:51 PM UTC-5, David Brown wrote: >> On 02/06/18 19:46, woodbrian77@gmail.com wrote: ... >> Christians. If that's your choice, fine - but be aware of the consequences. > Not everyone is as bigoted as you are. They can > "taste and see" if they want to. Being able to work with people who have different religious beliefs than your own counts as a sign of bigotry? I don't see how that follows. As far as I can see, "ideally I'd like to work with other boppers" is a stronger indication of bigotry than anything David said. It's certainly not a strong indication of bigotry - "I don't want to have anything to do with anyone who isn't biblically oriented" would be a much stronger indication. However, it's certainly not the statement of someone who's lack of bigotry would allow him to deal with people of conflicting religous beliefs as easily as with people who share his religious beliefs, in any context where those religious beliefs are irrelevant. |
| woodbrian77@gmail.com: Jun 02 12:57PM -0700 On Saturday, June 2, 2018 at 2:04:20 PM UTC-5, David Brown wrote: > issues. > You want to judge people based on their religion, their nationality, > their sexuality. You seem to have misunderstood me. When I say: "You don't have to be a bopper in order to get my help, but ideally I'd like to work with other boppers." I'm saying that you can be whatever and I'll try working with you. If I get more than one interested party, I'll take their beliefs into account in terms of my decision. Does G-d love atheists, Budhists, Muslims, etc.? Yes, and so do I. Like Ben Shapiro - https://www.dailywire.com/podcasts/31337/ep-551-bee-or-not-bee , I'm partial to western civilization. Brian |
| Sky89 <Sky89@sky68.com>: Jun 02 03:50PM -0400 Hello, Read this: I have changed my website, here is my new website that contains all my Delphi and FreePascal and C++ projects: https://sites.google.com/site/scalable68/ You are welcome. Thank you, Amine Moulay Ramdane. |
| 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