I have a legacy C API that I need to add functionality to. Specifically I need to make some of this API's calls thread-safe, because a call like this:
A_DoFoo(HandleA a)
Uses an object shared by all handles of type A.
My first thought is to add a function to the API that looks like this:
A_DoFooEx(HandleA a, HandleB b)
Is this a normal approach?
(I only used the Ex suffix because of years of exposure to the Win32 SDK. Does it make more sense to give a more descriptive name to the function?)
Adding another function under a new name is the standard (and in fact just about the only) way to deal with this problem in straight C (in C++ you could add a new overload and keep the old name). I'm not a big fan of the Ex suffix, because it doesn't tell you what the difference between the old and new APIs is. On the other hand, don't saddle people with something long and heinous like A_DoFoo_ThreadSafe, that hurts readability.
In this case, I'd try to think of a name that indicates what the requirements on HandleB are. If you tell us what this API actually does, we can maybe make more specific suggestions.
I prefer writing wrapper for thread safe code. So I can embedded any thread un safe code and make it thread safe use wrapper.
You should always use a proper naming format.
it will help you easily maintain your code and make it more readable.
Related
I've just read the book called clean code. The author Uncle Bob talks about a single responsibility that a function should have in a program. It should only do one thing.
Now, I would like to understand how is it now possible to reuse a code that does multiple things. Let's say I have a method called runTrafficAndCheckIfItPassed and it calls two methods inside of it: runTraffic and checkIfTrafficPassed.
Now let's say that in my software I need to run traffic and to check it's result in a lot of places in my software. sometimes i need to check that traffic has failed, and sometimes i need to check if it passed.
Why wouldn't it be right to call the runTrafficAndCheckIfItPassed function and why is it way better to call the functions inside separately?
As far as I see, if there will be a change in the runTraffic function, for example to receive another parameter, the change will be implemented in one place, only in runTrafficAndCheckIfItPassed, which we see will be kinda easy to maintain.
But if i will use the functions seperately i will need to change it in any place.
But Bob says it's wrong? Got any examples or tips why it is called wrong?
I find myself using a certain helper a lot in Views. I call it like this:
$this->MyHelper->foo()
It's a big nuisance to type this construct every time. I wish i could use a shortened version instead:
foo()
It should be available in Views.
How do i do that?
That's what IDE and type-completion is for.
You will open a can of worms and collisions with such an approach.
Also it doesn't make your code any more useful or better to understand btw.
The opposite: It is destined to blow up.
But if you must you can create yourself wrappers to access it via
$this->foo()
as long as there is no collision and you write yourself a custom View class to allow that.
foo() itself - if you think about it - is not possible as this would require static access and destroys the whole idea of reusable objects.
But again: It's a bad idea to begin with.
It is a simple PHP variable assigning technique:
Use:
$obj = $this->MyHelper;
$obj->foo();
Hope this will be helpful to you.
Are there any libraries/function available in C to pretty print tabular data. I am looking for something like this : http://code.google.com/p/prettytable/
If you really want to implement something as generic-looking as the Python module seems to be, one problem is going to be data storage. It's not so easy to just throw stuff into a list in C, of course. You might want to look at glib's GVariant solution for instance. It would be pretty easy to build a table-formatter handling any reasonable type of value based on that.
Me and my colleague are developing an ms access based application. We are designing and coding different pages/forms in order to divide work. We plan to merge our work later. How can we do that without any problems like spoiling the design and macros? We are using Ms access 2007 for front end and sqlserver 2005 as the datasource.
I found an idea somewhere on bytes.com. I can import forms, reports, queries,data and tables that I want.I'm going to try this. However, it's just an idea.So, need to study this approach by trial and error techniques.
The most important requirement is to complete the overall design before you start coding. For example:
All the forms must have the same style. Help and error information must be provided in the same way on each form. If a user can divide the forms into two sets, you have failed.
The database design must be finished with a complete, written description of each table, its relationships and its attributes.
The purpose and parameters for each major macro must be defined. If macro A1 exists only to service macro A then A1 is not a major macro and only A's author need know of its details until coding is complete.
Agreed a documentation style and detail level. If the application needs enhancement in six or twelve months' time, you should be able to work on the others macros and forms as easily as on your own.
If one of you thinks a change to the design is required after coding has started, this change must be documented, agreed with the other and the change specification added to the master specification.
Many years ago I lectured on (Electronic Data interchange (EDI). With EDI, the specification is divided into two with one set of organisations providing applications for message senders and another set providing applications for message receivers. I often used an example in my lectures to help my audience understand the importance of a complete, unambiguous specification.
I want two shapes, an E and a reverse-E, which I can fit together to create a 10 cm square. I do not care what they are made of providing they fit together perfectly.
If I give this task to a single organisation, this specification will be enough. One organisation might use cardboard, another metal, but I do not care. But suppose I ask one organisation to create the E and another the reverse-E. How detailed does my specification have to be if I am to get my 10 cm square? I would suggest: material, thickness and dimensions of the E. My audience would compete to suggest more and more obscure characteristics that had to match: density, colour, pattern, texture, etc, etc.
I was not always convinced my audience listened to the rest of my lecture because they were searching for a characteristic that would cap all the others. No matter, I had got across my major point which was why EDI specifications were no mind-blowingly detailed.
Your situation will not be so difficult since you and your colleague are probably in the same room and can talk whenever you want. But I hope this example helps you understand how easy is it for the interface between your two parts to be less than seamless if you do not agree the complete design at the beginning. It's the little assumptions - I though you knew I was doing it that way - that will kill your application.
New section
OK, probably most of my earlier advice was inappropriate in your situation.
So you are trying to modify code you did not write in a language you do not know. Good luck; you will need it.
I think scope is going to be your biggest problem. Most modern languages have namespaces allowing you to give a variable or a routine as much or as little scope as you require. VBA only has three levels.
A variable declared within a function or subroutine is automatically private to that function or subroutine.
A variable declared as Private within a module is invisible to functions and subroutines in other modules but is visible to any function or subroutine within the module.
A variable declared as Public within a module is visible to any function or subroutine within the project.
Anything declared within a form is private to that form. If a form wishes to pass a value to an outside function or subroutine, it can do so by writing to a public variable or by passing it in a parameter to a public function or subroutine.
Avoiding Naming Conflicts within VBA Help gives useful advice.
Form and module names will have to be unique across the merged project. You will not be able to avoid have constants, variables, functions and sub-routines which are visible to the other's functions and sub-routines. Avoiding Naming Conflicts offers one approach. An approach I have used successfully is to divide the application into sub-applications and, if necessary, sub-sub-applications and to assign a prefix to each. If every public constant, variable, function and sub-routine name has the appropriate prefix you can simulate namespace type control.
I'm creating a small Avida-style life simulation. I started out with a very basic, everything-is-global 600-line program in a single file to test some ideas, and now I want to create a real design.
Among other things, I had a global configuration object that every other function got something out of. Now, I must localize the object and pass pointers around. Thing is, mostly everyone needs this object. I've thought of three possible solutions:
a) Keep the configuration object
global (simplest, though not really a
solution)
b) Store pointers everywhere they are
needed (easy enough, though a waste
of memory, since some small
plain-old-data structures would need
it).
c) Create factories for the POD types
that need access to options, and have
the factory perform all operations on
them.
Of my ideas, only (c) sounds logical, but I don't want to needlessly complicate the structure. What would you guys do?
I'm fine with new ideas, and will provide whatever information about the program you want to know.
Thanks in advance!
I have to agree with #Carl Norum: there is nothing wrong with the global config setup you have now. You say that everybody "got something out of" it. As you know, the problem with globals comes when everybody writes into them. In your case, the config info truly is needed globally so deserves to be global.
If you want to make it be a little more decoupled and protected -- a little less global-ish -- then why not add some read/write access routines.
See, storing pointers everywhere isn't going to really solve the problem: it will only add a layer of indirection that will merely disguise or camouflage what are, in reality, the global accesses that are making you nervous. And that extra layer of indirection will add juuuuust enough room for juuuuust a teeny-weeny little bug to creep in.
So, bottom line: if stuff is naturally global then make it global and don't worry about the usual widespread received wisdom that's mostly correct but might not be the right thing in your application. To always be bound by the rules/propaganda that CS teachers put out there is, imo, the perfect example of a foolish consistency.
Global variables are awesome. Spend your time actually getting something done instead of refactoring for no reason. Every company I have worked at uses them heavily.
Ask yourself if you're actually gaining anything by moving it to an object you're just passing around everywhere. Might as well save yourself the extra complexity..
Go for B, unless profiling proves it to be a problem. On most machines, the memory required to store a pointer is very, very trivial.