Ecere SDK/eC Forums http://ecere.com/forums/ Print view |
|
Strings in eC http://ecere.com/forums/viewtopic.php?f=1&t=68 |
Page 1 of 1 |
Author: | fedor_bel [ Sat Apr 03, 2010 2:10 pm ] |
Post subject: | Strings in eC |
Dear Jerome, Thank you very much for your explanations. I know the question I asked was hard to answer, but the sum up you gave was pretty clear. Now I have to learn to live (i.e. to program) with this new reality. It is new to me, because in the recent years I have been mainly a Java programmer and almost totally forgot the memory handling habits and rules of thumb from my young c/c++ programming childhood (probably i never had none good of them anyways ![]() I was a pretty bad c/c++ programmer, spending days searching for memory leaks in my programs and long hours thinking on how to write my code so that i dont have to search for memory leaks afterwards instead of focusing on the problem domain. Java relieved me of that burden and I could just program, program, program, focusing on the task to solve. Now I find myself again tinkering more with the memory than object oriented thinking on the main problem. That is why I opened this thread. I want to learn to handle memory your way or the ecere way, if there is one. I studied the samples and they look beautiful: simple, effective. When I compare my code with the samples - my code looks awfully heavy and completely different in style and I dont like it. Maybe it is because I am still thinking the Java way and it does not pass to ecere, which offers a slightly different, maybe better style, which I still can not figure out, grasp it for use in my programs. For example: 1. I totally miss the String class from Java and I am very astonished that such an important and the most, most, most used class is not yet implemented in ecere. After some thinking and looking through samples I have got an idea that maybe there are reasons for that? My suspision is that, when programming ecere way, there really is not much need for it? Direct access to char buffer, some string handling functions and memory handling rules of thumb - are all a good ecere programmer needs? When it is totally clear with the char* access and string handling functions, the memory handling rules cause a problem for me - because I lack them and have to reinvent the wheel every time, instead of learning. For example: 1.1 when some function returns a string (a char* ) - the string should be allocated on the heap - how to make sure it is freed when it is no longer needed. 1.2 I really hate to use char [] arrays of fixed length - you never know what size of string may pass through it, it is not safe to assume that no buffer overflow will occur. that is why it is a bit akward to use the "c" string functions, because almost none of them will increase the buffer size if needed. I feel really nervous at this point, remembering the long hours I spent tinkering with the simplest string handling and comparing that with the lightning fast and baby-easy use of strings in Java. I think I will stop now. It should be enough to begin with. Sorry for the long and wheening question. Just used my chance to complain :=) Cheers, Fedor |
Author: | jerome [ Sat Apr 03, 2010 7:14 pm ] |
Post subject: | Re: Strings in eC |
The short answer to 'Where is the eC string class?' is 'Somewhere in the future'. We just haven't gotten there yet. eC having been developed to provide a better framework to organize the Ecere SDK API, which originally was in C, it was not a part of the original goals. However we do realize how important a String class is in making the language accessible for non-C programmers, and there are a lot of advantages for long time C programmers as well to using a String class, such as the prevention of buffer overflows that you brought up. One of the reasons it takes so long to get around to it is that, 1, there is a LOT of outstanding things to do and time is (very) limited, 2, we want to have a String solution that at the same time keeps the compatibility and fits in nicely with the C string and char buffers, while adding the safety and ease of use of easier languages. Sort of the perfect solution. We're still thinking it through in the back of our mind, you can take a look at some very rough draft of ideas for the String class here. You can find the 'SuperString' class at the end of that wiki entry there. You can also take a look at joeyadams's take at making a string class. One day I will sit down and implement that perfect String class. In fact, it would sort of have to be a special eC datatype, hence the added difficulty. One thing you can use for a string class is an Array<char>, a generic dynamic array container. You can set the 'minAllocSize' property to the normal case maximum width, and then expand it if you go past the initial size. It's far from a perfect solution however. The method I'll use often, is to use a buffer which should encompass the maximum size (although there probably are many instances when that can still be overflowed in exceptional situations), and then use CopyString(buffer) to prepare the final string, which will be of the perfect length. Some other useful string functions included in the Ecere library are the file path manipulation functions such as PathCat, GetExtension, etc., SearchString which is like a more flexible version of strstr. Of course you can also make extensive use of all the C string manipulations functions. Generally, if a String is 'returned' by a function, it should be a newly allocated string (which needs to be freed). Functions that do not allocate new memory for a string should take an output string buffer parameter, and should ideally be accompanied by another parameter for the maximum buffer size. Right now the 'String' data type maps directly to a C 'char *'. As for how to ensure these strings get deleted, just follow the 'block' model as I outlined in the thread about exception handling. This is one of the reasons why I like having separate declarations and statements, everything that is allocated can clearly be seen at the top of a block, and that's what you need to free at the end of the block. Also strings can be stored in classes where they are freed in the destructor. You can also use string properties this way: Code: Select all
I know eC currently does very little in terms of making your life easier dealing with strings. You're pretty much back in C programming in this regards. It is one of the roughest edges of eC right now, and probably the main reason why eC would not be suited to most beginning programmers. However, the upside (if you're willing to call it such ![]() ![]() Cheers, Jerome |
Author: | fedor_bel [ Sun Apr 04, 2010 8:04 am ] |
Post subject: | Re: Strings in eC |
Dear Jerome, Thank you for the sincere answer. That clarifies things a bit and brings me down to earth. Ok, untill that perfect string class is available I will have to write some simple utility class and use it together with the other memory and string handling advices you gave me. That should not be that much of a problem, once I get used to the new style. Cheers, Fedor |
Author: | sacrebleu [ Sun Jun 27, 2010 4:49 pm ] |
Post subject: | Re: Strings in eC |
I wrote an advance String class about 12 months ago for this project. ![]() |
Author: | samsam598 [ Tue Sep 18, 2012 12:51 am ] |
Post subject: | Re: Strings in eC |
I tried to compile the JString you listed above but I encountered an issue.I will paste the source code below.Given below code the compiler complained n is undeclared,why? Code: Select all
Error Message: Code: Select all
Code: Select all
|
Author: | jerome [ Tue Sep 18, 2012 10:24 am ] |
Post subject: | Re: Strings in eC |
Hi Sam, I'm not sure whether that code worked at the time or not... But Joey uses conversion properties there, and to convert a char * into a class, a new JString object actually needs to be allocated, like this: Code: Select all
![]() Regards, Jerome |
All times are UTC-05:00 | Page 1 of 1 |
Powered by phpBB® Forum Software © phpBB Limited |