String and interfacing with functions using char*

[DSF]

Hello,

This may be a question with an obvious answer, but I'm trying to
find out how to use a String object when it needs to be filled by a
function that uses char pointers. To make things simple, I'll use
strcpy as an example. It's properties are well known and should serve
better to explain than an obscure API call.

String cppstr = "Hello";
char cstr[20];

strcpy(cstr, cppstr.c_str());
...do whatever with cstr

I have no problem when the String is on the source side, but what if
it's on the destination side, too? Is something like this the only
recourse?

String cppstr1 = "Hello";
String cppstr2;
char *tempstr;

tempstr = new char["estimated size needed"];
strcpy(tempstr, cppstr.c_str());
cppstr2 = tempstr;
delete[] tempstr;
...do whatever with cppstr2

Or is there a way to get a C-type string directly into a String when
it's returned through a pointer as a parameter of a function? (And
no, unlike strcpy, the API call does not return the output C string
like strcpy does.)

DSF

[Ian Collins]

DSF wrote:
> Hello,
>
> This may be a question with an obvious answer, but I'm trying to
> find out how to use a String object when it needs to be filled by a
> function that uses char pointers. To make things simple, I'll use
> strcpy as an example. It's properties are well known and should serve
> better to explain than an obscure API call.
>
> String cppstr = "Hello";
> char cstr[20];
>
> strcpy(cstr, cppstr.c_str());

> ....do whatever with cstr

>
> I have no problem when the String is on the source side, but what if
> it's on the destination side, too? Is something like this the only
> recourse?
>
> String cppstr1 = "Hello";
> String cppstr2;
> char *tempstr;

Can't you just assign it?

--
Ian Collins

[Alf P. Steinbach]

On 14.10.2013 21:07, DSF wrote:
>
> [...] is there a way to get a C-type string directly into a [std::string] when

> it's returned through a pointer as a parameter of a function? (And
> no, unlike strcpy, the API call does not return the output C string
> like strcpy does.)

assert( buf_size > 0 );
std::string s( buf_size, '#' );
auto const new_length = some_c_function( &s[0], s.size() );
s.resize( new_length );


Cheers & hth.,

- Alf

[DSF]

On Tue, 15 Oct 2013 08:21:34 +1300, Ian Collins <ian-...@hotmail.com>
wrote:

Remember, strcpy was just an example. Something like:

GenericAPICall(char *s1, const char *s2, int i);

Where s2 and i are inputs and s1 is an output from the call is what
I'm talking about. You can't do:

String cppstrIn, cppstrOut;
int i = 12;
cppstrIn = "system";

GenericAPICall(cppsrtOut, cppstrIn, i);

You must create a temporary c-type string for s1, (it must long enough
for whatever length string the function supplies) call the function,
then you can assign it, as in:
cppstrOut = tempstr.

DSF

P.S. You might want to read my reply to Alf P. Steinbach when I get it
finished and posted. It seems I've had a slight misunderstanding
where strings are involved

[DSF]

It seems I've encountered an "oops" moment! I became suspicious
when I noticed your "string" is in all lower case whilst mine is not;
"String." The String class I've been dealing with is evidently one
written by the compiler writers and has nothing to do with STL
strings. This was confirmed when a search through the help file for
"vector" produced one match having nothing to do with STL. Yet I know
my compiler can handle STL code. I browsed through the numerous help
files and found one for STL. So I shall now try to interpret the
above code.

assert( buf_size > 0 );
std::string s( buf_size, '#' );

These lines assume (and test for) the existence of a buffer of
undetermined type (I assume char) and of a known length (buf_size).
string s is created and filled buf_size number of the character #.

The next line made no sense, then made a little more sense, but
still makes no sense.

auto const new_length = some_c_function( &s[0], s.size() );

The first point of confusion was the use of "auto," but research led
to the new C++11 definition of the keyword. So we are creating a
constant variable of type to be determined by whatever some_c_function
returns.
(My compiler is so far behind C++11 that the light from C++11 would
take 2,346.77 years to reach it.)

Beyond this is where things make no sense. Assuming that
some_c_function is an arbritrary function returning a string through a
pointer as I used in the strcpy example, some_c_function would be
handed a reference to the beginning of the string s. That's fine. But
the odds aren't very high that some_c_function wants the size as the
second parameter and will return the length of the string.

It also requires an existing string of buf_size length, which is the
same problem with using a temporary c-string; the need to know or
guess how long of a string some_c_function will return. But I suppose
it's not possible for the string to grow as needed. It would need
some way to monitor what some_c_function is doing to its pointer. I
don't believe there is any kind of operator overloading that would
provide a string in these circumstances the information to auto size
based on the pointer or reference it feeds to a function.

In other words, you have to have a buffer of possibly estimated
size, whether it be within a string class or located using a char
pointer.

DSF

P.S. This actually came about because I am using my own string class,
(which the writing of was a big step in learning C++) yet most of my
large classes pass char * for I/O to the class. I'm in the process of
trying to convert these classes to use the string class instead, but I
keep encountering many places where I can't use a string because of
function calls that return their value(s) through pointer parameters.
All the extra code to get these values into strings leads to a lot of
extra writing and can often get "ugly." Leading me to believe I
should just stick to a char * interface in the functions these beasts
haunt and leave strings to the more string-friendly places.

I know this is waaay off from the original question, but I figured
I'd ask it in STL string terms familiar to the group and leave the
burden of converting it into my particular needs to me.

[Alf P. Steinbach]

On 16.10.2013 00:32, DSF wrote:
> On Mon, 14 Oct 2013 21:53:25 +0200, "Alf P. Steinbach"
> <alf.p.stein...@gmail.com> wrote:
>
>> On 14.10.2013 21:07, DSF wrote:
>>>
>>> [...] is there a way to get a C-type string directly into a [std::string] when
>>> it's returned through a pointer as a parameter of a function? (And
>>> no, unlike strcpy, the API call does not return the output C string
>>> like strcpy does.)
>>
>> assert( buf_size > 0 );
>> std::string s( buf_size, '#' );
>> auto const new_length = some_c_function( &s[0], s.size() );
>> s.resize( new_length );
>>
>
> It seems I've encountered an "oops" moment! I became suspicious
> when I noticed your "string" is in all lower case whilst mine is not;
> "String." The String class I've been dealing with is evidently one
> written by the compiler writers and has nothing to do with STL
> strings. This was confirmed when a search through the help file for
> "vector" produced one match having nothing to do with STL.

Yep. The standard library's "char" based string type is "std::string".
There's also a "wchar_t" based string type called "std::wstring".

Both these types are just instantiations of the "std::basic_string"
class template, which primarily means that in some help files and
documentation sets you have to look up "std::basic_string".

> Yet I know
> my compiler can handle STL code. I browsed through the numerous help
> files and found one for STL. So I shall now try to interpret the
> above code.
>
> assert( buf_size > 0 );
> std::string s( buf_size, '#' );
>
> These lines assume (and test for) the existence of a buffer of
> undetermined type (I assume char) and of a known length (buf_size).

Well I meant "buf_size" as just a required buffer size, like

int buf_size = 42;

> string s is created and filled buf_size number of the character #.

Yes.

This includes that it allocates a buffer of at least the specified size.

The buffer is automatically deallocated when the string ceases to exist.

> The next line made no sense, then made a little more sense, but
> still makes no sense.
>
> auto const new_length = some_c_function( &s[0], s.size() );
>
> The first point of confusion was the use of "auto," but research led
> to the new C++11 definition of the keyword. So we are creating a
> constant variable of type to be determined by whatever some_c_function
> returns.

Yes.

> (My compiler is so far behind C++11 that the light from C++11 would
> take 2,346.77 years to reach it.)
>
> Beyond this is where things make no sense. Assuming that
> some_c_function is an arbritrary function returning a string through a
> pointer as I used in the strcpy example, some_c_function would be
> handed a reference to the beginning of the string s. That's fine. But
> the odds aren't very high that some_c_function wants the size as the
> second parameter and will return the length of the string.

Oh that's a not uncommon convention.

Here's an example using the mbstowcs function (multi-byte to wide
character string) from the standard library:


[code]
typedef ptrdiff_t Size;
typedef Size Index;

void fail( char const message[] )
{
cerr << "!" << message << endl;
exit( EXIT_FAILURE );
}

std::wstring widened( char const* const s )
{
Size const n = strlen( s );
Size const buffer_size = mbstowcs( 0, s, n );
if( buffer_size == -1 ) { fail( "invalid multibyte string" ); }

std::wstring result( buffer_size, L'#' );
Size const n_result_chars = mbstowcs( &result[0], s, n );
if( n_result_chars == -1 ) { fail( "mbstowcs conversion failed" ); }

assert( 0 <= n_result_chars && n_result_chars <= buffer_size );
result.resize( n_result_chars );
return result;
}
[/code]


The buffer size is first obtained, and then used to create a buffer of
the requisite size for the second call.

In general one will just have to do whatever the C function at hand
permits and suggests.

> It also requires an existing string of buf_size length, which is the
> same problem with using a temporary c-string; the need to know or
> guess how long of a string some_c_function will return.

Yes.

But by using std::string you avoid having to deal with copying and
deallocation.

> But I suppose
> it's not possible for the string to grow as needed. It would need
> some way to monitor what some_c_function is doing to its pointer. I
> don't believe there is any kind of operator overloading that would
> provide a string in these circumstances the information to auto size
> based on the pointer or reference it feeds to a function.

Right. One must just somehow or other obtain the required buffer size.
One way, when the function reports failure for too small buffer, is to
try repeatedly and double the buffer size each time.

> In other words, you have to have a buffer of possibly estimated
> size, whether it be within a string class or located using a char
> pointer.

Yes.

> P.S. This actually came about because I am using my own string class,
> (which the writing of was a big step in learning C++) yet most of my
> large classes pass char * for I/O to the class. I'm in the process of
> trying to convert these classes to use the string class instead, but I
> keep encountering many places where I can't use a string because of
> function calls that return their value(s) through pointer parameters.
> All the extra code to get these values into strings leads to a lot of
> extra writing and can often get "ugly." Leading me to believe I
> should just stick to a char * interface in the functions these beasts
> haunt and leave strings to the more string-friendly places.

The main contribution of std::string is the automatic buffer allocation
and deallocation management.

> I know this is waaay off from the original question, but I figured
> I'd ask it in STL string terms familiar to the group and leave the
> burden of converting it into my particular needs to me.

For documentation of std::string, look at
<url: http://en.cppreference.com/w/cpp/string/basic_string>

[Alf P. Steinbach]

On 16.10.2013 00:32, DSF wrote:

> (My compiler is so far behind C++11 that the light from C++11 would
> take 2,346.77 years to reach it.)
>

For Windows, for old PC with smallish memory look at

<url: http://nuwen.net/mingw.html>

Prince Nuwen was a master programmer in Vernor Vinge's galactic zones
novels. STL who maintains the above g++ distro is also a master
programmer, maintaining the standard library at Microsoft. And
incidentally with the same initials as the Standard Template Library.

If you have a modern PC, still Windows, but enough memory, then look at

<url:
http://www.microsoft.com/visualstudio/eng/products/visual-studio-express-for-windows-desktop>

for Visual C++.

Very nice product when you use info available on the web to configure
colors and not-all-uppercase menus, BUT it's a pretty huge download.

For *nix you should have g++ already.

Not sure about Mac but look around at e.g.
<url: https://developer.apple.com/technologies/tools/>.

All the above are FREE offerings.

[Geoff]

Good compiler advice all around. Xcode on the Mac is absolute fun to
use whether you are coding Objective C or C++. Writing in the IDE
feels like it's almost reading your mind at times.

[DSF]

On Wed, 16 Oct 2013 02:34:17 +0200, "Alf P. Steinbach"

<alf.p.stein...@gmail.com> wrote:

>On 16.10.2013 00:32, DSF wrote:
>> On Mon, 14 Oct 2013 21:53:25 +0200, "Alf P. Steinbach"
>> <alf.p.stein...@gmail.com> wrote:
>>
>>> On 14.10.2013 21:07, DSF wrote:
>
>Yep. The standard library's "char" based string type is "std::string".
>There's also a "wchar_t" based string type called "std::wstring".
>
>Both these types are just instantiations of the "std::basic_string"
>class template, which primarily means that in some help files and
>documentation sets you have to look up "std::basic_string".

It wouldn't have helped. As I said below all the STL information
was in a separate help file. (Perhaps I should have said "found one
for STL that is totally separate and not linked to by the main help
file.")

>
>> Yet I know
>> my compiler can handle STL code. I browsed through the numerous help
>> files and found one for STL. So I shall now try to interpret the
>> above code.
>>
>> assert( buf_size > 0 );
>> std::string s( buf_size, '#' );
>>
>> These lines assume (and test for) the existence of a buffer of
>> undetermined type (I assume char) and of a known length (buf_size).
>
>Well I meant "buf_size" as just a required buffer size, like
>
> int buf_size = 42;

I understand.

>
>> string s is created and filled buf_size number of the character #.
>
>Yes.
>
>This includes that it allocates a buffer of at least the specified size.
>
>The buffer is automatically deallocated when the string ceases to exist.

Yup. And that's one thing my string class doesn't have (yet), the
ability to pre-allocate string space. It will increase space as
needed, and even de allocate space if allocated_space - string_size
reaches a predetermined difference.

>
>> The next line made no sense, then made a little more sense, but
>> still makes no sense.
>>
>> auto const new_length = some_c_function( &s[0], s.size() );
>>
>> The first point of confusion was the use of "auto," but research led
>> to the new C++11 definition of the keyword. So we are creating a
>> constant variable of type to be determined by whatever some_c_function
>> returns.
>
>Yes.

I can see where this can make the code less clear. At the least,
one will have to get used to tracking down the function declaration
for its return type instead of the variable's declaration. In my
crystal ball I see "auto" variables having names that accurately
describe their purpose.

That's one thing I've noted with C++, you have to pay more attention
to the "big picture." In c, a = b + c; is fairly straightforward, but
in C++, it could mean, or do, anything!
(I've often wondered if spy organizations write in C++. In the
above statement "+" could be overloaded to launch missiles, erase
data, anything.)

Many Windows functions provide a mechanism by which you call the
function with the output string pointer set to NULL, causing it to
return the length of the buffer needed. Others use the "loop until
error is not 'buffer too small'" approach. Some provide neither. They
are the pain in the a$$ ones.

(I had to rewrite printf for my compiler (no wchar_t support) so I
added a feature to SPrintf(char *buf, const char*format, ...) so that
if buff is NULL, it returns the length needed. Yes, I still use
printf, but that's a whole different topic.)

I have to deal with calls like:
int SplitPathComponents(const char *path, char *drive, char
*directory, char *filename, char *extension);

That's four non-const outputs to deal with. Fortunately three of
them have OS set limits, but you get the idea.

>The buffer size is first obtained, and then used to create a buffer of
>the requisite size for the second call.
>
>In general one will just have to do whatever the C function at hand
>permits and suggests.

As I agreed above.

>
>> It also requires an existing string of buf_size length, which is the
>> same problem with using a temporary c-string; the need to know or
>> guess how long of a string some_c_function will return.
>
>Yes.
>
>But by using std::string you avoid having to deal with copying and
>deallocation.

The same with my string class. One thing I can't do with it is in
the statement:

some_c_function( &s[0], s.size() );

&s[0] works with STL string, but produces the error "Must take address
of a memory location." I expect to learn some interesting things
while exploring the difference.

{bool tongue_in_cheek = true;}
This may get me flamed out of the group, but I actually like working
with c-strings. Need the string shorter? Just pop in a zero at the
right spot and you're done!
{tongue_in_cheek = false;}

Seriously, I do enjoy c-string manipulation on a lower level and
have accumulated a large library of C/ASM string routines, creating
new tools as I've needed them.
I've been integrating them into my string class, once again as
needed.

>
>Cheers & hth.,
>
>- Alf

DSF

[DSF]

On Wed, 16 Oct 2013 02:46:46 +0200, "Alf P. Steinbach"
<alf.p.stein...@gmail.com> wrote:

>On 16.10.2013 00:32, DSF wrote:
>> (My compiler is so far behind C++11 that the light from C++11 would
>> take 2,346.77 years to reach it.)
>>
>
>For Windows, for old PC with smallish memory look at
>
><url: http://nuwen.net/mingw.html>
>
>Prince Nuwen was a master programmer in Vernor Vinge's galactic zones
>novels. STL who maintains the above g++ distro is also a master
>programmer, maintaining the standard library at Microsoft. And
>incidentally with the same initials as the Standard Template Library.
>
>If you have a modern PC, still Windows, but enough memory, then look at
>
><url:
>http://www.microsoft.com/visualstudio/eng/products/visual-studio-express-for-windows-desktop>
>
>for Visual C++.
>
>Very nice product when you use info available on the web to configure
>colors and not-all-uppercase menus, BUT it's a pretty huge download.

My PC is a home-built AMD 6-core 3.2GHz 16GB RAM Win 7 64 Ult.
Up-to-date enough when you consider that by the time any computer hits
the shelves it's already obsolete! :o)


I went searching a while back for an up-to-date compiler. I had
(have) a few requirements:

1. IDE with integrated debugger.
2. The cursor ****MUST*** be able to be positioned beyond the end of
the line and stay there in the same column while moving vertically, no
matter how long the current line it's on is.
3. 64-bit assembler included.
4. Reasonably-priced or free.

Number two has been the problem. With most IDE editors, the cursor
will fall back to the end of the line it's on, but move to it's
original position on lines as long as or longer than said position.
A few use the Windows' notepad style (UGH!), where the cursor falls
back to the end of the line it's on and stays there. The first blank
line and it's hugging the left edge.

The only one I found that had that feature (not by default, but
could be enabled) was MSVC++. But it seems to be RAD-oriented.

And over the years I've learned that everything MS writes operates
counter-intuitively to the way I think. I can get along with Windows
because it's configurable enough to fix that. My operating Windows is
*FAR* different than what comes out of the box.

Ideally, I'd love to cram an updated compiler and debugger into my
current IDE (Borland C++ 5.0x), since I'm used to how it works and
won't have to spend probably way too much time learning a new one.
Someone did find a way to shoehorn Borland's newer free compiler into
the IDE. But most project files produced errors and everything it
saved was the right size, but the file contained all zeroes! Maybe I
did something wrong, I'll try it again someday using a copy in a
virtual environment.
(It has a hell of a scripting language built-in, one would think it
could be used as a framework for any command line based
compiler/debugger. But that could involve weeks of learning only to
find it can't do that.)


If anyone knows a compiler that meets the above criteria, please
pass the name and/or link along.

>
>For *nix you should have g++ already.
>
>Not sure about Mac but look around at e.g.
><url: https://developer.apple.com/technologies/tools/>.
>
>All the above are FREE offerings.
>
>
>Cheers & hth.,
>
>- Alf

DSF

[Juha Nieminen]

DSF <nota...@address.here> wrote:
> If anyone knows a compiler that meets the above criteria, please
> pass the name and/or link along.

I think you are using slightly mistaken terminology here. A compiler is
simply a piece of software that takes your source files and produces
object or executable files. What you are talking about is a so-called IDE
(which is, basically, a full environment that consists of one or more
source file and other data editors, project management logic, the
compiler, and so on.)

You'll probably never get exactly what you want in one single package
like that. There exist highly-customizable and programmable text editors
out there, but they are difficult to integrate seamlessly into an IDE and
will often lack things that the IDE would offer (such as autocompletion
of code based on the rest of the code, or any kind of other interaction
with the rest of the project.)

Personally, I just use Emacs for editing because I can make it work like
I want. It's not perfect (because it doesn't have eg. autocompletion),
but I'm such an unix old-fogey that I just don't like anything else.
(And no, Emacs will probably not suit you because, while configuring it
to do whatever you want is possible, it's extremely laborious. Basically
you would have to learn elisp to such degree that you can call yourself
a fluent elisp programmer.)

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Alf P. Steinbach]

On 18.10.2013 13:18, Juha Nieminen wrote:
>
> Personally, I just use Emacs for editing because I can make it work like
> I want. It's not perfect (because it doesn't have eg. autocompletion),
> but I'm such an unix old-fogey that I just don't like anything else.
> (And no, Emacs will probably not suit you because, while configuring it
> to do whatever you want is possible, it's extremely laborious. Basically
> you would have to learn elisp to such degree that you can call yourself
> a fluent elisp programmer.)

I think every programmer should have created at least one editor,
without using an edit control.

I can see that work lined up for me now, because I want some basic
functionality that's not offered by edit controls or packages like the
one Notepad++ is built on (Scintilla? whatever). However, it will
probably not be a complete editor. Just text presentation with two or
three fonts, plus a movable edit field.

The last time around was in the early 80's, for the HP3000 under MPE/IV
OS, with much leveraging of programmable function keys in HP terminals
(they had these cute 8 little windows at the bottom of the screen
showing the current fkey assignments). He he. I still have that on tape.


Cheers,

- Alf

[Geoff]

On Thu, 17 Oct 2013 19:06:25 -0400, DSF <nota...@address.here>
wrote:

>2. The cursor ****MUST*** be able to be positioned beyond the end of
>the line and stay there in the same column while moving vertically, no
>matter how long the current line it's on is.

I'm not sure I understand your intent here, but UE Studio has the
capability of going into column edit mode. In this mode you can stay
in or edit/select columns of text.

http://www.ultraedit.com/

The editor can be configured to use any tool set and becomes the core
of your IDE. I use it with MASM32, VS, WinMerge, LCCWin, LLVM and
whenever I need a decent hex editor.

I know of no editor that will stay in a column past EOL no matter the
length of a line. They all seem to always go to the end of a line and
once positioned there they go to the end of the next line.

You are fighting a intrinsic problem here, all lines end at a carriage
return and all editors seem to trim white space at end of lines when
reformatting or auto-indenting. Your requirement demands an editor
anticipate your need to stay in the same column and to do that it must
insert spaces out to your cursor column and push the EOL out to that
point.

[Geoff]

On Fri, 18 Oct 2013 07:17:31 -0700, Geoff <ge...@invalid.invalid>
wrote:

Addendum: UltraEdit will do what you want.

Advanced | Configuration... | Editor Display | Cursor/Caret | Allow
positioning beyond line end.

[Paavo Helde]

Juha Nieminen <nos...@thanks.invalid> wrote in news:l3r5db$25o7$1
@adenine.netfront.net:

> I want. It's not perfect (because it doesn't have eg. autocompletion),
> but I'm such an unix old-fogey that I just don't like anything else.

Have you tried ctags/etags/GNU Global with emacs? I'm vaguely thinking
about trying to get autocompletion into emacs myself, but so far lacking a
bit motivation.

BTW, I'm positively surprised about autocompletion and "jump to
definition/declaration" features in VS2012. Most of the time this seems to
actually work! In VS2010 it was unbearably slow and failed anyway 95% of
time.

Cheers
Paavo

[Paavo Helde]

DSF <nota...@address.here> wrote in
news:jfq069h7e7vsup964...@4ax.com:

> I had
> (have) a few requirements:
>
> 1. IDE with integrated debugger.
> 2. The cursor ****MUST*** be able to be positioned beyond the end of
> the line and stay there in the same column while moving vertically, no
> matter how long the current line it's on is.
> 3. 64-bit assembler included.
> 4. Reasonably-priced or free.
>
> Number two has been the problem. With most IDE editors, the cursor
> will fall back to the end of the line it's on, but move to it's
> original position on lines as long as or longer than said position.
> A few use the Windows' notepad style (UGH!), where the cursor falls
> back to the end of the line it's on and stays there. The first blank
> line and it's hugging the left edge.
>
> The only one I found that had that feature (not by default, but
> could be enabled) was MSVC++. But it seems to be RAD-oriented.

What do you mean by this? How can an editor define your design process?
Of course you must ignore/decline 99% of stuff proposed by the "New
Project" wizard, but that's a one-time activity.

> And over the years I've learned that everything MS writes operates
> counter-intuitively to the way I think.

Visual Studio might be an exception here. It might have something to do
with that they actually use it themselves, so it has to be actually
usable (as opposed to sellable).

Cheers
Paavo

[Alf P. Steinbach]

On 18.10.2013 00:15, DSF wrote:
>
> &s[0] works with STL string, but produces the error "Must take address
> of a memory location."

Presumably this is a typo, where the intended meaning was

<< &s[0] works with STL string, but with the String class it produces

the error "Must take address of a memory location." >>

If String::operator[] returns a character value rather than a reference
then that can cause such an error message. You will then just have to
find some other way of obtaining a pointer to its buffer. Provided there
IS a guaranteed buffer -- std::string guarantees a contiguous buffer,
but the String class you've been using may not necessarily offer that
guarantee.

[Jorgen Grahn]

On Fri, 2013-10-18, Paavo Helde wrote:
> Juha Nieminen <nos...@thanks.invalid> wrote in news:l3r5db$25o7$1
> @adenine.netfront.net:
>
>> I want. It's not perfect (because it doesn't have eg. autocompletion),
>> but I'm such an unix old-fogey that I just don't like anything else.

"Autocompletion" makes me think of M-x dabbrev-expand. It's unaware
of C++ -- it simply sees all open buffers as a sequence of words,
available for expansion -- but that doesn't feel like a problem for
me.

> Have you tried ctags/etags/GNU Global with emacs? I'm vaguely thinking
> about trying to get autocompletion into emacs myself, but so far lacking a
> bit motivation.

Tags is also an essential (albeit imperfect) feature. If you write
code in Emacs or vi and don't use it, you're missing out.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[James Kanze]

On Friday, October 18, 2013 3:17:31 PM UTC+1, Geoff wrote:
> On Thu, 17 Oct 2013 19:06:25 -0400, DSF <nota...@address.here>
> wrote:

[...]

> I know of no editor that will stay in a column past EOL no matter the
> length of a line. They all seem to always go to the end of a line and
> once positioned there they go to the end of the next line.

Not the ones I know. The logical column the cursor is in
doesn't change unless you do something which involves horizontal
movement. The display position is "min( logicalColumn,
lineLength )", but the logical column isn't lost.

> You are fighting a intrinsic problem here, all lines end at a carriage
> return and all editors seem to trim white space at end of lines when
> reformatting or auto-indenting.

Or even when reading the file.

> Your requirement demands an editor
> anticipate your need to stay in the same column and to do that it must
> insert spaces out to your cursor column and push the EOL out to that
> point.

Not in the text. In any decent editor, what you see is a view
of the file, and that view is always rectangular. There's no
problem positionning the visual cursor to correspond to where
the logical cursor is located, even if there isn't any text at
that location. I suspect that most editors avoid this because
it's not clear what the semantics should be if you, say, insert
a character at a logical position when there is no text there.

IIRC, emacs has a block mode which allows text insertion at
logical positions where there is no text; it fills with blanks
if needed. One of the few things I don't like about vim is that
even in visual block mode, the visual cursor cannot be placed
beyond the physical end of line.

--
James

[Seungbeom Kim]

On 2013-10-20 09:04, James Kanze wrote:
>
> IIRC, emacs has a block mode which allows text insertion at
> logical positions where there is no text; it fills with blanks
> if needed. One of the few things I don't like about vim is that
> even in visual block mode, the visual cursor cannot be placed
> beyond the physical end of line.

Have you tried "set virtualedit=..." in Vim?
It seems to work exactly in the way you described for Emacs above.

--
Seungbeom Kim

[James Kanze]

So it does. I didn't know about it. Thanks.

--
James

[DSF]

On Sat, 19 Oct 2013 07:05:34 +0200, "Alf P. Steinbach"
<alf.p.stein...@gmail.com> wrote:

>On 18.10.2013 00:15, DSF wrote:
>>
>> &s[0] works with STL string, but produces the error "Must take address
>> of a memory location."
>
>Presumably this is a typo, where the intended meaning was
>
><< &s[0] works with STL string, but with the String class it produces
>the error "Must take address of a memory location." >>

No. I was unclear. When I prefaced the above line with: " The same

with my string class. One thing I can't do with it is in the

statement:" I forgot to clarify that I was talking about *my* string
class, the one I've been writing, not the one that came with the
compiler.

>If String::operator[] returns a character value rather than a reference
>then that can cause such an error message. You will then just have to
>find some other way of obtaining a pointer to its buffer.

[] was designed to return a single character. Like in C:

char str[100] = "Hello";
char c;

c = str[3]; /* c now = 'l' */

Not a pointer to the rest of the string.

I just tried changing:
char operator [] (int index) const {return str[index];}
to
char& operator [] (int index) const {return str[index];}

and it works. It still functions like above, but can also be used as
a pointer, as in &str[0]. Thanks for the tip. Now all I have to do
is implement "pre-sizing" code. Piece of cake.

> Provided there
>IS a guaranteed buffer -- std::string guarantees a contiguous buffer,
>but the String class you've been using may not necessarily offer that
>guarantee.

With the above said, obviously the string class I'm using can make
such a guarantee, since I wrote it that way.

>
>Cheers & hth.,
>
>- Alf

DSF

[DSF]

On Fri, 18 Oct 2013 15:58:21 +0200, "Alf P. Steinbach"
<alf.p.stein...@gmail.com> wrote:

>
>I think every programmer should have created at least one editor,
>without using an edit control.

I did that in 198X. I'd written a symbolic 6502 (Commodore, not
Apple) assembler, assembling it with an assembler I'd typed in from a
magazine. (Ahhh! There's nothing like that day when your assembler
first assembles itself!) I didn't care for the few available text
editors, so I wrote my own. Had them both stored on an EEPROM and
could start either with BASIC's SYS command. I can't say I remember
how the cursor functioned in the editor, though.

Started assembly with a simple ML monitor (VICMON). Now those were
the *FUN* days! Backward branches could just be filled in, but forward
ones I usually set to branch to themselves. That way, if I forgot to
go back and change the target once I knew what it was, the program
would go into an infinite loop. Then I could just break out of the
loop with the IP at the loop point. You could only branch -128 to 127
bytes from the instruction, so if you weren't sure about a branch, you
could always stick in a few NOPs so you could use the opposite branch
condition to branch over a JMP to the farther location. Speaking of
JMPs, if you had to insert some code to fix a bug, etc. most of the
branches would adjust automatically, being relative. But JMPs and
references to absolute memory addresses had to be found and fixed by
hand. No code/data separation back then, if the data buffer wasn't
going to grow beyond the buffer's size or was static, you put it
adjacent to its code. No asking for memory, either. If it was there,
it was yours to do with as you pleased, (outside of kernel memory
areas, of course.)

The good old days!
>
>Cheers,
>
>- Alf
DSF

[DSF]

On Fri, 18 Oct 2013 11:58:13 -0500, Paavo Helde
<myfir...@osa.pri.ee> wrote:

>DSF <nota...@address.here> wrote in
>news:jfq069h7e7vsup964...@4ax.com:
>
>> I had
>> (have) a few requirements:
>>
>> 1. IDE with integrated debugger.
>> 2. The cursor ****MUST*** be able to be positioned beyond the end of
>> the line and stay there in the same column while moving vertically, no
>> matter how long the current line it's on is.
>> 3. 64-bit assembler included.
>> 4. Reasonably-priced or free.
>>
>> Number two has been the problem. With most IDE editors, the cursor
>> will fall back to the end of the line it's on, but move to it's
>> original position on lines as long as or longer than said position.
>> A few use the Windows' notepad style (UGH!), where the cursor falls
>> back to the end of the line it's on and stays there. The first blank
>> line and it's hugging the left edge.
>>
>> The only one I found that had that feature (not by default, but
>> could be enabled) was MSVC++. But it seems to be RAD-oriented.
>
>What do you mean by this? How can an editor define your design process?
>Of course you must ignore/decline 99% of stuff proposed by the "New
>Project" wizard, but that's a one-time activity.

After many YEARS of using an editor that functions in a certain way,
using it becomes automatic. Shifting to a different editor can take
some time to get used to. In this case, I find the ability to move
the cursor beyond the EOL invaluable when creating/editing tables,
aligning text on lines separated vertically by shorter lines. If I
want to place text the same column on a shorter line one line below
the one I'm on, I just cursor down and type instead of cursor down and
hold the space bar until I'm on the same column.

And I'm used to the cursor traveling vertically in a straight manor,
so seeing it hop left and right according to line length when
scrolling vertically is a bit disconcerting.

If you meant the "RAD oriented" part, the last RAD programming suite
I tried out wouldn't even let you write a console app without creating
a form first and then hiding it. Being able to lay out controls in a
window the same way one would in a dialog was nice, but then
interacting with the control required typing code into separate
mini-editors (for each message the control sent or received) that were
fed (and expected in return) message data formatted for use with their
application framework. Not so good if you didn't want to use their
application framework.

>> And over the years I've learned that everything MS writes operates
>> counter-intuitively to the way I think.
>
>Visual Studio might be an exception here. It might have something to do
>with that they actually use it themselves, so it has to be actually
>usable (as opposed to sellable).

They have a free version. When I have time, I plan to install it in
a virtual machine and try it out. (The last time I installed VS on my
main computer, told it to install on E:, my main programming drive. It
installed about 20% of its bulk on E: and the rest on C:. I wound up
having to reinstall Windows to get the space back. So definitely a
virtual machine for VS!)


>Cheers
>Paavo
DSF

[guinne...@gmail.com]

On Wednesday, 30 October 2013 02:37:08 UTC, DSF wrote:
> >
> >> &s[0] works with STL string, but produces the error "Must take address
> >> of a memory location."
> >
> >Presumably this is a typo, where the intended meaning was
> >
> ><< &s[0] works with STL string, but with the String class it produces
> >the error "Must take address of a memory location.">
>

> I just tried changing:
> char operator [] (int index) const {return str[index];}
> to
> char& operator [] (int index) const {return str[index];}
>
> and it works. It still functions like above, but can also be used as
> a pointer, as in &str[0].

No no NO! DON'T do this.

The member function explicitly operates only on const objects.
NEVER hand out mutable references from const member functions.
Separate the functionality between const and non-const members:

char& operator[](size_t const index) { return str[index]; }
char operator[](size_t const index) const { return str[index]; }

(the latter could, like std::string, return a char const&).

[DSF]

On Wed, 30 Oct 2013 03:02:10 -0700 (PDT), guinne...@gmail.com
wrote:

>On Wednesday, 30 October 2013 02:37:08 UTC, DSF wrote:
>> >
>> >> &s[0] works with STL string, but produces the error "Must take address
>> >> of a memory location."
>> >
>> >Presumably this is a typo, where the intended meaning was
>> >
>> ><< &s[0] works with STL string, but with the String class it produces
>> >the error "Must take address of a memory location.">

This was a mistake, I should have said with my string class.

>> I just tried changing:
>> char operator [] (int index) const {return str[index];}
>> to
>> char& operator [] (int index) const {return str[index];}
>>
>> and it works. It still functions like above, but can also be used as
>> a pointer, as in &str[0].
>
>No no NO! DON'T do this.
>
>The member function explicitly operates only on const objects.
>NEVER hand out mutable references from const member functions.
>Separate the functionality between const and non-const members:
>
>char& operator[](size_t const index) { return str[index]; }
>char operator[](size_t const index) const { return str[index]; }
>
>(the latter could, like std::string, return a char const&).

I changed the header file for my string class to the above.

...which leads me right back to the same problem I started with when
using &s[0]. Error: "Must take address of a memory location."

Ignore the above two paragraphs. There used to be six. I left them
in to illustrate my stupidity! I spent half an hour trying to get rid
of that error. I changed back to my original code that worked and
still got the error! That's when it hit me. I have two versions of
the string class, one for ANSI and one for wide. I've adopted
Window's style of post fixing them with A or W. I had recently
converted the project to unicode. I was changing the A version, but
the compiler was using the W version.

Just thinking aloud:
The code works fine, but I'd really prefer that the internal string
be read only to the outside world except for initialization or
assignment. But I have to weigh that against having to create a
temporary char array every time I use a function or API call that
returns a string in the form of a pointer in the parameter list. I
think I'll live with the internal string being mutable and save all of
the extra work!

And why the const in "size_t const index"? index is going to be
passed by value. Or am I missing something?

Thank you.

"'Later' is the beginning of what's not to be."
D.S. Fiscus

[Chris Vine]

The Commodore 64 range and derivatives (I think that is what you had in
mind), and possibly also the preceding VIC, had a 6510 processor, but
with the same instruction set as the 6502. It was a lovely thing to
program in machine code/assembler. It had a well supported assembler
and monitor and documentation, and best of all an addressable back slot
to which you could attach peripherals. I used it amongst other things
to generate morse code which, via a mechanical relay, keyed a RF
transmitter, but you could do practically anything with it. A kind of
Raspberry Pi for the 80s.

And, as you say, because it was an open book with no distinction
between code and data memory, you could do yucky things like implement
polymorphism by directly poking at the memory.

Chris

[DSF]

To continue this OT discussion for one more item. Back then
everything was *DOCUMENTED*, right down to the support chips! There
were even books that fully documented the ROM code in the computer and
external floppies. These days, every company (except for CPU mfgrs.)
guard the slightest detail of their hardware as though it was a matter
of national security. Not that you can get at the hardware as easily,
anyway.

I wouldn't describe the tricks from those days as "yucky." By
today's standards, yes. But considering the single-user,
single-program use of those machines, I'd prefer to think of them as
clever tricks. :o)

[woodb...@gmail.com]

On Friday, November 1, 2013 2:08:58 PM UTC-5, DSF wrote:

> To continue this OT discussion for one more item. Back then
> everything was *DOCUMENTED*, right down to the support chips! There
> were even books that fully documented the ROM code in the computer and
> external floppies. These days, every company (except for CPU mfgrs.)
> guard the slightest detail of their hardware as though it was a matter
> of national security. Not that you can get at the hardware as easily,
> anyway.
>

"I agree that my submission of this employment application
does not obligate the Company (Bloomberg L.P., its
subsidiaries, divisions and any affiliated entities,
collectively "the Company") to employ me, or to offer me
employment."

I came across that in a job advertisement. They sound
paranoid, but I guess the job market is so bad they have
to add stuff like that. I recommend to start a company
if you haven't already.

Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

[nick.keig...@gmail.com]

On Wednesday, 16 October 2013 01:46:46 UTC+1, Alf P. Steinbach wrote:
> On 16.10.2013 00:32, DSF wrote:
>
> > (My compiler is so far behind C++11 that the light from C++11 would
> > take 2,346.77 years to reach it.)
>
> For Windows, for old PC with smallish memory look at
> <url: http://nuwen.net/mingw.html>
>
> Prince Nuwen was a master programmer in Vernor Vinge's galactic zones
> novels.

ITYM "Pham Nuwen"

<snip>

[DSF]

On Wed, 16 Oct 2013 02:34:17 +0200, "Alf P. Steinbach"

<alf.p.stein...@gmail.com> wrote:

>On 16.10.2013 00:32, DSF wrote:
>> On Mon, 14 Oct 2013 21:53:25 +0200, "Alf P. Steinbach"
>> <alf.p.stein...@gmail.com> wrote:
>>
>>> On 14.10.2013 21:07, DSF wrote:
>Well I meant "buf_size" as just a required buffer size, like
>
> int buf_size = 42;
>
>
>> string s is created and filled buf_size number of the character #.
>
>Yes.
>
>This includes that it allocates a buffer of at least the specified size.
>
>The buffer is automatically deallocated when the string ceases to exist.
>
>

>> It also requires an existing string of buf_size length, which is the
>> same problem with using a temporary c-string; the need to know or
>> guess how long of a string some_c_function will return.
>
>Yes.
>
>But by using std::string you avoid having to deal with copying and
>deallocation.
>
>
>> But I suppose
>> it's not possible for the string to grow as needed. It would need
>> some way to monitor what some_c_function is doing to its pointer. I
>> don't believe there is any kind of operator overloading that would
>> provide a string in these circumstances the information to auto size
>> based on the pointer or reference it feeds to a function.
>
>Right. One must just somehow or other obtain the required buffer size.
>One way, when the function reports failure for too small buffer, is to
>try repeatedly and double the buffer size each time.
>
>
>> In other words, you have to have a buffer of possibly estimated
>> size, whether it be within a string class or located using a char
>> pointer.

I just wanted to take a sec and thank Mr. Steinbach for reminding me
about pre-allocation for the string buffer. Turns out I already had a
SetBufferLength function, but it didn't do anything. Having a buffer
with a length independent of the string can be very handy.
For example, with operator=, I used to delete the old buffer, create
a new buffer the size of the new string, then copy the string. Now I
check to see if the current buffer is large enough for the new string,
If it is, only a copy is needed. If the buffer needs to be shortened,
their is a Compact function that will reassign the string to a buffer
just big enough to fit.

Thanks again!