I am developing iOS application and I need base_convert function. Application is communicating with PHP server using base_convert, too. In PHP I use this:
base_convert($something,16,36) and base_convert($something,36,16)
I search for something like I use in PHP, but for Xcode (iOS application).
Thank you.
there is a C++ implementation here:
http://thinkdiff.net/mixed/base-conversion-handle-upto-36-bases/
that will convert back and forth with bases up to 36. Not sure if you need more than that.
There is a complete wikepedia page devoted to Base 36 with various forms of source code that you could adapt (for example the C code should just drop straight in with no modification but is soooo not objective-c)
There is also how to convert Decimal to base36 which only does a one-way conversion, but the code is objective-c, so you could get an idea on how to adapt the wikepedia code.
As to why base 36 I learnt:
Base 36 is therefore the most compact case-insensitive alphanumeric
numeral system using ASCII characters
Adapted the code David Hope suggested into Objective-C, here:
https://gist.github.com/furkanmustafa/5660086
Related
I've been researching this topic for a few weeks now, but I'm still unsure as to what is the "best" way to approach this problem.
I am designing an app, and part of the input involves entering an equation (ie mathematical function). I'm not looking for anything super complicated; it's single-variable, at least for now.
What is the best way to approach entry and parsing? Is there a parser that is very good for this? What about a graphical approach such as dragging/selecting parts and assembling a function by its components?
Thanks.
You should be able to use regular expressions to parse it out.
Check out NSRegularExpression and Google around for a regex that will parse out the equation into its different parts.
If you want to make your application extensible (for the future) you should read something about parser theory. There is a simple example on wikipedia (here) from which you can start. It uses flex (to generate the lexer) and bison (to generate the parser) which can be easily integrated with Objective-C code.
If that example is more than expected you can start with a more simple one from the bison manual (here).
you can use mathml products like mathtype and maths magic.
for other products see this
If you want to use javascript for formatting that use jqmath
I have the following question:
Let's assume I have many different C++ libraries(algorithms), which are written in the same style . (They need some inputs and give back some outputs).
I've done some research and wanted to ask if its possible to auto-generate Wrapper classes (by using an algorithm which are given the input and the outputs of the c++ algorithm), which can be easily used in Objective-C/Java (iOS/Android) then .
The app-programming part isn't really time-consuming.
You'll want to look at SWIG. This generates bindings for other languages from a C based API. Objective-C support is in there as is Java.
I'm not sure what happened to objective-C support in the later versions, but its in v1.1 and you can see the branch where it was added.
I'm just thinking of porting some old C++ sources held in my archive to iOS thus supplying a ObjC GUI, using wrappers for some C++ stuff and leave the important data working stuff within the C++ code. So, the problem is that the old sources come from Win32 MFC thus using CString class for strings and I want to replace that with Joe O'Leary's CStdString which is a C++ template class that will do it just fine ... but:
I have to use the string class definition along with a big bunch of different C++ sources and so each of them will include the CStdString template on their own. Normally I would write a wrapper for the whole string class, but better if I needn't.
Will I have a problem with instantiation of strings in the different sources? Could it make a problem to pass a templated string from one source to another? In fact I don't know if the compiler generates the code for a template only once or multiple times having the fact that the same instantiation type is used for the template.
Can you fill some light into this?
Thanks...
MFC and CString may only work properly on Windows OS so they aren't good candidates to be putting in any kind of library that will be potentially used by a platform other than windows.
I'm not familiar with Joe O'Leary's CStdString classes but I'd recommend using std::string as much as possible and char* with "extern C" exports and wrapping functions for use outside of C++ land as the c-style string is more easily compatible with other languages that may need to call into your C++ library.
As far as templates all the variations are generated at compile time and then the correct implementation is chosen at run time as far as I know. However your problem will most likely be in translation from one kind of string to another which may require you to create some middle layer or wrapper to marshal from string type of one language to another.
I agree with CString, as long as you stay with std::string or some other multi-platform string implementation for C++ you are not going to face any issues ( even boost works on iOS ).
I've been integrating C++/Obj-C for about two years now so you can be sure that keeping model classes in C++ ( even with heavily templated code ), is not a problem. I would advice you to do what you could do best with Obj-C in Obj-C though... ( avoiding being a hammer developer :) )
Good luck!
Does anyone know of any examples of code written in prolog to implement a DSL to generate perl code?
DCGs might be an excellent choice!
I have used a similar approach for generation of UML class diagrams (really, graphviz code for such diagrams) from simple English sentences (shameless-plug: paper here). It should be possible to do something similar with generation of Perl code instead.
In the paper above, we use a constraint store (CHR) as intermediate representation which allows some extra reasoning power. Alternatively you can build a representation as an output feature/argument of the DCG.
Note that DCGs can be useful both for the parsing of your sentences and the generation of your Perl code.
Well, not exactly what you are asking for, but maybe you can use AI::Prolog for what you are looking for. That way you may be able to use Perl and generate the Perl code you want.
I'm not sure why you would want to do that?
Perl is a very expressive language, I'm not sure why you'd want to try to generate Perl code from Prolog; in order to make it useful, you'd be getting closer and closer to Perl in your "DSL", by which point you'd be better off just writing some Perl, surely?
I think you need to expand this question a bit to cover what you're trying to achieve in a little more detail.
SWI-Prolog library(http/html_write) library builds on DCG a DSL for page layout.
It shows a well tought model for integrating Prolog and HTML, but doesn't attempt to cover the entire problem. The 'residual logic' on the client side remains underspecified, but this is reasonable, being oriented on practical issues 'reporting' from RDF.
Thus the 'small detail' client interaction logic is handled in a 'black box' fashion, and such demanded to YUI components in the published application (the award winner Cliopatria).
The library it's extensible, but being very detailed, I guess for your task you should eventually reuse just the ideas behind.
I have a range of Win32 VCL applications developed with C++Builder from BCB5 onwards, and want to port them to ECB2009 or whatever it's now called.
Some of my applications use the old TNT/TMS unicode components, so I have a good mix of AnsiStrings and WideStrings throughout the code. The new version introduces UnicodeString, and a bunch of #defines that change the way functions like c_str behave.
I want to modify my code in a way that is as backwards-compatible as possible, so that the same code base can still be compiled and run (in a non-unicode fashion) on BCB2007 if necessary.
Particular areas of concern are:
Passing strings to/from Win32 API
functions
Interop with TXMLDocument
'Raw' strings used for RS232 comms, etc.
Rather than knife-and-fork the changes, I'm looking for guidelines that I can apply to ease the migration, while keeping backwards compatibility wherever possible.
If no such guidelines already exist, maybe we can formulate some here?
The biggest issue is compatibility for C++Builder 2009 and previous versions, the Unicode differences are some, but the project configuration files have changed as well. From the discussions I've been following on the CodeGear forums, there are not a whole lot of choices in the matter.
I think the first place to start, if you have not done so, is the C++Builder 2009 release notes.
The biggest thing seen has been the TCHAR mapping (to wchar or char); using the STL string varieties may be a help, since they shouldn't be very different between the two versions. The mapping existed in C++Builder 2007 as well (with the tchar header).
For any code that does not need to be explicitally Ansi or explitically Unicode, you should consider using the System::String, System::Char, and System::PChar typedefs as much as possible. That will help ease a lot of migration, and they work in previous versions.
When passing a System::String to an API function, you have to take into account the new "TCHAR maps to" setting in the Project options. If you try to pass AnsiString::c_str() when "TCHAR maps to" is set to "wchar_t", or UnicodeString::c_str() when "TCHAR maps to" is set to "char", you will have to perform appropriate typecasts. If you have "TCHAR maps to" set to "wchar_t". Technically, UnicodeString::t_str() does the same thing as TCHAR does in the API, however t_str() can be very dangerous if you misuse it (when "TCHAR maps to" is set to "char", t_str() transforms the UnicodeString's internal data to Ansi).
For "raw" strings, you can use the new RawByteString type (though I do not recommend it), or TBytes instead (which is an array of bytes - recommended). You should not be using Ansi/Wide/UnicodeString for non-character data to begin with. Most people used AnsiString as makeshift data buffers in past versions. Do not do that anymore. This is particularly important because AnsiString is now codepage-aware, and thus your data might get converted to other codepages when you least expect it.