- "Why does most C/C++ developer prefers char *c instead of char* c? Pin" - 4 Updates
- Forget about C++, C is not a low-level language either - 2 Updates
- Blinking message in Dev C++ - 14 Updates
- leakage in recursive algorithm - 3 Updates
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 31 08:19PM +0100 On 30/05/2018 14:35, Scott Lurndal wrote: > #define ASTERISK * > char ASTERISK p > who cares? There is an even simpler (and better) solution: DON'T DECLARE MULTIPLE VARIABLES ON THE SAME LINE. /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." |
| bart4858@gmail.com: May 31 02:30PM -0700 On Thursday, 31 May 2018 20:20:06 UTC+1, Mr Flibble wrote: > There is an even simpler (and better) solution: DON'T DECLARE MULTIPLE > VARIABLES ON THE SAME LINE. That's not a solution, it's a workaround. And comes with a disadvantage; suppose that T includes any pointer, array, or function pointer modifiers, then instead of writing: T x, y, z; which tells you that these variables are likely related, and they have a common type which is automatically kept in sync, you have to write: T x; T y; T z; Then that relationship is lost, and it will need more maintenance to ensure they stay the same type. So declaring several names with the same type spec is useful. The original C syntax however allows you to declare several names together but with *different* types (and they can be wildly different), which is not useful and is bad practice. -- bart |
| David Brown <david.brown@hesbynett.no>: May 31 11:49PM +0200 (Please get a real news client, or fix your line endings if you have to use Google's broken interface. It makes it a pain for others to sort out your messed up line breaks.) >> There is an even simpler (and better) solution: DON'T DECLARE >> MULTIPLE VARIABLES ON THE SAME LINE. > That's not a solution, it's a workaround. It is a solution to the problem "how should I declare several pointer variables in a way that won't be confusing?". > T z; > Then that relationship is lost, and it will need more maintenance to > ensure they stay the same type. That might, occasionally, be a relevant point. I can't speak for Mr. Flibble, of course, but I would be okay with "T x, y, z;" in such simple cases. But I am /not/ okay with "char* c, d;" or "char *c, d;" - it is far too easy to misread these. More commonly, however, you have longer type names (including qualifiers), initialisers, descriptive variable names, comments, etc., which mean putting multiple object definitions on one line becomes a mess. > So declaring several names with the same type spec is useful. /Occasionally/ useful. > The original C syntax however allows you to declare several names > together but with *different* types (and they can be wildly > different), which is not useful and is bad practice. Agreed. And for me, that rule includes cases like the sample one here with a "char" and a "char*". |
| Lynn McGuire <lynnmcguire5@gmail.com>: May 31 05:55PM -0500 On 5/31/2018 2:19 PM, Mr Flibble wrote: > There is an even simpler (and better) solution: DON'T DECLARE MULTIPLE > VARIABLES ON THE SAME LINE. > /Flibble +1,000,000 Lynn |
| scott@slp53.sl.home (Scott Lurndal): May 31 06:00PM >then passes control to the exception handler in the naughty program. >This will take quite a long time. IF you're really concerned about >security your kernel will make sure it's a _loooooong_ time. I don't have a lot of time to respond to this, but if you google search for "timewarp: rethinking timekeeping and performance monitoring mechanisms to mitigate side-channel attacks" There are descriptions of and references to the various side-channel attacks via cache timing et alia in that paper. |
| Vir Campestris <vir.campestris@invalid.invalid>: May 31 11:03PM +0100 On 31/05/2018 19:00, Scott Lurndal wrote: > side-channel attacks" > There are descriptions of and references to the various side-channel > attacks via cache timing et alia in that paper. This paper? <http://www.cs.columbia.edu/~simha/preprint_isca12_tw.pdf> That's a much more complete solution to a much wider range of problems, but one that requires that the CPU is modified. As they say you can't afford to cache flush on every context switch. There's also no way to flush the branch predictor cache (which I'd forgotten about TBH) but for the class of attacks which rely on the pipeline pre-fetching stuff to which the program has no right of access, which causes detectable changes in the cache, clearing the cache ought to destroy all that side channel data. Leaving only the branch predictor (which someone will of course use...) I also feel that killing the process after a few exceptions would be a good thing to do. Though no doubt there will be a way around that too. After an exception for an illegal access the state of the cache (and the branch predictor cache) will be different depending on whether the page accessed did not exist or was blocked, and also depending on the contents of that page. The attacks I have read about rely on detecting the state of the cache after the exception. Flushing the cache after such an exception and before returning control to the user program will destroy that information in the cache. I do not see that such a change would be harmful, and it would block one class of attacks. Andy |
| bintom <binoythomas1108@gmail.com>: May 30 10:50PM -0700 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. void Blink(char *str) { cout << "\n"; while(true) { cout << str; for(long l1=0; l1<300000000; l1++); for(int i=0; i<5; i++) cout << "\b"; for(int i=0; i<5; i++) cout << " "; for(long l1=0; l1<300000000; l1++); for(int i=0; i<5; i++) cout << "\b"; } } int main() { Blink("Message"); } |
| "Öö Tiib" <ootiib@hot.ee>: May 30 11:15PM -0700 On Thursday, 31 May 2018 08:50:59 UTC+3, bintom wrote: > } > int main() > { Blink("Message"); } Seems waste of computing power. There is usually something more sane than busy loop for delaying an action. That Dev C++ is AFAIK MinGW and So you can use Windows functions like Sleep in it. |
| David Brown <david.brown@hesbynett.no>: May 31 09:33AM +0200 On 31/05/18 07:50, bintom wrote: > 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. There are a number of "improvement opportunities" in this code. I don't want to demoralise you by listing everything I can think of, especially as that would also lead to discussions about details or alternative constructions that are probably beyond what you are interested in at the moment. But there is a /big/ mistake here, IMHO - your delay loops. These are bad for a number of reasons: 1. They are totally dependent on the individual computer for their timing. Faster or slower processors will give you shorter or longer delays. 2. They are busy-waiting, blocking a cpu core while waiting. 3. The delays will vary according what else is going on in your machine. 4. If you change the optimisation level, or other compiler details, the loops will change timings - the compiler is also free to see that the loops are pointless and can be removed altogether. So a "count for a bit" delay loop is almost never a good idea. (They do see occasional use in embedded systems, for very specific purposes on specific known chips for short delays. And even then, they are written differently.) Standard C++ libraries do not have a "wait a bit function". But every multi-threaded or multi-processing OS has a "sleep" function of some sort. If you are writing for a specific operating system, find out what kind of "sleep" call it supports, and use it. If you are writing with a cross-platform toolkit (like Qt, wxwidgets, etc.), then use the call from those libraries. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 31 09:53AM +0200 On 31.05.2018 09:33, David Brown wrote: > [snip] > Standard C++ libraries do not have a "wait a bit function". std::this_thread::sleep_for Docs at <url: http://en.cppreference.com/w/cpp/thread/sleep_for> Example usage, sleep_for( 2s ); Cheers!, - Alf |
| David Brown <david.brown@hesbynett.no>: May 31 10:12AM +0200 On 31/05/18 09:53, Alf P. Steinbach wrote: > <url: http://en.cppreference.com/w/cpp/thread/sleep_for> > Example usage, > sleep_for( 2s ); Of course you are right. Depending on the versions of his tools and libraries, he might not have a C++11 threading implementation. But it should be the first thing to try. |
| Manfred <noname@invalid.add>: May 31 03:53PM +0200 On 5/31/2018 7:50 AM, bintom wrote: > } > int main() > { Blink("Message"); } Besides the loop counting problem, the above code doesn't display anything on my terminal, due to the lack of any std::flush usage. Moreover, the amount of '\b' outputs should match the message length. More generally, text decoration is not really part of the language (and I think it shouldn't); C++ inherits the very basic text rendering features of C, which do not include things like blinking. This sort of things falls more properly into the category of either text-based or GUI-based text rendering. If working with gcc (or other compiler that supports the \e escape sequence) and an ECMA-48[*] compliant terminal (thanks to https://stackoverflow.com/questions/26522542/nesting-text-decoration-using-vt100-escape-sequences) the following will do (it is C code, but that's irrelevant here): /* ----------------------------- */ #include <stdio.h> int main() { puts("foo \e[05mbar\e[25m baz\e[m"); } /* ----------------------------- */ Examples of terminals that will show the above properly include xterm and putty, I didn't try any Windows native terminal. Thanks to the OP, that re-awakened my curiosity about text-decorations in terminal output. [*] https://www.ecma-international.org/publications/standards/Ecma-048.htm |
| bintom <binoythomas1108@gmail.com>: May 31 07:03AM -0700 On Thursday, May 31, 2018 at 1:03:21 PM UTC+5:30, David Brown wrote: > > } > > int main() > > { Blink("Message"); } Thanks to the guidance from the group, I found the Sleep() function in windows.h that does what I need. |
| bintom <binoythomas1108@gmail.com>: May 31 07:04AM -0700 On Thursday, May 31, 2018 at 1:23:25 PM UTC+5:30, Alf P. Steinbach wrote: > sleep_for( 2s ); > Cheers!, > - Alf Dev C++, which we use does not support sleep_for() but I found Sleep() from windows.h which does the job. Thanks. |
| David Brown <david.brown@hesbynett.no>: May 31 04:13PM +0200 On 31/05/18 16:04, bintom wrote: >> - Alf > Dev C++, which we use does not support sleep_for() but I found > Sleep() from windows.h which does the job. Thanks. Dev C++ is an IDE, not a compiler - it supports whatever compiler you want, with whatever options you want, whatever libraries you want and whatever standards you want (though it has a preference for gcc compilers, I believe). If you are using an older compiler, or not enabling C++11 (or newer) standards, then you won't have sleep_for(). You might conceivably have tools that support C++11 in general, but not all of the C++11 libraries. Unless you have very good reasons not to (and programmer knowledge and experience might be a good reason), I'd recommend using at least C++11 standard for new code - it is a significant step up in the language. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: May 31 02:43PM On Thu, 2018-05-31, David Brown wrote: ... > Unless you have very good reasons not to (and programmer knowledge and > experience might be a good reason), I'd recommend using at least C++11 > standard for new code - it is a significant step up in the language. I don't think not knowing all of C++11 is a reason to tell the compiler to use C++98. I don't know all of C++98 either ... /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| "Öö Tiib" <ootiib@hot.ee>: May 31 08:34AM -0700 On Thursday, 31 May 2018 17:13:36 UTC+3, David Brown wrote: > want, with whatever options you want, whatever libraries you want and > whatever standards you want (though it has a preference for gcc > compilers, I believe). That is ideal talk about normal IDE. ;) Just like it is tricky to integrate something but Apple-approved-LLVM stuff into X-Code it is tricky to integrate something but that outdated version of MinGW gcc into that Dev C++. > Unless you have very good reasons not to (and programmer knowledge and > experience might be a good reason), I'd recommend using at least C++11 > standard for new code - it is a significant step up in the language. There are number of other 0 price IDEs that are easier to deal with. Eclipse CDT, NetBeans, Qt creator, even free vesions of MS VS are relatively easy to to deal with. But one who has picked Dev C++ or Code::Blocks should first just dump it if they want to use modern compilers IMHO, YMMV. |
| woodbrian77@gmail.com: May 31 11:11AM -0700 On Thursday, May 31, 2018 at 9:43:34 AM UTC-5, Jorgen Grahn wrote: > > standard for new code - it is a significant step up in the language. > I don't think not knowing all of C++11 is a reason to tell the > compiler to use C++98. I don't know all of C++98 either ... Agreed. There's also an increasing amount of software that you won't be to use if you don't take steps toward 2011 ++C. That includes code from an online code generator that has been mentioned here previously. Brian Ebenezer Enterprises - Enjoying programming again. https://github.com/Ebenezer-group/onwards |
| scott@slp53.sl.home (Scott Lurndal): May 31 06:29PM >Agreed. There's also an increasing amount of software >that you won't be to use if you don't take steps toward >2011 ++C. Actually, that precludes the use of such software in many cases where moving to a newer compiler isn't feasible. On-line code generators aren't a viable solution - who wants to be dependent upon a third-party that may disappear tomorrow? |
| David Brown <david.brown@hesbynett.no>: May 31 08:53PM +0200 On 31/05/18 20:29, Scott Lurndal wrote: > where moving to a newer compiler isn't feasible. > On-line code generators aren't a viable solution - who wants to > be dependent upon a third-party that may disappear tomorrow? I have only dealt with one on-line code generator (for making customised SDK's for a family of microcontrollers), and I agree entirely. I'd rather have a large download giving a big, fat tree of all the files for all the devices in the family - so that I can pick the ones I want, when I want, copy them, compare them, archive them. |
| Ralf Goertz <me@myprovider.invalid>: May 31 02:55PM +0200 Hi, I have a problem with a program implementing the backtracking algorithm shown in <https://en.wikipedia.org/wiki/Backtracking>. Everything is fine except for the fact that the program seems to be leaking. I use a variant of the algorithm that finds all solutions (find_all=true). In my case the memory usage still increases considerably although I already found solutions and accordingly recursion_depth stays at or below its maximum value of 65. According to my understanding this shouldn't happen. The relevant snippets are: struct BT { … void bt() { //the bt "procedure" from wikipedia ++recursion_depth; //global variable static bool found(false); if (reject()) { --recursion_depth; return; } if (accept()) { found=true; output(); if (find_all) solutions.push_back(state); --recursion_depth; return; } BT s=first(); while (s.isValid) { s.bt(); if (found && ! find_all) break; s.next(); } --recursion_depth; } BT first() { BT result(*this); //modify result return result; } bool accept(); bool reject(); void next(); } first() creates a copy of its class variable, modifies it and returns the copy by value. The variable "result" goes out of scope and gets destroyed. In bt() the copy is assigned to s and then s itself calls bt(). But s also gets destroyed when bt() returns. So where does the leaking come from? (solutions.push_back() is not the problem, memory gets consumed even though no new solutions are found.) Is it a problem inherent to recursion? |
| Barry Schwarz <schwarzb@dqel.com>: May 31 09:13AM -0700 On Thu, 31 May 2018 14:55:50 +0200, Ralf Goertz >found solutions and accordingly recursion_depth stays at or below its >maximum value of 65. According to my understanding this shouldn't >happen. The relevant snippets are: If you don't where or why the problem is occurring, then what is your basis for deciding what is relevant? We need to see a complete compilable example that demonstrates the problem. We don't need all the internal details. If your sample exhibits the undesired behavior, we have enough. The code you showed for first() is a suitable stub for the function details we don't need and can be used as a template for accept, reject, isValid, etc. We also need to see the actual constructor for BT I don't know if it is related or not but only one copy of a member function exists, not a new copy for each class object. Consequently, the variable found is common to all the objects and is initialized before program execution begins. Once set to true, it is never set back to false. -- Remove del for email |
| Paavo Helde <myfirstname@osa.pri.ee>: May 31 09:25PM +0300 On 31.05.2018 15:55, Ralf Goertz wrote: > leaking come from? (solutions.push_back() is not the problem, memory > gets consumed even though no new solutions are found.) Is it a problem > inherent to recursion? If you don't have a new (or malloc;-S) in your program then you cannot have a memory leak in the classical sense that the memory is lost and cannot be freed. You can have accumulation of data somewhere where it should not be. You can also see an effect of memory fragmentation. In case of memory fragmentation the apparent memory growth should eventually slow down and approach a more or less stable level. However, if you have no explicit dynamic allocations in your code you probably won't have memory fragmentation either. In recursive programs what takes memory is the stack, but if you say the recursion depth is limited then it should not grow either. So I guess there is either a bug in the code you did not show, or a bug in the compiler related to recursion (very unlikely). |
| 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. |
