PureBasic Forums - English

my_string$ = "This is just an \"example\" of what I'm talking about"

I think it's nothing but a benefit, so I'd like to plug it in here as a request.

Thanks!

Karbon, try either:

my_string$ = "This is just an 'example' of what I'm talking about"
(single quote marks)

or

my_string$ = "This is just an " + Chr(34) + "example" + Chr(34) + " of what I'm talking about"

Does this help?

HarryO

Sure, I know you can get quotes in a string, I was just requesting less hoops to have to jump through..

Thanks!

>my_string$ = "This is just an \"example\" of what I'm talking about"

Like Fred said in a other Thread:
PB is a Basic and not C. Also a new Problem: \ must then write \\

In VB you can Escape double Quotes like this:

my_string$ = "This is just an ""example"" of what I'm talking about"

would this be a possibillity??

GPI wrote:>my_string$ = "This is just an "example" of what I'm talking about"

Like Fred said in a other Thread:
PB is a Basic and not C. Also a new Problem: \ must then write \\

And like I said in the other thread, show me a BASIC that has or supports pointers, structures, or native dynamic linked lists... PB has already crossed the line from being more like BASIC to being more like C, so why not make it more convenient to use? So what if that's the way it is in C, that's the way people expect it to be. In just about every other language you are likely to use (other than PB and VB), you have an escape character, and that character is a backslash.

So yes, you would have to write \\ in your paths, or do this: "some" + chr(92) + "directory" + chr(92) + "path"... See, not so fun is it? But that's exactally what you are telling us to do with quotes.

Matthew

helpy wrote:In VB you can Escape double Quotes like this:

my_string$ = "This is just an ""example"" of what I'm talking about"

would this be a possibillity??

Good suggestion. And i don't must change anything in the Editor.

GPI wrote:

helpy wrote:In VB you can Escape double Quotes like this:

my_string$ = "This is just an ""example"" of what I'm talking about"

would this be a possibillity??

Good suggestion. And i don't must change anything in the Editor.

That's fine if all you you want to do is make an exception for the delimiter withing the string. However, having a real escape character allows you to do things like:

""" (for whatever reason...)
\r
\n
\t

etc...

Matthew

>That's fine if all you you want to do is make an exception for the delimiter
>withing the string. However, having a real escape character allows you to
>do things like:

And a totaly incompatiblity with older source-code, no thanks.

So the attitude is to be dead set against anything that might cause problems with older code? I understand perfectly well that backwards compatibility needs to be maintained as much as possible, but sometimes, for the sake of making the product better, you have to make changes that cause backward compatibilty problems. I won't go on and on giving examples, but if PB remains 100% backward compatiable forever then it will become outdated, unused, and fade away.

There are ways to add new functionality without breaking old code. You simply build in an option to turn on new feature xyz, if the new feature causes backward compability problems. Also, initially you make the option default to the "old way", so you don't cause problems with old code. Then over time and several releases, people will update their old code, and use the new feature with their new code. Eventually you can change the feature default to the "new way" and, if desired, the old way compatiblity could be dropped altogether.

This could be accomplished with a function similar to:

old_escape = UseStringEscape([0 | 1])

The function would set an internal setting to not use an escape character in strings (zero: the current way of doing things), or to allow the use of an escape character (one: the new way.) The function would return the old setting so it could be restored if necessary. Also, the setting should apply to both double and single quoted strings and characters.

Doing things this way would have zero impact on existing code, and would allow the developer to decide if they want to use the feature or not. It would also make implementation easier since existing lexer and parser would not have to change other than to check which internal function to use when dealing with strings (and of couse a new internal function to recognize the escape sequences.)

Matthew

Just my 2 cents:

Num3 wrote:Just my 2 cents:

Code: Select all

mytext.s="I'm really enjoying "+Chr(34)+"this"+Chr(34)+" part"

But it would be funny, when this would do the same.

GPI

When talking about Speed and Size, an escape character would be just fine. Calling Chr() to often, or even connecting Strings in the Sourcecode just slows down and bloats the code.
What is it about calling Chr() with a constant value, when you could easily type the character directly in the String?

I always thought, PB was designed to be fast and compact. I give a s... about PB beeing a native BASIC dialect. All it has to be is simple, fast and convenient, nothing more.

EDIT:
In PHP there are two sorts of constant strings, those delimited with a single quote and those with double quotes. The single quoted ones can't contain any escape characters while the double quoted can (plus variable insertion etc.).

EDIT:
In PHP there are two sorts of constant strings, those delimited with a single quote and those with double quotes. The single quoted ones can't contain any escape characters while the double quoted can (plus variable insertion etc.).

Single quote are already used:

Yes, that's true, but I only wanted to show, that there are often more ways to accomplish something than you would expect.