More Coverage

Edward Palonek's programming rss feed: comp.lang.c++ Google Group

• Re: Oozing poison But it is a typical novice error that leads to false assumptions
  regarding exception performance.
  

  It may well be, but the catch and the throw my still be several calls
  away. Using nested small functions is much cleaner with exceptions than
  with return codes. In your example you return the state in the object Sat, 28 Jan 2012 05:06:34 UT

• Re: Oozing poison Er, exceptions are intended to be _exceptional_.
  

  If some exception occurs so often that it has a measurable performance
  impact, it probably shouldn't be an exception.
  

  If you look at the code generated for the two styles, one of the big
  differences with the exception-using code is that the _normal_ case Sat, 28 Jan 2012 04:44:31 UT

• Re: Oozing poison Good to know, I guess. Since I intend to keep the malloc and forgo
  the try/catch clause, the point is however moot.
  

  However, in this case (modeling a physical device), the best determination
  of how to present the failure can be made as close to the cause of the
  exception as possible. I would think that for most applications that Sat, 28 Jan 2012 04:18:30 UT

• Re: Leigh's GUI [OT] Well I thought it may make an interesting discussion since there isn't much
  else going on around here.
  

  The android OS has become quite a big player in the booming smartphone
  sector. I think most C++ programmers would be interested in what the C++
  languages' role is in this OS.
  AFAICT there is not a not much support for C++ at application level , other Sat, 28 Jan 2012 00:09:22 UT

• Re: Oozing poison never catch exceptions by value, always catch by const reference to
  avoid slicing.
  

  This is fairly atypical use of exceptions, mixing exceptions and return
  codes. It is more common to catch the exception at a higher call. This
  simplifies the source and machine code (fewer conditional branches). Fri, 27 Jan 2012 23:22:07 UT

• Re: Leigh's GUI [OT] That is off-topic, yes.
  

  /Leigh Fri, 27 Jan 2012 22:29:51 UT

• Leigh's GUI [OT] Hello
  Leigh are you sure there is a market/requirement amongst Android developers
  for your C++ graphics thingy, re: [link]
  

  I was looking at developing for Android it seems all applications run in a
  JVM. Sure native code can be used but this would be through JNI so I don't
  see how your neogfx program would work on an android system. Fri, 27 Jan 2012 22:23:09 UT

• Re: Oozing poison I agree, of course, but when you have to deal with legacy C or low level
  code casting appears (and I have to say that there is a lot of legacy C
  code)
  

  --
  Cholo Lennon
  Bs.As.
  ARG Fri, 27 Jan 2012 21:28:46 UT

• Re: Oozing poison uint8 cmd = iocb->get_op_var2();
  

  buf = (uint8 *)malloc(bufsize);
  if (buf == NULL) {
  iocb->set_rd(IOT_WITH_EXCEPTIO NS, RD1_OCS_MPU_PARITY);
  return false;
  }
  

  switch (cmd) {
  

  vs.
  

  uint8 cmd = iocb->get_op_var2();
  

  try {
  buf = new uint8[bufsize]; Fri, 27 Jan 2012 21:26:23 UT

• Re: Oozing poison How comes one version has multiple calls to new and the other one call
  to malloc?
  

  What was the original source?
  

  --
  Ian Collins Fri, 27 Jan 2012 21:06:36 UT

• Re: Oozing poison A large proportion of my work is in embedded devices, where the byte
  count is even more important!
  

  These days of low cost, plentiful RAM, the most important factor in
  hypervisor or operating system is performance, not code size.
  

  As I said above, if code size is an an issue, there are well known Fri, 27 Jan 2012 21:01:50 UT

• Re: Oozing poison I tried substituting a 'new uint8[xx}' call to replace a malloc with a try
  catch block for bad_alloc. I then disassembled the code. One instruction
  (to test the return value of the malloc) turned into:
  

  try {
  buf = new uint8[bufsize];
  7327: 4c 89 f7 mov %r14,%rdi Fri, 27 Jan 2012 20:29:46 UT

• Re: Oozing poison Unless you are writing an operating system or hypervisor where every byte
  counts.
  

  scott Fri, 27 Jan 2012 20:16:45 UT

Archive: Press Archive