I have a uint8_t variable for example '01:2.7:300:4'. It comes in on an Arduino acting as a transceiver.
I want to parse the variable by the colon (:) using strtok(). However, the first argument of strtok is required to be a char*.
Is there a way to convert the uint8_t variable to a char? or is there another way to parse the input?
I searched google for the last few hours but have been unable to find a solution.
Thank you
Although it's a bit ugly, you can simply cast the uint8_t* to a char* and strtok will work fine (at least, on all normal platforms, including Arduino):
Related
Has anyone built a "universal" string class for C++Builder that manages all of the conversions to/from ASCII and Unicode?
I had a vision of a class that would accept AnsiString, UnicodeString, WideString, char*, wchar_t*, std::string, and variant values, and would provide any of those back out. AND the copy constructor has to do a deep copy, not just provide a pointer to the same buffer space (as AnsiString and UnicodeString do).
I figure someone else besides me must have to pass strings to both old interfaces that use char* and new ones that use (wide) strings. If you have built, or know of, something you're willing to share, please let me know. Most of the time it's not too big a deal, until I have to pass a map<std::string, std::string>, then it starts getting ugly.
We do not, and will not, support any internationalization whatsoever, so I don't need to worry about encoding. I just want a class that will return my little ASCII strings in whatever format makes the compiler happy... sanely.
UPDATE: to address the comments:
So, std::map<std::string, std::string> is ugly, because you can't do:
parammap[AnsiString(widekey).c_str()] = AnsiString(widevalue).c_str();
Oh no no no. You have to do this:
AnsiString akey = widekey;
AnsiString aval = widevalue;
parammap[akey.c_str()] = aval.c_str();
The person who originally wrote this code tried to keep it as port-friendly as possible, so he standardized on char* for all of the function calls he wrote (circa 2000, it wasn't a bad assumption). Sometimes I was trying to convert everything to char *s before I realized that the function was then immediately turning around and converting it back to wide. There are multiple interface layers, and it took me a while to figure out how it all went together.
Add in some creative compiler bugs, where it would get confused, especially when pulling string values out of Variants. In some places, I had to do:
String wstr = passedvariant.AsType(varString);
String astr = wstr;
std::string key = astr.c_str();
Then life happened, we ended up starting the port over (for the 3rd time. Don't ask), and I finally got smart and wrapped the low-level library in a layer that does all of the conversions, and retooled the middle layers to deal in Strings, so the application layer can just use String except for that map. For the map<string, string>, I created a function to do the converting, so it was one line in a bunch of places instead of six (the three line conversion above for both key and value).
Lastly, I wasn't actually asking for anyone to make suggestions on how to make my code better. I was asking if anyone had or knew of a universal string class. Our code is the way it is for reasons, and I'm not rewriting all of it to make it prettier. I just wanted not to have to touch so many lines... again. It would have been so much nicer to have the compiler keep track of which format is needed and convert it.
For an app, I need a 64bit unsigned int. Looking at dart documentation I did not see how to exactly go about declaring one.
Can anyone tell me how this is done? I will use this "64bit unsigned int" in bitwise operation.
Dart does not have a native unsigned 64-bit integer.
For many operations, you can just use the signed 64-bit integer that an int is, and interpret it as unsigned. It's the same bits. That won't work with division, though. (And if it's for the web, then an int is a JavaScript number, and you need to do something completely different).
The simplest general approach is to use a BigInt and use toUnsigned(64) after you do any operations on it.
Just use fixnum
You can easily create an int64 with Int64()
Given this C string:
unsigned char *temp = (unsigned char *)[#"Hey, I am some usual CString" UTF8String]
How can I replace "usual" with "other" to get: "Hey, I am some other CString".
I cannot use NSString functions (replaceCharactersInRange/replaceOccurencesOfString, etc.) for performance reasons. I have to keep it all at low level, since the strings I'll be dealing with happen to exceed 5MB, and therefore the replacements (there will be a lot of replacements to do) take about 10 minutes on a iOS device.
Objective-C is a just thin layer over C.
If you need to work with native C strings, just go ahead and do it.
This
What is the function to replace string in C?
seems to address your problem fairly well.
The C string returned by UTF8String is const. You can't safely change it by casting it to a non-const string and mutate the bytes. So the only way to do this is by creating a copy.
If you really have reason to use an NSString as the source it might be much faster to do the transformation on the original string.
If you want to get a better answer that helps you to speed up your special case you should provide some more information. How do you create the original string, what's the number and size of search/replacement strings and so on.
Does it make a difference which one I use in objective-c (particularly on iOS)? I assume it comes from inheriting from C and its types, as well as inheriting the types from Mac OS, which iOS was based on, but I don't know which one I should use:
unsigned char from...well..the compiler?
uint8_t from stdint.h
UInt8 from MacTypes.h
Byte from MacTypes.h
Bytef from zconf.h
I am aware that the various defs are for portability reasons, and using literals like unsigned char is not good future thinking (size might change, and things will end up like the Windows API again). I'd like some advice on how to spot the best ones for my uses. Or a good tongue lashing if I'm just being silly...
EDIT : Just for some more info, if I want something that will always be 1 byte, should I use uint8_t (doesn't seem like it would change with a name like that)? I'd like to think UInt8 wouldn't change either but I see that the definition of UInt32 varies on whether or not the processor is 64-bit.
FURTHER EDIT : When I say byte, I specifically mean that I want 8 bits. I am doing pixel compression operations (32 bits -> 8 bits) for disk storage.
It's totally indifferent. Whichever you use, it will most probably end up being an unsigned char. If you want it to look nice, though, I suggest you use uint8_t from <stdint.h>.
Neither will change with the architecture. char is always 1 byte as per the C standard, and it would be insupportable from a user's point of view if in an implementation, UInt8 suddenly became 16 bits long.
(It is not the case, however, that char is required to be 8 bits wide, it's only that if the name of a type suggest that it's 8 bits long, then any sensible implementation does indeed typedefs it as such. Incidentally, a byte (which char is) is often an 8-bit unit, i. e. an octet.)
As in every programming language derived from C-language type model, Objective C has a handful of equivalent options to declare a 8-bit integer.
Why did I say equivalent? Because as OP correctly stated, it's obvious that all of those options eventually typedef-ed to unsigned char built-in compiler type. This is correct for now and, let's speak practically, nobody sane will change them to be a non-8-bit integers in the future.
So, the actual question here is what is the better order to prioritize considerations when choosing the type name for 8-bit integer?
Code readability
Since basically in every code having C language roots, primitive type names are a mess. Therefore, probably the most important factor is readability. And by that I mean clear and uniquely identifiable intent of choosing this specific type for this specific integer for the majority of people who would read your code.
So let's take look at those types from an average Objective C programmer point of view who knows little about C language.
unsigned char - what's this??? why char is ever meant to be signed???
uint8_t - ok, unsigned 8 bit integer
UInt8 - hmm, the same as above
Byte - signed or unsigned 8 bit integer
Bytef - what's this? byte-float? what does that 'f' mean?
It's obvious here that unsigned char and Bytef aren't a good choices.
Going further, you can notice another nuisance with Byte type name: you can't say for sure if it represents signed or unsigned integer which could be extremely important when you're trying to understand what is the range of values this integer could hold (-128 .. 127 or 0 .. 256). This is not adding points to code readability, too.
Uniform code style
We're now left with the 2 type names: uint8_t and UInt8. How to choose between them?
Again, looking at them through the eyes of an Objective C programmer, who is using type names like NSInteger, NSUInteger a lot, it looks like much natural when he sees UInt8. uint8_t just looks like a very low-level daunting stuff.
Conclusion
Thus, we eventually are left with the single option - UInt8. Which is clearly identifiable in terms of number of bits, range and looks accustomed. So it's probably the best choice here.
i am coding opera recovery tool in my delphi
i am using c++ which is already exist
http://pastebin.com/ViPf0yn6
but i didnt get whats DES_KEY_SZ in that code .
i think they are present in des.h ,but i couldnt found same des.pas :(
can any one help me please
regards
Here we go: http://freebsd.active-venture.com/FreeBSD-srctree/newsrc/crypto/des/des.h.html
Apparently,
#define DES_KEY_SZ (sizeof(des_cblock))
where
typedef unsigned char des_cblock[8];
I am not a C programmer, but I think that this means that DES_KEY_SZ has the value 8.
Google Code Search finds many copies of des.h, where the DES_KEY_SZ macro is defined. It's the size of a des_cblock, which happens to be an array of eight unsigned chars.
In other words, DES_KEY_SZ = 8.
You're going to run into other problems beyond just that missing identifier, though. The code you showed calls a handful of DES functions, too. To unencrypt the data, try using DCPCrypt.