Click here to Skip to main content
15,747,766 members
Please Sign up or sign in to vote.
1.00/5 (1 vote)
See more:
the new variable name should be the value of the string variable.

While browsing the web, i found a solution- but it was in Python. -

i also found similar question on MSDN forum: here

this is a solution that i keep coming to for a few problems i am getting, one of which is that since threads can not be restarted, i would like to have my program make a new thread, and use that, then dispose, this would save me from having to create lots of threads and hope that it is enough. another time this possibility cam up was for a SQL Query, i realised i was Passing a Parameter (the query) to the same block of code on multiple modules, but this was required because it would have to pipe the sql data to different variables, i realised i could use a IF or Select statement to achieve this, however that would be more coding and harder to update as new modules are added.

essentially what i want to do is say:
dim variablename as string = "ThreadNumber"

dim variablenumber as integer = 0

dim ([variablename.value] & [variablenumber .value]) as new thread (addressof functionSQLQuery)

variablenumber = variablenumber + 1

if i could do this, i would not even need to use intergers if that would be a problem, i could create a variaty of string name variables.

remember, there is two questions here

1. could i use string variables as names for variables (will already be declared in a shared module somewhere else)

2. could i use string/integer variables for names for new threads

any help would be greatly appreciated. cheers
Sergey Alexandrovich Kryukov 12-Mar-14 16:23pm    
You language? Platform? (Yes, some Microsoft's, but...)
Are you talking about .NET languages it makes no sense at all.

From your description, I'd suggest to use a different way of thought. The problem to be solved is that you need to access a thread object by some "identifier". So you need to add both the identifier and the corresponding thread object into a container object, such that you can retrieve the thread by its name. A Dictionary<string, Thread> could do so.
You may define a member variable in your class:
Dictionary<string, Thread> MyThreads = new Dictionary<string, Thread>();
and later on add your new threads to it:
string threadName = ...;
Thread theThread = ...;
MyThreads.Add(threadName, theThread);
When you need to access a specific thread, use
string nameOfThread = ...;
Thread aThread = MyThreads[nameOfThread]
Share this answer
Please see my comment to the question. The question, as it is, makes no sense at all. But perhaps it would make some marginal sense if you clarify things. I doubt, though.
I was the question on MSDN forum you referenced. That question certainly makes no sense.

The author of this question forgets that we are talking about language based on compilation, not interpretive. Please see:[^],[^].

Skipping long explanations of languages and their paradigms, you are trying to break through the major paradigm of mainstream types of languages, mentally. I cannot lead you anywhere. The main problem is: if you clearly described your ultimate goals, you could get some advise withing the .NET paradigm and the paradigm of compiled, strongly typed languages.

In addition to that, you probably misuse the term "variable". All you are talking about could be conceptually applied to types, to members of these types, but not to "variables". In CLI, this term is reduced to the notion of stack variable only (local variables). Unlike types and members, which really have names and are represented by some object during runtime (accessible through reflection), local variable do not even exist; they exist only in source code and converted to some IL code and later to some native CPU-level addressing during JIT compilation. The names of variables already disappear at the stage of compilation to IL. They virtually do not exist.

Even if you agree to consider only types and their member, which really have names, you should remember that they are statically known at the moment of compilation and cannot be changed. But, at best, you can dynamically create an assembly during runtime using System.Reflection.Emit, or create such assembly using CodeDOM, or, create some assembly in any way and load it dynamically during design time. Remember: the whole assembly. Besides, you cannot unload loaded assembly. To unload it, you would creates a whole separate Application Domain, load an assembly in it, work with it through the domain boundary (which means using IPC), and, eventually, unload the whole domain. If you really want to consider one of those technologies, read on them; the documentation is readily available. Remember that using System.Reflection.Emit will require good understanding of IL and hard to debug. If you have questions on either of those technologies, I'll answer.

You might be interested to read on related topics:[^],[^],[^],[^],[^],[^],[^].

However, I suspect that you would be trying to kill an ant by a ballistic inter-continental rocket. The problems you mentioned so far are much, much simper than what we discussed so far. "Threads can not be restarted"? Nonsense. Threads can easily be reused. You just should use some thread during all the lifetime of the application, by looping it, never terminated. This is not easy, this is very easy. And so on…

Anyway, you can really step back and stop describing fantastic features you seem to "want". You need to explain your ultimate goal. Not what you explained so far. Ultimate.

Share this answer

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900