function pointers

[Guest]

Storing one of several values in a function pointer object, so you can
call a function that's determined at run time, can substitute for a
switch statement, which executes one of several blocks of code
selected at run time.  There are significant differences, of course,
and the two are not directly interchangeable.  For example, the
function pointer approach provides no equivalent for a switch
statement's fallthrough semantics.

Isn't it effectually equivalent to call another function at the end of
one?

 

[cr88192]

Why? I get all that ability. Of course, I am using gcc under
DJGPP on winders.

my case:
I use mostly mingw.
cygwin dumps a stack trace, but there are IMO other issues with cygwin...


so, I typically use cygwin for smaller projects, and mingw for larger ones.
mingw is, of course, a little less nice in some regards than cygwin.

or such...

 

[Ian Collins]

Why? I get all that ability. Of course, I am using gcc under
DJGPP on winders.

You prove my point, jumping through hoops to get a useful environment.

 

[jacob navia]

You prove my point, jumping through hoops to get a useful environment.

I am programming in debian, I have a customer under linux that
wants a server application.

I installed debian (latest).

To boot, I start with a menu of the "grub" booting utility.

I point the cursor at the first line, then I press "e", then
"e" again, then I change (hd1,0) to (hd0,0). Then I
scroll to the second line and press "b". Then I am able to boot.

This is due to a bug in debian that mixed up the 3 disks in my machine.

After this, I boot only when I do not do a restart. Debian needs
a cold restart to boot. Any warm restart (ctrl+alt+del) doesn't
work and the boot process hangs after a few seconds.

When I arrive at the desktop, I type my name and see a thing called
"gnome". It is a great desktop. Sound doesn't work, nor my music
collection, anyway who cares. The Desktop shows some icons
about the different disks. There is no way to hide those
useless icons. Th desktop shows very often the cdrom icon on top
of another icon. Then you have to move it each time you insert
a cdrom to access the cdrom contents.

Debian doesn't like that people go away. When I go away it will start
a desktop screen saver program. I changed the screen saver to a
blank screen, then, I discovered that the screen saver doesn't
come back, i.e. you can type like crazy at the keyboard but
the screen REMAINS blank.

Great. I lost everything and now I have the screen saver time delay
at 10 000 minutes...

There is no IDE, nor any modern development system. I use vi,
gdb, and the compiler, exactly like in 1986 when I first started using
Unix.

The different "IDE"s are all completely crap. No go to definition,
no browse by function, no nothing. They are barely able to
start the compiler.

There is only one debugger: gdb. All other "debuggers" are just
software on top of that, but since they did not integrate
the debugger source code into the IDE they offer NO extra functionality
but they offer a layer of BUGS that is quite incredible.

Printer doesn't work, but this is no great pain since I can always
reboot and print under windows.

There is no obvious way to write to a DVD to make a backup. I looked
at some "HOWTOS" (that goes as documentation this days), but
they were outdated. Obviously, for Unix gurus I am just a looser that
doesn't know how to use the system, and that is right. I did not want
to learn how to write obscure commands to make the sound work, to
download software from the internet to make the cd writer work,
to study CUPS and make the printer work, to study GRUB and see why my
changes to the configuration file are overwritten...

Yes, I *could* learn all that if I wanted to... I learned enough of GRUB
to find out that the grub system mixed the hard disks and that I had
to replace hd1 by hd0 using the built in editor (took me 2 hours) of
googling, reading, etc.

That was a FATAL error and I HAD to fix it. But I can live
without sound, printer, screen saver, and I can develop
using vi+gcc+gdb. It is horrible but if it is well paid
I do not give a damm. I have programmed in worst environment
than this one.

At least, vi works, and I do not have to use ed



I am a linux user since it came out with the first slackwares...
ANd I will go on using it, mind you. As long as there are
customers under that stuff, and as long as I can make it
do what I need, it is ok!

 

[cr88192]

I am programming in debian, I have a customer under linux that
wants a server application.

I installed debian (latest).

There is no IDE, nor any modern development system. I use vi,
gdb, and the compiler, exactly like in 1986 when I first started using
Unix.

when running on linux, I usually use gedit or kedit.

The different "IDE"s are all completely crap. No go to definition,
no browse by function, no nothing. They are barely able to
start the compiler.

There is only one debugger: gdb. All other "debuggers" are just
software on top of that, but since they did not integrate
the debugger source code into the IDE they offer NO extra functionality
but they offer a layer of BUGS that is quite incredible.

back when I was young, I was developing using a version of Turbo C.
worked pretty, well, and I developed on DOS.

I forget the specifics, TC was really cheap in the early 90s, back when I
was young (early elem, technically, but coding was cool, and parents got for
me a compiler and some books...).


this was long ago, and I operated pretty solidly in DOS.
later on in this part of my life, Win95 was around and gaining popularity,
but I mostly used Win3.11, as my computer at the time was a little weak for
95 (I think I had a few other gripes with 95 as well).

in general though, I developed primarily in DOS land...

eventually, I switched over to DJGPP (moving along into the later 90s).

at this point, I went over to Linux, which had remained my primary OS.
on linux (back then, my preferred distro was Slackware), the main compiler I
used was, of course, GCC.

for a long time, my primary editor was jmacs, and I think I mostly used the
thing in console mode (this was before the rise of KDE and GNOME, on X there
was FVWM...).

later on, it was Mandrake, KDE, and GNOME (I forget exactly when these came
about).

around 2002 or 2003 or so, when the problems that endlessly plague Linux
(lame driver support, ...) eventually frustrated me into a switch (I used
Win 2000, as IMO 98 was worse crap than 95, but oddly, my brother liked 98
more, I guess because most games tended to break on 2000...).

I liked an OS that didn't crash endlessly...

and, on Windows, I used GCC (primarily Cygwin).

and, several years later, I switched over primarily to MinGW.


and, as such, I have never really had much use for, or dependence on,
IDEs...

however, I have often wished that some things were a little nicer though (I
have been engineering some of my "own" solutions though, namely, a slightly
"different" way of approaching compilers).


in a very technical sense, I have a kind of C-based VM.
it is torn between the worlds of static compilation and being a VM...

technically the inverse of the JVM, or LLVM, though, which "compile" then
"run in the VM", rather, the VM *is* the compiler, and the linker, so it
starts pulling in and linking static libraries, objects, and source files,
at runtime...

Printer doesn't work, but this is no great pain since I can always
reboot and print under windows.

There is no obvious way to write to a DVD to make a backup. I looked
at some "HOWTOS" (that goes as documentation this days), but
they were outdated. Obviously, for Unix gurus I am just a looser that
doesn't know how to use the system, and that is right. I did not want
to learn how to write obscure commands to make the sound work, to
download software from the internet to make the cd writer work,
to study CUPS and make the printer work, to study GRUB and see why my
changes to the configuration file are overwritten...

yes.

I remember back when CD recorders were new as well...

never have done a whole lot of burning in linux though.
even when it works, mkisofs+cdrecord is a hassle to get to work...

Yes, I *could* learn all that if I wanted to... I learned enough of GRUB
to find out that the grub system mixed the hard disks and that I had
to replace hd1 by hd0 using the built in editor (took me 2 hours) of
googling, reading, etc.

That was a FATAL error and I HAD to fix it. But I can live
without sound, printer, screen saver, and I can develop
using vi+gcc+gdb. It is horrible but if it is well paid
I do not give a damm. I have programmed in worst environment
than this one.

At least, vi works, and I do not have to use ed



I am a linux user since it came out with the first slackwares...
ANd I will go on using it, mind you. As long as there are
customers under that stuff, and as long as I can make it
do what I need, it is ok!

well, my comment is that gedit or kedit may be worthwhile.

gedit has tabs and syntax highlighting, and kedit is more like notepad...


I sit and watch in hope that linux's driver support eventually stops being
so terrible...
if I use the OS, sound and network are at least a few major things I like to
work...

that is probably the major reason I am not using linux right now...

 

[Ian Collins]

I am programming in debian, I have a customer under linux that
wants a server application.

I installed debian (latest).

In these days of virtual machines I just install what ever the client
wants in a VM. No messing about and I can use my standard desktop tools.

 

[Ark Khasin]

Ark Khasin said:


No, it's an excellent practice, albeit rather hard to achieve. Assertions
should indeed be redundant, and therefore should never, ever fire. If,
therefore, they do, it means that something is wrong with the program.
That's their job - to show that the program is broken in a particular way.

If the programmer manages to make all other necessary checks without any
redundancy, his program will fly. In practice, however, it's rather
difficult to do.

Perhaps, I didn't make myself clear.
Asserts are great for catching 'em bugs.
IMHO, they are not meant to crash the program on erroneous user input.
By implication, an input to an API-level function is still a user input
- programmatically generated from the efforts of another programmer.
This stuff should be accounted for by the argument checking and
conscious actions on errors.
One might argue that with that in place an extra assert won't hurt. I
tend to agree - but the purpose of an assert now is to catch a bug in
input validation.
Curiously, if the input checking is coded well, then an "extra safety"
assert may invite diagnostics from PC-Lint and/or from an overzealous
compiler (unreachable code)

 

[Ark Khasin]

If there's a need for a check, then there should be one. There's no need
for several checks. Maybe the calling function needs to validate user
input before passing it to the function:

unsigned i;
scanf("%u",&i);

if (i > 4)
{
puts("Bad input, bailing out.");
exit(EXIT_FAILURE);
}

Func(i);

And then there are the times when no checks are necessary:

unsigned i = some_number % 5;

Func(i);

Turns out there's little or no disagreement here.
[I won't pick on not checking the return value of scanf and not
analyzing the rest of the line in stdin. This has been torn apart in
this NG before, but I suppose you just showed the idea of the code.]

On a subject of who should do the input validation - the caller or the
callee: if 100 guys are calling your function, perhaps, 61 of them will
not validate the input (yes, 83% of all statistics are made up on the
spot, even though some 31 ought to (and 30 have naturally safe
cases). The rest 39 will duplicate the validation code which could be
conveniently put once in your function.

[Of course I am talking about production code, not about the throwaway
artifacts of prototyping and exploration.]

 

[Tomás Ó hÉilidhe]

On a subject of who should do the input validation - the caller or the
callee: if 100 guys are calling your function, perhaps, 61 of them
will not validate the input (yes, 83% of all statistics are made up on
the spot, even though some 31 ought to (and 30 have naturally safe
cases). The rest 39 will duplicate the validation code which could be
conveniently put once in your function.

Duplicate code... ? What do we normally do when we've got duplicate code?
Yes, you guessed it:


int ValidateInput(unsigned const i)
{
return 5 > i;
}


I'm just not a fan of adding inefficiency to a system. If you add
inefficiency willy-nilly, and then make the program more and more
complicated with more and more layers adding inefficiency willy-nilly all
the while, then you're left with an operating system that could have run
15% faster if the programmers hadn't been such boring old men.

 

[Richard]

I am programming in debian, I have a customer under linux that
wants a server application.

I installed debian (latest).

To boot, I start with a menu of the "grub" booting utility.

I point the cursor at the first line, then I press "e", then
"e" again, then I change (hd1,0) to (hd0,0). Then I
scroll to the second line and press "b". Then I am able to boot.

This is due to a bug in debian that mixed up the 3 disks in my
machine.

then alter your grubs menu.lst. Google it up.

After this, I boot only when I do not do a restart. Debian needs
a cold restart to boot. Any warm restart (ctrl+alt+del) doesn't
work and the boot process hangs after a few seconds.

Then you screwed something up. Debian dual boot works flawlessly. Remove
it and install again.

When I arrive at the desktop, I type my name and see a thing called
"gnome". It is a great desktop. Sound doesn't work, nor my music
collection, anyway who cares. The Desktop shows some icons
about the different disks. There is no way to hide those
useless icons. Th desktop shows very often the cdrom icon on top

Yes there is. Google up volume manager.

or

http://www.howtogeek.com/howto/ubuntu/hide-removable-drive-icons-from-your-ubuntu-desktop/

of another icon. Then you have to move it each time you insert
a cdrom to access the cdrom contents.

Debian doesn't like that people go away. When I go away it will start
a desktop screen saver program. I changed the screen saver to a
blank screen, then, I discovered that the screen saver doesn't
come back, i.e. you can type like crazy at the keyboard but
the screen REMAINS blank.

Then turn it off from the preferences.

Great. I lost everything and now I have the screen saver time delay
at 10 000 minutes...

There is no IDE, nor any modern development system. I use vi,
gdb, and the compiler, exactly like in 1986 when I first started using
Unix.

Eclipse is available.

The different "IDE"s are all completely crap. No go to definition,
no browse by function, no nothing. They are barely able to
start the compiler.

Not true at all. Emacs with cscope/tags kicks ass.

There is only one debugger: gdb. All other "debuggers" are just
software on top of that, but since they did not integrate
the debugger source code into the IDE they offer NO extra functionality
but they offer a layer of BUGS that is quite incredible.

gdb is a great debugger.

Printer doesn't work, but this is no great pain since I can always
reboot and print under windows.

There is no obvious way to write to a DVD to make a backup. I looked

install k3b from synaptic.

at some "HOWTOS" (that goes as documentation this days), but
they were outdated. Obviously, for Unix gurus I am just a looser that
doesn't know how to use the system, and that is right. I did not want
to learn how to write obscure commands to make the sound work, to
download software from the internet to make the cd writer work,
to study CUPS and make the printer work, to study GRUB and see why my
changes to the configuration file are overwritten...

Yes, I *could* learn all that if I wanted to... I learned enough of GRUB
to find out that the grub system mixed the hard disks and that I had
to replace hd1 by hd0 using the built in editor (took me 2 hours) of
googling, reading, etc.

Its a new OS. Of course there are things to learn.

 

[J. J. Farrell]

Perhaps, I didn't make myself clear.
Asserts are great for catching 'em bugs.
IMHO, they are not meant to crash the program on erroneous user input.
By implication, an input to an API-level function is still a user input
- programmatically generated from the efforts of another programmer.
This stuff should be accounted for by the argument checking and
conscious actions on errors.
One might argue that with that in place an extra assert won't hurt. I
tend to agree - but the purpose of an assert now is to catch a bug in
input validation.
Curiously, if the input checking is coded well, then an "extra safety"
assert may invite diagnostics from PC-Lint and/or from an overzealous
compiler (unreachable code)

I think you missed the word "redundant" (give or take an 'n'). If the
asserts are redundant, then they're checking something which the coder
believes he has already checked in the normal code. The redundant
asserts are there purely as a debugging aid to make sure that the checks
in the main code have done their job properly.

I believe Tomás was saying that he aims to check things exactly once in
the main run-time code. The only time he might check again is in the
form of an assert, whose job is to make sure that the real check worked
as expected.

 

[Tomás Ó hÉilidhe]

I believe Tomás was saying that he aims to check things exactly once in
the main run-time code. The only time he might check again is in the
form of an assert, whose job is to make sure that the real check worked
as expected.

I use asserts so as to avoid horrible bug searches. For instance, let's
say I change one line of my code and all of a sudden the program just won't
work. It compiles fine, it links fine, but then when I go to run it I get
"Windows has ended this program because blah blah".

Just within the last few days, I played around with a program's code,
hit compile, and ran it but it stopped after two seconds and said. "assert
failed, x > 3". This makes it a hell of a lot easier to fix the code.

And I'll use assert liberally all over the place by the way. Efficiency
is of no concern to me in the debug build. The release build however will
be lean.