#pragma region INFO
/*
* # FUNCTION: GetSubStrBetween
*
* # PARAMETER(s):
* [1st] std::string &in_Str = This paramter takes in a std::string, which
* is the string that contains the unknown sub-string.
*
* [2nd] std::string in_A = This parameter takes in a std::string, which
* will be the beginning point of the unknown sub-string.
*
* [3rd] std::string in_B = This parameter takes in a std::string, which
* happens to be the ending point of the unknown sub-string.
*
* [4th] std::string in_out_SubStr = This parameter takes in a std::string,
* which will contain the unknown sub-string.
*
* [5th] bool in_opt_Append = This optional* parameter takes in either a true
* or false value. If in_opt_Append = true, in_out_SubStr (see 4th
* param.) will append the unknown sub-str. Else, in_out_SubStr will be
* equal to the unknown sub-str. Note: The default value is false.
*
* # RETURN VALUE(s):
* false = This function returns a false value because...
* - The length of in_Str/in_A/in_B is equal to 0.
* - The length of in_A/in_B is greater than or equal to the length
* of in_Str.
* - The length of in_Str is smaller than length of in_A + the length
* of in_B.
* - Unable to find in_A/in_B.
* true = Successfully found and return the unknown sub-str to in_out_SubStr.
*/
#pragma endregion INFO
It's clean and seems like very useful format.
#pragma region <region_name>
#pragma endregion <region_comment>
is simply the collapsible region stuff in Visual Studio, allowing you to collapse or expand blocks when looking at your source in outline mode.
The text inside it is largely irrelevant to Visual Studio and doesn't match the usual suspects like Doxygen, Ghost Doc or the built-in Visual Studio stuff.
Failing notification from the author of that code (unfortunately, they haven't been seen here since May 2013), you may just have to accept they were fastidious about their comments, unless someone comes along who knows the format off the top of their head.
Related
I have successfully connected to my database, but when I select 2 cells from my SQL db to set the value for both of my variables it does nothing. I have no problem inserting data into the database. I have tried different approaches to this with no success. Could it be that I am trying to use a string format for doubles??
double userHeight;
double userWeight;
QSqlQuery query;
QString retreiveUserHeight =
QString("SELECT Height, Weight FROM SQL1 WHERE Username='joejoe'");
query.prepare(retreiveUserHeight);
query.bindValue(0,"Height");
query.bindValue(1, "Weight");
query.exec();
userHeight = query.value(0).toInt();
userWeight = query.value(1).toInt();
I'm pretty certain there is a small error in syntax that is causing this mishap but I have been unable to find it. Thanks for your help.
qDebug() << "calculated" << 703*(userWeight/(userHeight*userHeight))
<< userWeight << userHeight ;
Heres the debug output:
calculated nan 0 0
// Obtain username from somewhere
QString username = "joejoe";
// Check whether DB is open
if( db->isOpen( ) )
{
QSqlQuery query;
double userHeight;
double userWeight;
// Prepare select statement
query.prepare ( "SELECT Height , Weight FROM SQL1 WHERE Username = :username" );
query.bindValue ( ":username" , username );
query.exec ( );
// Check if something went wrong when executing your query
if( query.lastError( ).text( ).trimmed( ) == "" )
{
// Loop through all results and handle them accordingly
while( query.next( ) )
{
userHeight = query.value( 0 ).toDouble( );
userWeight = query.value( 1 ).toDouble( );
qDebug( ) << "calculated" << 703 * ( userWeight / ( userHeight * userHeight ) ) << userWeight << userHeight;
qDebug( ) << "---------------------------------";
}
}
else
{
// Display the error that occured
QMessageBox::critical( this , tr( "SQL Error" ) , query.lastError( ).text( ) );
}
}
I assume this is what you wanted it to look like.
I've included some error checking and corrected your query to use .bindValue( ) correctly, since it's not meant for using for return values rather than for input as seen in the WHERE.
Since I don't know anything about your sql table I've included a loop to go through all results of your query. That can obviously be changed.
Apart from that if you're using doubles you should cast the result .toDouble( ) rather than .toInt( )
There are a number of serious problems with this code. Let's start with the concept of prepared SQL queries. Wikipedia lists two reasons for using prepared statements:
The overhead of compiling and optimizing the statement is incurred
only once, although the statement is executed multiple times. [...]
Prepared statements are resilient against SQL injection, because
parameter values, which are transmitted later using a different
protocol, need not be correctly escaped.
Neither of these reasons apply in your code; you're only executing the query once, and you're not splicing any inputs into the string. In fact, the only input in your query at all is the username, which is hard-coded to "joejoe":
"SELECT Height, Weight FROM SQL1 WHERE Username='joejoe'"
Since there are no variable inputs, using a prepared query doesn't make much sense. Neither do the following lines:
query.bindValue(0,"Height");
query.bindValue(1, "Weight");
Height and Weight are outputs from this query, not inputs. See the section in the Qt docs for QSqlQuery titled "Approaches to Binding Values" for an explanation of how this is intended to work. Qt's API for binding prepared SQL queries is fairly typical among database libraries, there's nothing earth shattering here.
Then we get to this:
userHeight = query.value(0).toInt();
userWeight = query.value(1).toInt();
Both the variables you're reading into here were declared as doubles, but you're calling toInt() on the returned QVariant rather than toDouble(). I don't know what (if any!) values are in your database, but it's possible they're getting rounded down to zero during the conversion from double to int if the values are between -1.0 and 1.0.
That said, you aren't doing any error checking whatsoever. The methods prepare() and exec() return bools that indicate whether they succeeded or failed. Likewise, both toInt() and toDouble() tell you whether they've succeeded or failed if you pass in a pointer to a bool. It's worth noting that both methods also return a zero value on failure.
I'm working on MVC Web API with Dapper version 1.38.0.0. I write this code
var param = new Dapper.DynamicParameters();
foreach (Match match in Regex.Matches("Select Top #count * From tblCourse", #"(?<!\w)#\w+"))
{
string key = match.Value;
string value = HttpContext.Current.Request.QueryString[key.Replace("#", null)];
param.Add(key, value);
}
result = con.Query<dynamic>("Select Top #count * From tblCourse", param);
But I have an error on result's row.
Additional information: Incorrect syntax near '#count'.
How can i solve this problem? Thanks.
TOP #param
Is not legal in SQL server. 2 options:
Select Top (#count) * From tblCourse
Or
Select Top {=count} * From tblCourse
The first is SQL-server's way of representing this. The second is a dapper-specific feature that injects integer values (only: it doesn't work for strings) directly into the query. If the value is usually the same, the second will usually perform better. Of course, with the second you'd need a different regex too.
Try this
result = con.Query<dynamic>("Select Top (#count) * From tblCourse", param);
Top needs to be inside parenthesis when it's value is supplied via a parameter
I am having an issue with a derived column calculation in SSIS not returning the correct values. To give some background, I had to change the format of my calculation due to an overflow issue (resolved), see here - SSIS - Derived Column Calculation Error
Now, the old and new calculations return different values in SSIS, even though they are both mathematically the same and return the same value when executed in .net, excel and SQL.
In .Net -
decimal test1 = Convert.ToDecimal((415 * 415 * 415) * 0.000000030940000);
decimal test2 = Convert.ToDecimal((0.000000030940000 * 415 * 415 * 415));
both return 2.2113862225
In SSIS -
test1 = ((415 * 415 * 415) * 0.000000030940000)
test2 = (0.000000030940000 * 415 * 415 * 415)
return different values (test1 = 2.2113862225 and test2 = 2.211535)
Interestingly, SSIS sees test1 as a numeric (38,6) and test2 as a numeric (27,15)....
Has anyone encountered this issue before?
I don't really want to have to re-factor the whole package to use .net calculations, however that will be my last resort solution.
In case anyone else has this problem - I didn't find the solution but did implement a workaround -
Instead of doing the calculation in a derived column -
Use the derived column component to reate the variable and set it as 0
Add a data conversion and switch it to the required data type (float in this case)
Add an OLE DB Command to call a stored procedure to do the calculation, with an output parameter filling the variable created at point 1.
I'm trying to parse a very big message (approx 25 fields) and serialize them. The fields in the message appear in the same order all the time and in the proto file I numbered them accordingly. Is there a method to set the fields with the tag value (the number in the proto file)?
Thanks,
Chem.
google::protobuf::Message myMessage;
const google::protobuf::Descriptor * myDescriptor = myMessage.GetDescriptor();
const google::protobuf::FieldDescriptor * myField = myDescriptor->FindFieldByNumber(9001);
const google::protobuf::Reflection * myReflection = myMessage.GetReflection();
myReflection->SetInt32( &myMessage, myField, 7);
Obviously you'll need to change the field number, type of the field, and value to which you want to set.
I need to find a maximum of the function:
a1^x1 * const1 + a2^x2 * const2 +....+ ak^xk * constk = qaulity
where xk>0 and xk is integer. ak is constant.
constraint:
a1^x1 * const1*func(x1) + a2^x2 * const2*func(x2) +....+ ak^xk * constk*func(xk) < Budget
Where func is a discrete function:
func(x)
{
switch(x)
{
case 1: return 423;
case 2: return 544;
...
etc
}
}
k may be big(over 1000). x less then 100.
What is the best method?
There are techniques like nelder-mead optimization (which I believe GSL implements), but most techniques assume some sort of special structure (i.e. convexity or continuity). Depending on the values of the function, there may not exist a unique optimum or even an optimum that a normal downhill method can find.