HashMap in symbian - symbian

i want to implement Hashmap in symbian
which takes two values
is there any body who have implement it
there is class RHashMap,RHashTable but i want to pass descrpter and value
or
else is there any class other solution for this
thanks in advance

I think the documentation doesn't make clear the fact that you should probably have a class that contains an integer and a descriptor.
The THashFunction32 that you need to implement takes one instance of your class and return it's integer member.
The TIdentityRelation that you need to implement takes two instances of your class and compares the integer members.
When you insert an instance of your class into the RHashMap, both the integer and the descriptor members need to have meaningful values.
When you want to retrieve a descriptor from your RHashMap, you create and instance of your class but only set the integer member value. Use that object as a parameter to RHashMap::Find() and it will return the instance of your class that contains the descriptor you were looking for.

RHashMap is a templated type. You can use whatever classes you requires as follows:
RhashMap<TInt,TPtr> map;
map.Insert(myInt,myDes);
...
myDes = map.FindL(myInt);
TInt error = map.Remove(myInt);
User::LeaveIfError(error);
map.Close();
Edit: If you wanted a single key to point to two things, then just encapsulate those two things in a single object.

Related

Is there any good reason to use 'id' as return type or parameter type in public API?

I am learning from Stanford's CS193P course. In the class, Paul has a demo project, "Calculator", where he uses id as the type of a property. He intends to not use a specific class, because he does not want to create a new class and then he does not need to write documentation, and even when it is updated, he does not need to redesign the class. id can solve all these problems.
Is this a really a good way? id is the return type of the property, and used as the parameter type of another method. How does the caller know what id is, and how to provide the correct object? By reading code comments?
In general, is there any good reason to use id as a return type or parameter type in public API? (Except init and factory method, though even for those, instancetype is recommended.)
If your method returns a class that is a member of a class cluster, you should return id.
If you're returning an object whose class is opaque, isn't declared in a public header, you should return id. (Cocoa occasionally uses such objects as tokens or context data.)
Container classes should always accept and return their constituents as ids.

How to implement introspection on RealBasic?

RealBasic's Introspection is kinda of different than what I expected.
My intention is:
Create a MainObject from which other objects will inherit two, three methods, to simplify.
Method 1-> Returns to the child class itself all of its properties, types and values.
Method 2-> Would call Method1 and with the information, save the child Object.
So, for method 1 I thought about writing a generalised introspection which for each child class would easily return what I need for Method 2 to do its work.
Why do I want this? So I can have tens of objects knowing how to save, draw themselves without worrying too much about a modification here or there on the properties etc...
But using what RealBasic tutorials and reference offers doesn't work, since it requires me to have it happening outside the object etc... i.e.: I can easily, inside ObjectA, get ObjectB's properties, methods etc, but I want to get inside ObjectA, A's properties, not B's
Thanks in advance...
I've found out how... Very simple, create the MainClass and inside of it a simple method WhoAmI which could return an array, dictionary etc...
Dim thisClassTypeInfo As Introspection.TypeInfo = Introspection.GetType(Self)
Dim thisClassProperties() As Introspection.PropertyInfo = thisClassTypeInfo.GetProperties
Dim thisClassMethods() As Introspection.MethodInfo = thisClassTypeInfo.GetMethods
For Each myProperty As Introspection.PropertyInfo In thisClassProperties
// Then here use myProperty.Name, myProperty.Value(Self).StringValue
// or myProperty.Value(Self).anyotheroption and create a dictionary
// or array with the results and return it.
Next

Comparing String to class name

I have a little Problem:
I have a method that parses an incoming string for certain values, if a value is found, a new class is instantiated. The class name is identical to the parsed string. At the moment, my code looks like this:
Public Class Test1
End Class
Public Class Important
End Class
Public Class DoWork
Public Sub DoWork(incoming as String)
Select case incoming
case "Test1"
dim myobj as new Test1
Case "Important"
dim myobj as new Important
End Select
End Sub
End Class
I do not like the string literals like "Test1" - i could store them in a constant, but if the class names change, they have to be changed too. Is there a way to replace the literals with the Name of class?
I know that me.gettype produces the result for instantiated objects, but what about the simple name for a class, which is no object at this moment?
If your string is in correct format you can use Type.GetType(string) method to retrieve type. Then you can use Activator class to create instance if you have default constructor on that type.
Rafal's answer is good if you're stuck with the current situation, with the incoming string parameter. But it's still a bit fragile. What if the incoming parameter changes? What if you want to restructure your code, moving some classes to different namespaces or assemblies? What if those strings change - do you now have to rename your classes and recompile? You don't see the magic strings explicitly now, but they're still there.
So ask yourself - where are those strings coming from? Are they generated internally by your code? If so, you might want to generate, instead of strings, an Enum value that corresponds to the class to be instantiated. If they're external strings that you map to your classes, consider having explicit mapping (in a configuration file, for instance) that map String->Type. It's a bit more cumbersome, but a lot more flexible.

VB.NET - I'm Refactoring and Could Use Some Help

I'm working with vb.net, wcf, wpf and I'm refactoring working code with the hope of being able to reduce some amount of redundancy. I have a bunch of methods that get called in several places throughout the code that only have a slight variation from each other and I would like to replace them with a single method instead.
Specifically, each of the redundant methods process an 1-d array that contain different objects I have created. There are several of these different object types each with different signatures but they have all have a "name" and "Id" property. (Also these objects don't have a shared base class but I could add that if needed.) Each of the redundant methods deal with a different one of the object types.
To refactor the code I would like to pass any of the different object arrays to a single new method that could access the "name" and "id" properties. I'm trying to write this new method in a fashion that wouldn't require me to update it if I created more objects down the road.
I've done some reading on Delegates and Generic Classes but I can't really figure out how this fits in. It would almost be as if I wanted to create a generic class that could handle each of my object types but then somehow also access the "name" and "id" propeties of the different object types.
Any help you can provide would be appretiated. Also, please keep in mind this project is written in VB.net.
Thanks
Mike
It sounds like having your object implement a common interface or have a shared base class would be best. Interfaces give you the most flexibility down the road if you ever need to pass a class to this method that must derive from some other class that does not implement the interface. However, a base class that implements the interface may also be useful just to reduce the duplicate declarations of these properties.
Public Interface IThingThatHasNameAndId 'good name not included
ReadOnly Property Name As String
ReadOnly Property Id As Integer
End Interface
Once you have the interface, you can then pass arrays of types implementing the interface as IEnumerable(Of IThingThatHasNameAndId) or make a generic method taking T() and constrain T to the interface.
Make a base class with the Name and ID properties, then you can make a method that takes in any class that derrives from that class.
Public Function TestFunction(Of t As YourBaseClass)(Byval obj As t) As Boolean
If obj.Name = "Some Name" AndAlso obj.ID = 1 Then
Return True
Else
Return False
End If
End Function

VB Classes Best Practice - give all properties values?

Sorry if this is a bit random, but is it good practice to give all fields of a class a value when the class is instanciated? I'm just wondering if its better practice to have a constuctor that takes no parameters and gives all the fields default values, or whether fields that have values should be assigned and others left alone until required?
I hope that makes sense,
Becky
I don't know if it makes a performance difference or not, but any fields for which you have explicit default values I personally prefer to assign them in the declarations, as so:
Public Class MyClass
Private pIsDirty As Boolean = False
Private pDated as Date = Now()
End Class
Keep in mind most "simple" types like boolean, integer, etc. auto-default and don't NEED to be initialized, but I show that here as example and sometimes for clarity you want it anyway. Additionally since any classes I write are all for internal use (we don't sell any code objects for public use) I can be assured to the consumer of my classes. So I generally just write a minimal constructor (if a non-default one is needed) that only takes the primary fields, and spin up any additional values with the new With syntax in VB as so:
Dim myObj = New SomeClass() With { .Prop1 = "value", .Prop2 = Now() }
Your class' constructor should accept enough parameters to be in an usable state.
You can get the same functionality you seem to be looking for by using Optional Parameters in your constructor.
That way you can set by name just the properties that you have to, and leave the rest with default values until you need to change them.
Sub Notify(ByVal Company As String, Optional ByVal Office As String = "QJZ")
If Office = "QJZ" Then
Debug.WriteLine("Office not supplied -- notifying Headquarters")
Office = "Headquarters"
End If
' Code to notify headquarters or specified office.
End Sub
Remember that optional parameters must be after all non optional parameters.
Ideal practice is to have an object in a usable state as soon as the constructor returns. This reduces errors whereby a partially 'ready' object is inadvertently used.
It depends. How do you intend to use the class? What is the purpose of the class? (i.e. is it an entity class for database modeling or some other class)
I always make my entity classes with nullable properties that are all null when the class is instanced with a constructor that takes no parameter. Then when I call .Load I know all properties reflect the database.
Adding a constructor that calls .Load and assigns all of the properties known values from the database would be a feasible route also.
If you are not referring to an entity modeling class then it really depends on your usage of the class.
My personal preference is to assign all properties a known value (from constructor parameters) and therefore the class is in a known - neutral state.