Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > typedef, 2D arrays, design: question

Reply
Thread Tools

typedef, 2D arrays, design: question

 
 
gdotone@gmail.com
Guest
Posts: n/a
 
      09-19-2012
Thanks very much.
 
Reply With Quote
 
 
 
 
Seungbeom Kim
Guest
Posts: n/a
 
      09-19-2012
On 2012-09-13 15:10, John Bode wrote:
>
> Honestly? Not so much, at least not in my experience. Typedefs almost always
> wind up hiding information that I need to know. The code is more "readable"
> in that it scans more easily, but it's less *understandable* in that I don't
> necessarily know how to *use* objects of that type without chasing down the
> typedef. In a large project with several hundred files spread over different
> directories, that can be a pain.


Information hiding, or abstraction, is an important *feature* of typedef,
I'd rather say. (Of course, it's not perfect...) In a large project,
having to deal with every detail everywhere can be a pain.

>
> For example, what conversion specifier do I use to print a value of type
> "scalar" (assuming whoever defined the typedef hasn't also provided routines
> to read and write such values)? In this case, it's whatever I would use for
> a "double" (%f, %g, etc.), but if I don't know what a "scalar" is off the top of
> my head, I have to go looking for the typedef.


True. It's an example of a leaky abstraction, where the information
hiding is not perfect. Sometimes the abstraction can/should provide
a dedicated I/O function (like print_matrix), or a format specifier
macro (like PRIxPTR for uintptr_t), but it's not always done or doable,
unfortunately.

>
> Or, even better, there's a school of thought that likes to typedef function
> pointers, like
>
> typedef void (*Callback)(int, double, double);
>
> so you can write function declarations that look like
>
> void bar(int x, Callback c);
>
> instead of
>
> void bar(int x, void (*c)(int, double, double));
>
> Yeah, the first form scans more easily, but it doesn't tell me anything about
> what Callback returns, or how many arguments it takes, or what their types are,
> or that it's *even a function* (I assume that from the name "Callback", but
> not everyone names their typedefs so helpfully). Again, if I don't have the
> definition handy, I have to stop and go looking for it. By contrast, the second
> form tells me everything I need to know about how to *use* c, right there in
> front of me. I know that it's a function that takes 3 parameters of type int,
> double, and double, and returns void.


Yes, but you always carry all the details, even when you don't need them
(e.g. when you're merely passing such an argument). It can be a pain to
have to write and understand

void (*bar(int x, void (*c)(int, double, double)))(int, double, double);

instead of

Callback bar(int x, Callback c);

Of course, you'll need the details *at some point*, no matter whether
you use typedef or not.

>
> IME, typedefs work best for types that are meant to be truly opaque, where
> the programmer *shouldn't* need to know anything about the underlying
> representation, such as the FILE typedef. You don't manipulate objects of
> FILE type directly, you manipulate them through the interface provided
> by stdio.


Agreed, that's a good example.

>
> One of my favorite build breaks resulted from a typedef name hiding the
> "pointerness" of a type (this is C++, but you should get the idea):
>
> for(vector<typedef_name>::iterator it = v.begin(); it != v.end(); ++it)
> it->foo();
>
> Unfortunately, "typedef_name" was along the lines of
>
> typedef some_class* typedef_name;
>
> where "typedef_name" gave ABSOLUTELY NO CLUE that this was a pointer type,
> meaning the above code *should* have been written
>
> for(vector<typedef_name>::iterator it = v.begin(); it != v.end(); ++it)
> (*it)->foo();
>
> and thanks to g++'s incontinence whenever there's an error involving a
> template, it took more than a minute to figure out what the hell was going
> on.


Just a few minutes? You were so quick.

>
> So, conceptually, is a matrix really an array of vectors, or is it a 2D array
> of scalars?


Both. In mathematics, a matrix of M-by-N scalars, a matrix of M rows of
N row vectors, and a matrix of N columns of M column vectors are all
used interchangeably. So it doesn't matter really.

>
> Yes, essentially; you're trying to abstract away details that don't matter at
> a given level.
>
> But...
>
> At some point you have to translate from the problem domain to the
> implementation. The key is the "don't matter" part; again, if the programmer
> *has* to be aware of the underlying representation of the object, then you don't
> want to hide that object's type behind a typedef.


In nearly all cases, the programmer has to be aware of the underlying
representation of the object *at some point*, of course. Does that mean
you don't want typedef in nearly all such cases? I don't think so.

>
> IME, when writing C code, it's better to err on the side of less abstraction;
> details start to matter early on. Rather than creating a bunch of typedefs,
> use native types and comment liberally.


I see your point here.

I don't agree fully, though. IMHO programming is all about abstraction;
not only typedefs, but macros are also abstractions, functions and
operators are abstractions of the underlying behaviour, and even types
themselves are also abstractions of the underlying bits. Abstraction is
what makes us much more productive writing in C than in assembly or
machine code.

Following your argument could lead to objecting to all such abstractions.
(Yes, I've seen people objecting to C++ because it doesn't reveal every
detail at hand.) In small programs, it may be feasible to forgo many of
them and write with bare literals and put most of the program in main(),
but I'm afraid that way you'll have more trouble with the burden of all
the details. (Or maybe it's just that you'll need a different language
with more powerful abstraction facilities for larger programs anyway,
and that it doesn't really matter in C. )

--
Seungbeom Kim
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
question row filter (more of sql query question) =?Utf-8?B?YW5kcmV3MDA3?= ASP .Net 2 10-06-2005 01:07 PM
Quick Question - Newby Question =?Utf-8?B?UnlhbiBTbWl0aA==?= ASP .Net 4 02-16-2005 11:59 AM
Question on Transcender Question :-) eddiec MCSE 6 05-20-2004 06:59 AM
Question re: features of the 831 router (also a 924 question) Wayne Cisco 0 03-02-2004 07:57 PM
Syntax Question - Novice Question sean ASP .Net 1 10-20-2003 12:18 PM



Advertisments