|
Pete O'Hanlon wrote: I suspect the answer lies simply with the fact that things like string or int look more like their old C/C++ counterparts than String or Int32 which look very VB.
I think it has more to do with the evolution of 'short/int/long' in C and less to due with making it look like another language. C has a tendency to keep the size of its integers in line with the common CPU register size. Some C programs are created with the assumptions that these won't change, and errors can crop up as a result of these types expanding in size. There's an article at Gamasutra about these errors (C/C++ based article, so brace for pointers and address arithmetic).
By aliasing the native type to System.Int32 (or potentially Int64 in the future), you can use 'int' for general purpose integers that fit nicely into registers where the bit size isn't relevant. Using Int16/Int32/Int64 will still give you control over the specific sizes where it might be required. A lot of C/C++ compilers have started doing something similar by creating non-standard typedefs of __int16, __int32, and __int64 to give the programmer more explicit control of their data type sizes.
Of course, as you said, this is all theory and speculation on my part.
|
|
|
|
|
As mentioned, 'String' is a class (c.f. Int32, Single). string is a C# language construct which is translated by the compiler to a suitable string class (c.f. int, float). It's extremely unlikely that it will ever translate to anything other than System.String so they are essentially equivalent. (This may not be true for some of the numeric types, int and long might not mean 32 and 64 bit forever.)
|
|
|
|
|
BobJanova wrote: int and long might not mean 32 and 64 bit forever I think this statement is incorrect. Int32 is always 32-bit irrespective of the size of the underlying platform's native integer type (that's why the name itself has the size - Int32). The same holds good for Int64.
|
|
|
|
|
Int32 is always 32, yes. But does the C# language construct 'int' always map to Int32? Let me rephrase that: is it guaranteed that that will always be the case? I thought that it was not (i.e. in some future machine configuration 'int' will mean Int64 and 'long' will mean Int128).
|
|
|
|
|
BobJanova wrote: I thought that it was not (i.e. in some future machine configuration 'int' will
mean Int64 and 'long' will mean Int128).
That is true of C, and it's a very bad idea, C# straightened that out.
|
|
|
|
|
BobJanova wrote: in some future machine configuration 'int' will mean Int64 and 'long' will mean Int128 Wouldn't that break existing apps that use int ? I am highly doubtful of such a situation. And by the time 64-bit becomes the de facto architecture, Microsoft would come up with some breathtaking new technology that would replace .NET
|
|
|
|
|
arkiboys wrote: I have read on the web that there is no difference.
..and what does the manual on MSDN state?
Bastard Programmer from Hell
|
|
|
|
|
Since Intellisense on instances of both 'String and 'string show the same underlying exposed properties and methods, and since the pop-up showing the constructor overloads for both shows the same parameter options, and since comparison of their 'Type, via GetType(), shows equality: ergo, I conclude they are the same, hence having both usages is meant for some semantic purpose.
My hypothesis for what that purpose might have been would be that code written where 'string is used to indicate the creation of instances of type 'String, and 'String is used to indicate accessing the static methods exposed by the 'String class ... might be clearer.
But that's just a guess, and it would be interesting to know what the language designers intended.
best, Bill
"In the River of Delights, Panic has not failed me." Jorge Luis Borges
|
|
|
|
|
From the spec:
Each of the predefined types is shorthand for a system-provided type. For example, the keyword int refers to the struct System.Int32. As a matter of style, use of the keyword is favored over use of the complete system type name.<br />
Predefined value types such as int are treated specially in a few ways but are for the most part treated exactly like other structs.
For instance, when defining an enum, you can't use System.Int32, the langauge requires the alias (if specified).
and:
int 32-bit signed integral type
|
|
|
|
|
i need to create setup package that setup assistant software behind without users see it
like .net framework & sql express & report viewer
& if the same version exists doesn't setup it
this work in background without user see it
md_refay
|
|
|
|
|
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
i want to create shortcut from my application from setup package
how i do that
md_refay
|
|
|
|
|
That varies, depending on what software you're using to create the setup.
Bastard Programmer from Hell
|
|
|
|
|
Do you use Microsoft Visual Studio (which version?) for your setup project? There you could have the setup create the shortcuts: open the editor for the file system, and add a link to desktop, program menu etc.
|
|
|
|
|
Hi,
I'm trying to come up with the architecture for my new project.
It's a window form based application with a SQL Server backend.
I would like to use a multi-tiered approach with the database, a data access layer, a
business logic layer and a user interface layer.
The structure of the solution is as follows
- DAL (Class Library)
- BLL (Class Library)
- UI (Window form application)
From what I understand, the UI should not have access to the DAL (except via the BLL),
so there should be no reference to the DAL in the UI. Wright ?
I use the "TableAdapter Configuration Wizard" to generate my DAL code, which sometimes
returns typed datatables. The businesslogic layer returns those same typed datatables that
were defined in the DAL. I'm setting the data source of a gridview to that typed datatable.
This requires that the UI know something about the datatable defined in the DAL, so to make
this work I have to place a reference to the DAL in my UI layer, which I supose is not
good programming practise. How should this be done ??
|
|
|
|
|
Move the datatables to a new Class Library project and add reference to this library from your DAL and UI projects.
|
|
|
|
|
Having data classes bubble up from the DAL shouldn't be a problem; but, as Shameel said, defining them in a separate place is even better.
paper67 wrote: I use the "TableAdapter Configuration Wizard" to generate my DAL code
I prefer to roll my own and maintain control.
|
|
|
|
|
So when I intend to keep the wizards autogenerated code, referencing the DAL in the UI layer
to access the typed dataset, datatable and datarow types returned from the BLL is not so bad ??
|
|
|
|
|
As long as you access them via the BLL.
|
|
|
|
|
In addition to the other comments I would consider Enity Framework for the entities and DAL. Place the former in a seperate assembly to be references in the other layers.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Hello,
I have used this method but to return a single int value. Now I am returuing a string.
I have tried to define the local variable as a string as well as object. It just does not seem to be returning a string value.
I have tried the following different ways:
1. string name = sqlcommRights.ExecuteScalar() as string;
2. string name = (string)sqlcommRights.ExecuteScalar();
3. object name = sqlcommRights.ExecuteScalar();
I am printing the SQL statement and running in sql server, that returns a single row value like 'John Smith'.
To check value - Response.Write(name);
Am I missing something here?
|
|
|
|
|
Try;
string name = sqlcommRights.ExecuteScalar().ToString();
Though, Its a good idea to check the result isnt null before trying to access it.
Regards,
Gareth.
(FKA gareth111)
|
|
|
|
|
I'm surprised 2 & 3 don't work. The thing to do to figure out why they don't:
1. What is the error message you are getting?
2. In version 3, have you put a breakpoint on to see what value you get back - it is a good idea to check this in code even if it works on the SQL side.
|
|
|
|
|
What is the SQL code that you are calling? Is it a stored proc? If yes, did you put a SELECT statement there?
|
|
|
|
|
If everything is working when you run the query manually (sounds like you have verified this already), use method #3 and check if name is null, and if not, check name.GetType() to see what the framework thinks the type being returned from the command is.
|
|
|
|