|
I believe parallel programming libraries use multiple or multi-core chips. Currently, the .NET languages have multi-threading code which is not adequate for parallel programming. The Professional VS version of native C++ has a library called OpenMP to do parallel programming: http://msdn2.microsoft.com/en-us/library/tt15eb9t(VS.80).aspx[^].
"We make a living by what we get, we make a life by what we give." --Winston Churchill
|
|
|
|
|
|
I am creating a Log On page where I am trying to extract UserName and Password from a StoredProcedure. This code below is trying to return a boolean value.
But no matter what UserName and Password I enter I always get access to the FileManager.aspx file. It gives access to anybody who logson. Where should I change the code to make it work??
try
{
sqlconSource.Open();
if (sqlcmdSource.ExecuteScalar().ToString() == "0")
Response.Redirect("AccessDenied.aspx");
}
catch
{
}
finally
{
Response.Redirect("FileManager.aspx");
sqlconSource.Close();
}
}
|
|
|
|
|
Not sure what the query is in your stored procedure, but maybe this snippet from MSDN will shed some light for you...
SqlCommand.ExecuteScalar executes the query, and returns the first column of the first row in the result set returned by the query. Additional columns or rows are ignored.<br />
<br /> So, the only way you will be redirected to AccessDenied.aspx is if the first column in the first row of the results provided by your stored procedure evaluates to "0".
|
|
|
|
|
Hi everyone, i need a regular expression that can extract the name and content section from each class in a css file...
.Data1{color:#000000}
.Data2{ color:#111111
}
.Data3{
color:#222222
}
the regexp should extract :
.Data1 => color:#000000
.Data2 => color:#111111
.Data3 => color:#222222
Without the { or } chars
Ive tried but nothing seems to work....im only be able to parse .Data1{color:#000000} using this expression (\.(.+){(.+)})
Thanks in advance.
|
|
|
|
|
Allow for line breaks inside the brackets. Also you need to make your quantifiers non-greedy, or you will be cathing everything in the first match.
(\.(.+?){\s*(.+?)\s*})
If the content contains line breaks, a period doesn't match that.
(\.(.+?){\s*([\w\W]+?)\s*})
---
single minded; short sighted; long gone;
|
|
|
|
|
I found this article, it might be useful
http://www.codeproject.com/csharp/CSSParser.asp
|
|
|
|
|
Nice of you to add it to the thread, so that other might benefit. 
---
single minded; short sighted; long gone;
|
|
|
|
|
my pleasure, thanks to you.
|
|
|
|
|
How big is a bool value?
For example an int is 4byes...
Common sense tells me its just one bit, either a 0 or a 1... but id like to know for sure. Thanks ^^
|
|
|
|
|
bool is also 4 bytes
Paul
|
|
|
|
|
Oh right, thanks 
|
|
|
|
|
pmarfleet wrote: bool is also 4 bytes
No, it's one byte.
---
single minded; short sighted; long gone;
|
|
|
|
|
|
The size of a bool is one byte.
How much memory that is needed to store a bool depends on where you store it. Variables in a class or struct are generally aligned on a four byte boundary, but if you have bools that are declared next to each other, they are aligned inside the same four byte boundary.
Example:
struct A12ByteStruct {
bool test1;
int test2; bool test3;
}
struct An8ByteStruct {
bool test1;
bool test3;
int test2; }
---
single minded; short sighted; long gone;
|
|
|
|
|
Wouldn't the compiler be smart enough to recognize this and align the bools inside the same boundary?
|
|
|
|
|
One would think so, but appearently it doesn't. Perhaps it will in future versions.
---
single minded; short sighted; long gone;
|
|
|
|
|
Well, it shouldn't rearrange the fields.
|
|
|
|
|
Hmmm...I thought that in the managed world you weren't guaranteed the order in a struct. That is why most structs used for P/Invoke calls needs the [StructLayout(LayoutKind.Sequential)] attribute so it told the compiler not to rearrange the fields.
|
|
|
|
|
I concur.
The order is not specified, unless you use LayoutKind.Sequential or explicit offsets.
AFAIK the padding is also not specified.
Nevertheless there must be some mechanism to let different CLR languages work together
on the same structs. Do they all use the same conventions, or is the JIT taking into
account some available metadata ?
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
Apparently, I was only partially correct. According to the MSDN docs:The members of the object are laid out sequentially, in the order in which they appear when exported to unmanaged memory. The members are laid out according to the packing specified in StructLayoutAttribute.Pack, and can be noncontiguous.
And the docs for StuctLayoutAttribute.Pack say:This field indicates the packing size that should be used when the LayoutKind.Sequential value is specified. The value of Pack must be 0, 1, 2, 4, 8, 16, 32, 64, or 128. A value of 0 indicates that the packing alignment is set to the default for the current platform.
The default packing size is 8, except for unmanaged structures that typically have a default packing size of 4. So, it sounds like as long as the struct stays inside managed code, the fields are packed along an 8 byte boundary, but if the struct is exported to unmanaged code and has LayoutKind.Sequential set it is exported in the order in which they appear in the definition.
|
|
|
|
|
Hi Scott,
thanks for clarifying this.
On the same MSDN page it says "The common language runtime uses the Auto layout value
by default. To reduce layout-related problems associated with the Auto value, C#,
Visual Basic, and C++ compilers specify Sequential layout for value types."
So they know how to act smart, but choose not to do that by default!?
Seems to me Auto should be the default, and a warning should be given when a struct
gets P/Invoked without an explicit LayoutKind specification (so explicitly saying Auto
or Sequential or Explicit would suppress the warning).
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
Sequential is the default for structs, Auto must be the default for classes.
Confusing documentation.
|
|
|
|
|
My bad. I thought that only controlled whether or not fields were packed together.
On the other hand:
"
C#, Visual Basic. NET, and C++ compilers apply the Sequential layout value to structures by default.
"
|
|
|
|
|
PIEBALDconsult wrote: C#, Visual Basic. NET, and C++ compilers apply the Sequential layout value to structures by default.
Yes, but...according to the MSDN docs:
The members of the object are laid out sequentially, in the order in which they appear when exported to unmanaged memory. The members are laid out according to the packing specified in StructLayoutAttribute.Pack, and can be noncontiguous. And the docs for StuctLayoutAttribute.Pack say:This field indicates the packing size that should be used when the LayoutKind.Sequential value is specified. The value of Pack must be 0, 1, 2, 4, 8, 16, 32, 64, or 128. A value of 0 indicates that the packing alignment is set to the default for the current platform.
The default packing size is 8, except for unmanaged structures that typically have a default packing size of 4. So, it sounds like as long as the struct stays inside managed code, the fields are packed along an 8 byte boundary, but if the struct is exported to unmanaged code and has LayoutKind.Sequential set it is exported in the order in which they appear in the definition.
It definately seems like they could have made the explanation a lot clearer.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
