|
Maybe this creates another internalized copy for the string, if that is util or not, i can't say...
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
|
|
|
|
|
String.Copy does create a new internal copy of the string data (rather than copy the reference as a normal string assignment would).
That is precisely why the original code is so bad! It creates unnecessary copies of the string data for no obvious reason where an assignment would be faster, better for memory use, and easier to read... 
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
So the String.Copy() must be used if one wants to pass a string to a P/Invoke call? i don't get why this would be better than passing a StringBuilder...
well, i've got to far 
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
|
|
|
|
|
Gawd no! Use a StringBuilder instead! Passing an immutable object to a function known to change it is very nasty indeed (as I said earlier).
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
I understand... well, there are some things that are better to do not know for what are used...
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
|
|
|
|
|
array = new T[1];
array[array.Length - 1] = handler;
is
array[0] not allowed in c#?
|
|
|
|
|
Yes you can, but someone in a near future may say it's Hard Coded!! 
|
|
|
|
|
some might actually do. I know a person who says worlds ending soon, so lets not design!! 
|
|
|
|
|
An array with one element! Now that's thinking outside the box. 
"You get that on the big jobs."
|
|
|
|
|
I missed to recognize that.... have my vote of 5 for "eye for detail" lol 
|
|
|
|
|
Actually, that would be a very logical thing to do if the size of the array could change and the requirement was that the last element of the array be set to that particular value. If that's the case, I'd prefer the "1" to be a const int rather than hardcoded. And some comments would also be nice.
|
|
|
|
|
In my "non-productive" (read "non-coding!") time I write parodies (Weird Al is my hero!)
Why this one didn't occur to me years ago, I do not know. Recently it came to me as I needed to write something for a team lunch, and today I decided to start working up a home recording of it.
Dedicated to my code geek colleagues -- and their mothers!
Mamas, Don't Let Your Babies Grow Up to be Coders
Hope you enjoy a little fun on this 4th of July.
_______________________
Keith Chuvala
Friendswood, Texas USA
|
|
|
|
|
Common sense is not a gift it's a curse. Those of us who have it have to deal with those that don't....
Be careful which toes you step on today, they might be connected to the foot that kicks your butt tomorrow.
You can't scare me, I have children.
|
|
|
|
|
Just a moment ago..
private Visual GetChild<T>(FrameworkElement source)
{
if (source == null) return null;
var count = VisualTreeHelper.GetChildrenCount(source);
for (int i = 0; count > 0; count--)
{
var child = VisualTreeHelper.GetChild(source, i);
if (child is T)
return (Visual)child;
}
return null;
}
don't know what was in my mind!!  :facepalm:
|
|
|
|
|
Bit backwards today, are we?
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
Ew, yuck, misuse of var, how could you? 
|
|
|
|
|
In the halcyon days before SQL Databases(!) we worked on a system using ISAM databases.
We needed to develop a system for real estate agents.
They needed to be able to search for properties matching their clients criteria. (3 bedrooms, < $50,000, swimming pool etc.)
The award for thinking-outside-the-square went (I think it was his idea anyway) to Phred.
we created a column in the db which was 4096 characters long - or 32768 bits.
we created a table with an integer 'index' column containing a value from 0 to 32767, and a description
each index column's description would be something like '3 or more bedrooms', '$50,000 or less' or 'Swimming Pool' (they could be user modified)
So, to match records against criteria, each record was simply read, and a logical AND applied against the user-requirements 4096 characters and the value of the field.
This stable scan was written in Assembler (this task was given to me- meaning I had to learn assembler overnight!) for speed - and boy, was it fast!
In the days when any real estate agent would have had to run an overnight report to get that sort of information, we could do it in real time, while the agent sat with the buyer.
|
|
|
|
|
Back in the days when a PC was 2 floppy disks we used an app called askSam that sounds similar to ISAM. We used it for media research. I was so intrigued I ended up becoming a programmer and eventually leaving the media research industry.
There is an elegance to those KISS solutions that programming today doesn't normally appreciate.
"You get that on the big jobs."
|
|
|
|
|
2 floppy disks?! You were lucky!
ISAM is Indexed Sequential Access Method - essentially a way to specify fields on sequential files as indexes, and methods to retrieve those records based on those indexes.
I never heard of AskSam before - but that sounds like a specific tool, rather than a methodology.
It's interesting, though, how something like that can steer your entire career!
|
|
|
|
|
_Maxxx_ wrote: < $50,000
50K? Just how old are you max?
|
|
|
|
|
My first house was bought in the UK and cost me 17,000 sterling as I recall.
and no, it wasn't wattle and daub, or a dug-out cave. it was a pleasant terraced house close to the sea front in sunny Worthing *
* anyone who knows worthing will try to tell you it is not only not sunny, but also inhabited generally by the elderly, smells of seaweed, has some of the most stoney beaches on the English coast, and is generally the place people go to to live out their remaining years. This is true, and goes a long way toward explaining the cost of housing there.
|
|
|
|
|
We manage an application that searches an internal database. It's slow... takes about 3+ seconds to search. The reason is that there are tons of records and our search query is basically this:
SELECT * FROM SomeTable WHERE Field LIKE '%Something%'
That "LIKE" (with the initial "%") prevents SQL from using indexes for that field (which leads to a full table scan, meaning hundreds of thousands of records must be loaded). To fix that, I have the brilliant idea to create a new table and split the field across 72 columns (the current max length of the field). Each column would store the field with one less leading character than the previous column. The new query would look something like this:
SELECT * FROM SomeNewTable WHERE Field1 LIKE 'Something%' OR Field2 LIKE 'Something%' ... OR Field72 LIKE 'Something%'
That's a lot of data, but SQL Server 2005 has a limit of 200+ indexes on any table, so I figure fair trade. However, after showing this to my boss, he comes up with the idea to instead store a new column per word in the search string rather than per character. So we might only have 8 columns instead of 72:
SELECT * FROM SomeNewTable WHERE Field1 LIKE 'Something%' OR Field2 LIKE 'Something%' ... OR Field8 LIKE 'Something%'
I thought that sounded pretty good, except I thought then auto-complete wouldn't work until a full word was typed. However, thinking about it some more, auto-complete will work, considering people typically type words starting with the first letter (e.g., people will generally type "something" starting with "some" rather than starting with "thing").
My boss just prevented me from creating a horrific table. He's a genius.
Now I just need to consider a few niggling options: different tables for clustered indexes, a single column with each word rather than split-up columns, combinations of sequential words, and SQL Server full text indexing (not even sure if that would apply to this situation, but I'll soon see). Seems I have some design and experimenting ahead of me.
|
|
|
|
|
Thinking about this some more, I think I'm going to choose a combination of the above ideas. So the search query will be:
SELECT * FROM SomeNewTable WHERE Field LIKE 'Something%'
However, instead of containing 1 record for "ABC", it will contain 3 records ("ABC", "BC", and "C"). That's potentially a lot of data. However, since the max length is known to be 72 characters, it's not really a big deal. Fast and simple.
|
|
|
|
|
Assuming you're talking real words in that field, rather than some codification, then I would think looking at full text indexing might be worth a shot.
|
|
|
|
|
It was a bit of a simplification. Some are real words, some are codes (without spaces), and often people will type "word1 word2" expecting a result that contains those words in that order. And there are some special characters that they may or may not type in, so I'll probably also have alternate versions without those characters they can search too. I'll probably take the custom approach rather than the full text indexing, as I'm not sure it would be able to handle the fringe scenarios we want to support.
But yeah. Sure am glad I didn't resort to a table with 72 columns (or worse, 72 tables).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
